Network notes / Connectivity
Find the failing layer.
Change one thing at a time. Keep the hostname, network and test consistent long enough to tell a meaningful result from a coincidence.
Start with an exact observation
Record the URL's hostname, the time and timezone, the network you are on, and the error text. Note whether the failure affects one page, one hostname, or unrelated sites as well. Do not include passwords, cookies, authorisation headers or private subscription links.
- Check local connectivity. Confirm that the device has an address and a default route. A Wi-Fi connection icon does not establish that the router has internet access. A captive portal may require interaction before ordinary requests work.
- Resolve the exact hostname. Compare A and AAAA answers. If the lookup fails, investigate the resolver and authoritative records before interpreting a web timeout. See the DNS note.
- Check the intended port. HTTPS normally uses TCP 443. A timeout, immediate refusal and successful connection are different observations. Ping uses ICMP; a missing reply does not prove that TCP or UDP is blocked.
- Verify TLS. Use the real hostname and keep certificate validation enabled. Record whether the error concerns trust, expiry, hostname matching or connection setup. See the HTTPS note.
- Read the application response. Once HTTP headers arrive, inspect the status and any redirect. A working homepage is not proof that a download, API or a separate transport works.
Compare IPv4 and IPv6 deliberately
If both address families are published, a device may use a different path from another device on the same network. On systems with curl, compare the same public URL:
curl -4 --connect-timeout 10 --max-time 20 --output /dev/null https://yoooyo.co.uk/
curl -6 --connect-timeout 10 --max-time 20 --output /dev/null https://yoooyo.co.uk/On Windows, use curl.exe and NUL instead of /dev/null. An IPv6 failure is expected if either the client has no usable IPv6 route or the name has no AAAA record. That result alone is not a reason to disable IPv6 system-wide.
When small requests work but larger ones stall
Record the transfer size, elapsed time and whether failures repeat. Different paths, packet loss, path-MTU discovery or an overloaded endpoint can cause similar symptoms. One successful retry is not a diagnosis; one failed download is not evidence of deliberate filtering.
Compare the same request on a second network if one is available. Avoid changing DNS, transport settings and device configuration together. Packet captures should be tightly scoped, handled privately and taken only where you have permission.
Leave a useful diagnostic record
A useful report contains: timestamp, network, hostname, address family, exact command, error or status, and whether the result repeats. Redact credentials and identifying paths before sharing logs.
Separate observation from explanation. “TCP connection timed out twice” is evidence; naming a provider or firewall as the cause requires more.