Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

marcus_sugarcoated's avatar

AWS Load Balancer Health Check Path for Laravel App

I have 2 AWS EC2 instances sitting behind an Application Load Balancer. On each instance I have multiple multi-tenant Laravel apps deployed (app1.com, app2.com). As they are multi-tenant they'll have wildcard subdomains (demo.app1.com, demo.app2.com etc...)

Laravel Forge has a 000-catch-all nginx file in the sites-available/ folder which returns a status code of 444.

I'm trying to figure out what path I need to set for the target groups in AWS that will return a healthy 200 response. No matter what path I set for the health check, it always resolves to the 000-catch-all file and returns a 444 resulting in an 'unhealthy' instance.

Things I have tried:

Created a route (/health) in one of the apps that simply returns a 200 status code and set the health check path to both /health and demo.app1.com/health

Created a server block in both the 000-catch-all and the app1.com files with a server block like,

location /health { return 200 'OK'; }

The only thing that works is if I make the 000-catch-all file return a 200 instead of a 444 but that seems hacky.

Any ideas or something I might be missing?

0 likes
1 reply
yavormilchev's avatar

I was facing the same issue, thank you for posting all this info :)

The reason why you can't get any app/site to handle the request (even the "default") site is because every site's nginx configuration only listens to requests made to the public IP address of the ES2 instance, while the ELB documentation mentions that the health check requests are made to the private IP like so: curl –I private-IP-address-of-the-instance:port/health-check-target-page Docs: https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/ts-elb-healthcheck.html

So, all sites answer to the public IP, while the ELB is only making requests to the private IP, which leaves you with the option to modify the 000-catch-all file and return that 'OK' for the /health URL. As a side effect it will also respond with success on '/' because of the re-enabled "Welcome to nginx!" page due to the removed "return 444;".

I ended up doing the same thing as you, and also locking down all traffic to the application EC2 instances so they're only accessible from the load balancer. I had a 3rd party consultant help with any advice but they didn't have any other ideas. I hope this helps!

Please or to participate in this conversation.