配置GoDaddy域名绑定AWS S3静态网站后连接超时故障求助

Let’s walk through why your example.com is timing out even though DNS resolves to S3’s IP. Since dig and ping show the correct IP, the issue is almost certainly tied to how S3 is configured to serve your site, or how your DNS records are pointing to it. Here’s step-by-step troubleshooting:

1. Verify Static Website Hosting is Enabled on Your example.com Bucket #

This is the most common oversight even when files are uploaded:

• Head to the S3 console, select your example.com bucket, and go to the Properties tab.
• Scroll to Static website hosting—ensure this is set to Enable.
• Confirm you’ve specified an Index document (e.g., index.html) and optionally an Error document. Without enabling this feature, S3 won’t serve your files as a website, even if the bucket is public.

2. Double-Check Bucket Permissions & Public Access Settings #

Your bucket policy looks correct, but global settings might override it:

• Go to the Permissions tab of your example.com bucket.
• Under Block public access (bucket settings), make sure all four toggle options are disabled (since you’re serving a public website). Even a valid bucket policy won’t work if public access is blocked at the bucket level.
• Quick test: Try accessing an individual file directly via its S3 object URL (e.g., https://example.com.s3.amazonaws.com/index.html). If you get a 403 Forbidden, there’s a permission conflict—either the object lacks public read access, or the bucket’s block settings are interfering.

3. Fix Route53 Record Type (Use Alias, Not A Record) #

Directly pointing an A record to S3’s IP is a mistake—S3 requires requests to use its region-specific static website endpoint (not raw IPs) because it validates the Host header. Here’s how to fix it:

• In Route53, open your example.com hosted zone.
• Edit the example.com record set:
  • Set Type to A - IPv4 address.
  • Toggle Alias to enabled, then select Alias to S3 website endpoint from the dropdown.
  • Choose your AWS region, then pick your example.com bucket’s website endpoint (it’ll look like example.com.s3-website-<region>.amazonaws.com).
• Save the record. Using an alias ensures Route53 points to the correct, dynamic S3 endpoint and handles IP changes automatically.

4. Confirm GoDaddy DNS is Pointing to Route53 Nameservers #

If you created a Route53 hosted zone for example.com, you need to update GoDaddy’s nameservers to use Route53’s:

• In Route53, copy the four Nameservers listed at the top of your hosted zone.
• Log into GoDaddy, go to your domain’s DNS settings, and replace the default nameservers with the four from Route53.
• Note: DNS changes can take up to 48 hours to propagate, but usually take effect within an hour. If you only updated A records in GoDaddy instead of switching nameservers, Route53’s settings won’t apply.

5. Test the S3 Website Endpoint Directly #

Bypass your domain entirely to isolate the issue:

• Find your bucket’s static website endpoint in the S3 console (under Properties > Static website hosting).
• Paste it into your browser (e.g., http://example.com.s3-website-us-east-1.amazonaws.com). If this loads your site, the problem is with your DNS/Route53 configuration. If it also times out or errors, the issue is with your bucket’s static hosting or permissions.

6. Rule Out Network/Caching Issues #

• Try accessing the site from a different network (e.g., mobile hotspot) to rule out local firewall/VPN blocks.
• Run curl -v http://example.com in your terminal to get detailed connection logs—this might show if the timeout happens during the TCP handshake, or if an underlying HTTP error is being hidden.

Start with steps 1 and 3 first—those are the most likely culprits when DNS resolves but the site times out.

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