Bug: Same AL2 version but different AMIs causes NGINX to fail healthchecks

Question

I have dug down a lot to make sure this is a bug and post it here.  
  
I run several workloads on Elastic Beanstalk. The newest app I have deployed on Elastic Beanstalk seems to fail the default 80 port healthchecks. After digging down, I found out that it doesn't detect `index.php` files.  
  
I run two workloads with the same "PHP 7.4 running on 64bit Amazon Linux 2/3.1.0" version. The older one, that works, has AMI set to `ami-0d9f444fde94d8329`, but it seems like a newly deployed application has the AMI set to `ami-0ebd56d21ef13ef53` that makes NGINX return 404 for PHP applications.  
  
This is not related to healthchecks in the app, as if I SSH into both instances, calling `curl http://127.0.0.1` works for the older app, but for newer app it doesn't.  
  
I have tried to change some of the NGINX config files to figure out what is all about, and i realised that in the `~ .php` location block check, somehow refuses to read `index.php` files. If I create an `index.html`, curl-ing works again. If i let `index.php` as the only index, it throws 404 and refuses to serve it.

Answer

Finally, after many configuration attempts and checks, I found out that the CNAME that points to my EB Environment DNS is solving correctly the application, but internally, `127.0.0.1:80` is not solving, even tho the `listen 80 default_server` directive is set and not overwritten by any of my own configuration.

Answer

After more digging, I found out that http://127.0.0.1 gets 404, while the DNS name i pointed to the AWS EB endpoint via CNAME work. I am now going insane.

Answer

It's an issue with my Laravel app's kernel handler. APP_URL enforces DNS solving at the Kernel level within the routing system: https://github.com/laravel/framework/issues/35522  
  
Edited by: rennokki on Dec 7, 2020 6:00 AM

Bug: Same AL2 version but different AMIs causes NGINX to fail healthchecks

Relevant content