无法通过Route 53域名访问网站的技术排查求助

Let’s walk through the most likely issues and fixes here—since you can reach your EC2/LB directly but not via your www.domain.com domain, the problem is almost definitely tied to DNS resolution or Route53 configuration, not your backend servers.

1. Verify DNS Resolution is Working Correctly #

First, confirm your domain is resolving to the right IP address or LB DNS. Use these terminal commands to check:

• Basic lookup: nslookup www.domain.com or dig www.domain.com
• Trace full resolution chain (great for spotting upstream DNS issues): dig www.domain.com +trace

What to look for:

• The output should match your EC2’s public IP (when routing directly to it) or resolve to the LB’s DNS name (and its associated IPs).
• If the returned IP/DNS is wrong, your Route53 record is misconfigured.
• If there’s no resolution at all, your domain might not be pointing to Route53’s nameservers (more on that below).

2. Double-Check Your Route53 Record Set #

Head to the Route53 console and verify these critical details for your www.domain.com record:

• Record Type:
  • For EC2 public IP: Use an A record. If you’re using a temporary public IP (not Elastic IP), it might have changed after an EC2 restart—confirm the IP matches what’s in Route53.
  • For Load Balancer: Use an Alias record (not a CNAME) for AWS resources. Alias records automatically track LB IP changes, whereas CNAMEs are static. Ensure the Alias target is correctly selected as your LB.
• Record Name: Make sure it’s exactly www.domain.com (no typos, extra dots, or missing parts).
• TTL: If you recently updated the record, a long TTL (e.g., 24 hours) could mean clients are still using cached old data. Temporarily lower it to 300 seconds (5 minutes) to speed up propagation.

3. Confirm Your Domain Uses Route53 Nameservers #

Your domain must use Route53’s assigned nameservers for its records to take effect. To check:

1. Run dig ns domain.com in your terminal.
2. Compare the returned nameservers to the ones listed in your Route53 hosted zone (under the "NS" record set).
3. If they don’t match, update your domain registrar’s nameserver settings to point to Route53’s nameservers. This change can take up to 48 hours to propagate globally, but usually happens much faster.

4. Clear Local DNS Cache #

Sometimes your local device holds onto old DNS records. Flush the cache to force a fresh lookup:

• Windows: ipconfig /flushdns
• Mac: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
• Linux: sudo systemctl restart systemd-resolved (use your distro’s specific command if needed)

You can also test using a different network (like mobile data) to rule out local network DNS issues.

5. Check for WAF/SSL Certificate Issues (If Using HTTPS) #

If you’re accessing the site over HTTPS:

• SSL Certificate: Ensure your certificate (on the LB or EC2) includes www.domain.com as a valid subject alternative name (SAN). If the certificate only covers the LB’s DNS name or your root domain, browsers will block access due to invalid SSL.
• WAF Rules: If you have a WAF attached to your LB or CloudFront, check for rules blocking requests with the www.domain.com Host header. Review WAF logs for any blocked traffic.

6. Rule Out Edge Cases #

• Typos: Double-check the domain name in your browser—even a small typo (like wwww.domain.com) will break access.
• Route53 Health Checks: If you have health checks enabled on your record, confirm they aren’t incorrectly marking your resource as unhealthy and stopping traffic routing.

Start with the DNS resolution and Route53 record checks first—those are the most common causes of this exact issue. Once you confirm the domain resolves correctly, move on to the other steps if needed.

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