CloudFront接入现有ALB+EC2架构后出现301重定向问题排查求助

I’ve run into this exact issue before when setting up CloudFront for dynamic PHP backends, so let’s break this down step by step—starting with clearing up the confusing server: AmazonS3 header first.

First, the server: AmazonS3 Header Is Normal #

Don’t worry about this! CloudFront uses this header as a default identifier when it generates its own responses (like redirects or error pages), even if you’re not using an S3 origin. You can override it later with a custom response header if it matters to you, but let’s focus on fixing the 301 redirect issue first.

Troubleshooting & Fixes #

1. Fix CloudFront Origin Configuration (Most Likely Root Cause) #

The #1 reason for this /index.php → /index.php/ redirect is a trailing slash added to your CloudFront origin domain. Here’s how to fix it:

• Go to your CloudFront distribution → Origins tab → Select your ALB origin.
• Ensure the Origin Domain Name is your ALB’s full DNS (e.g., my-alb-123456789.us-west-2.elb.amazonaws.com) and does NOT end with a /. Adding a trailing slash here tells CloudFront to normalize paths by appending a slash, which triggers the 301.
• Set Origin Protocol Policy to HTTPS Only (since your ALB only accepts HTTPS on 443). This ensures secure traffic between CloudFront and your ALB.

2. Validate ALB Forwarding Rules #

Make sure your ALB isn’t modifying the request path:

• Go to your ALB → Listeners tab → Select the HTTPS:443 listener → View Rules.
• Confirm the default rule forwards traffic directly to your EC2 target group with no path rewrites or extra redirects. The ALB’s HTTP→HTTPS redirect should only change the protocol, not the path structure.

3. Clean Up Nginx Configuration Conflicts #

Looking at your Nginx config, there’s a potential conflict in the location / block:

• You have both try_files $uri $uri/ /index.php?$query_string; and proxy_pass http://localhost:8000; in the same block. Since your backend uses PHP-FPM (handled by the location ~ \.php$ block), the proxy_pass line is unnecessary and could cause unexpected routing.
• Comment out the proxy_pass and related proxy headers in the location / block, then restart Nginx:

  sudo systemctl restart nginx
  

• Also, check the included forge-conf/example.com/server/* files for any hidden rewrite rules that might be adding trailing slashes to requests.

4. Verify CloudFront Behavior Settings #

Ensure your CloudFront default behavior is optimized for dynamic content:

• Go to CloudFront → Behaviors tab → Select your default behavior.
• Set Path Pattern to /* and Allowed HTTP Methods to GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE (PHP services often need to handle POST/PUT requests).
• Confirm Cache Policy is set to Managed-CachingDisabled and Origin Request Policy is Managed-AllViewer (you already have this, but double-check it’s applied correctly to forward all viewer headers to your ALB).

5. Isolate the Issue by Testing Directly to the ALB #

To confirm whether the problem is in CloudFront or your backend stack, test accessing your ALB’s DNS directly:

curl -v https://your-alb-dns.us-west-2.elb.amazonaws.com/index.php

If this returns a 200 OK with your JSON response, the issue is definitely in CloudFront. If it still returns a 301, focus on debugging your ALB or EC2/Nginx setup.

Bonus: Replace the server: AmazonS3 Header #

If you want to customize this header, go to your CloudFront distribution → Behaviors tab → Edit your default behavior → Scroll to Custom Headers → Add a custom response header:

• Header Type: Response
• Header Name: Server
• Header Value: Your preferred value (e.g., CloudFront or your app name)
• Cache Behavior: Include

内容的提问来源于stack exchange，提问作者KoreanDude