- Newest
- Most votes
- Most comments
From which network location(s) are you unable to connect? Are you only seeing that at your office or home network; or multiple networks but all connected to the same ISP; or a very small handful of origins whose ISPs you might not be certain about; or definitely large numbers of clients across multiple ISPs?
If the problem is only confirmed to be occurring on a single ISP's network, possibly even at one office/home location, then I suggest you first try a TCP traceroute to the destination IP on port 443. There are many TCP traceroute tools available on the internet for different operating system platforms. Compare the traceroute results between one or two working and the one non-working CloudFront edge server. It isn't guaranteed that a difference will show, in case intermediate routers or firewalls don't send ICMP responses when TTL is exceeded, but if they do, you'll get a good idea of which part of the network is dropping and/or which parts of the networks are not dropping the traffic. For example, if it's your ISP that routes the packets in a wrong direction, or your office firewall that has block-listed the IP, that could be easily revealed by the TCP traceroute.
If running a TCP traceroute isn't convenient or doesn't reveal the location where the packets are dropped, then the other options would include a) running a regular ICMP traceroute to see if a difference is observed; 2) inspect the logs of intermediate devices, such as firewalls, to see if they are dropping or passing the packets; and 3) try to narrow down the commonalities and differences between the clients that observe and those that don't observe the issue. For example, for me (far from Poland), the server 108.138.51.66 is responding just fine, suggesting that the issue is likely local to Poland or near there.
The issue you're experiencing with occasional long delays for users accessing your website through CloudFront is concerning, and it appears to be related to a specific edge location (WAW51-P2) in Warsaw.
Based on the information provided, it seems that one of the IP addresses (108.138.51.66) associated with this edge location is experiencing connectivity issues, causing timeouts for some user requests. This can indeed lead to the behavior you're observing, where browsers wait for a timeout before retrying with a different edge server IP.
While it's difficult to confirm definitively without access to AWS's internal systems, your investigation suggests there might be an infrastructure issue affecting this particular edge node. The fact that other IP addresses in the same range (108.138.51.35 or .58) are working correctly while 108.138.51.66 consistently times out supports this theory.
Unfortunately, as you're on the Basic Support Plan, you can't open a technical support ticket directly with AWS. However, there are a few steps you can take:
- Continue monitoring the situation to see if it resolves on its own, as AWS may already be aware of and working on the issue.
- If the problem persists, you could try posting about it on the AWS Developer Forums or other public AWS discussion platforms. Sometimes AWS staff monitor these channels and may be able to escalate internally.
- Consider implementing a client-side retry mechanism that quickly fails over to a different edge location if a connection attempt times out. This could help mitigate the impact on your users while the underlying issue is being addressed.
- If this issue is significantly impacting your business, you might want to consider upgrading your support plan temporarily to get direct access to AWS technical support.
- In the meantime, you could also try adjusting your CloudFront distribution settings to potentially route traffic away from the problematic edge location, although this may not be a perfect solution.
While we can't confirm an official AWS infrastructure issue here, your detailed investigation certainly suggests there might be a problem with that specific edge node. Continue monitoring the situation and consider the above steps to mitigate the impact on your users.
Sources
Cloudfront 504 gateway Timeout | AWS re:Post
Cloudfront timeout to Application Load Balancer | AWS re:Post
Relevant content
- asked 3 years ago
- asked 2 years ago

We confirmed this issue for several users from Ukraine from different cities/networks.
When I do traceroute I see different IPs each time. So, when request goes through IP 108.138.51.66, it "stucks" and waits for timeout (about 130 seconds). After timeout it tries other IP and request resolves without any delays.
Here is a screenshot of curl command: https://0x0.st/8x24.png
Here is screenshot of traceroute with resolving via IP 108.138.51.66: https://0x0.st/8x2y.png
And via IP 108.138.51.40: https://0x0.st/8x2t.png