HTTP与HTTPS访问不同站点异常问题求助（AWS环境）

Hey Krisam, let's dig into why your http://www.123.com is loading www.987.com instead of your intended site—especially since this started after adding SSL. Since you've already ruled out .htaccess and domain forwarding, the issue is almost certainly tied to AWS-specific configurations or your web server's default setup. Here are the most likely culprits and fixes:

1. Check AWS CloudFront (If You're Using a CDN) #

If you're using CloudFront to serve either site, misconfigured origins or behaviors could be routing HTTP traffic incorrectly:

• Head to the CloudFront console, find the distribution linked to www.123.com, and verify the Origin Domain Name points to your 123.com server/ALB (not 987.com's resources).
• Check the Behaviors tab: Ensure the HTTP (80) behavior is set to route requests to the correct origin, not a cross-site one.
• Don't forget to clear CloudFront's cache via the Invalidations tab—old cached redirects might be sticking around.

2. Audit Your Elastic Load Balancer (ALB/ELB) Listener Rules #

If you're using an ALB or ELB to handle incoming traffic, a misconfigured HTTP listener could be sending requests to the wrong site:

• Go to the EC2 Console > Load Balancers, select your 123.com load balancer, and navigate to the Listeners tab.
• Look at the HTTP:80 listener's rules: Confirm the target group is associated with your 123.com EC2 instances, not 987's.
• Double-check any HTTP-to-HTTPS redirect rules you might have added when setting up SSL—if you accidentally set the redirect target to www.987.com, that's exactly what's happening.

3. Verify Your Web Server's Default Site Configuration #

Even with a blank .htaccess, your web server (Apache/Nginx) might be falling back to a default site that's set to 987.com:

For Apache: #

• Check the configuration files in /etc/apache2/sites-available/: Ensure there's a valid config for www.123.com with the correct ServerName and document root.
• Make sure this config is enabled (run sudo a2ensite your-123-config.conf if needed) and that the default 000-default.conf isn't overriding it.

For Nginx: #

• Look in /etc/nginx/sites-available/ or /etc/nginx/conf.d/ for your 123.com server block. Confirm it has server_name www.123.com; and points to the right root directory.
• Check the default server block—if it's set to serve 987.com, any unrecognized HTTP requests (including misconfigured 123.com traffic) will route there.

4. Double-Check Route 53 Records (Just to Be Sure) #

You mentioned no domain forwarding, but it's worth a quick second look:

• In the Route 53 Console, open the hosted zone for www.123.com.
• Verify your A/CNAME record points to the correct CloudFront distribution, ALB, or EC2 instance—not the resources tied to 987.com.
• Ensure there are no hidden "Redirect" type records that you might have missed.

Quick Debugging Steps to Narrow It Down #

• Test directly via EC2 IP: Try accessing your 123.com EC2 instance's public IP over HTTP. If it loads the correct site, the issue is in your routing layer (Route53/ALB/CloudFront). If it loads 987.com, the problem is on the EC2 server itself.
• Use curl to inspect headers: Run curl -v http://www.123.com in your terminal. Look for a Location header (indicating a redirect) or check if the response content is directly from 987.com—this will tell you if traffic is being redirected or just served from the wrong source.

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