Safari Can't Open the Page: Server Unexpectedly Dropped the Connection

"Safari can't open the page because the server unexpectedly dropped the connection" appears on iPhone, iPad and Mac when Safari opens a connection and the other side closes it without a proper response. The page adds: "This sometimes occurs when the server is busy. Wait for a few minutes, and then try again." Sometimes the message is "Safari Can't Open the Page" with "The error is: 'The network connection was lost.'"

Safari does not show a code. The meaning is the same as Chrome's ERR_CONNECTION_CLOSED or ERR_EMPTY_RESPONSE, or Firefox's PR_END_OF_FILE_ERROR. The connection was started, then ended early: during the TLS handshake, before any bytes of HTTP, or mid-response. The cause is on the visitor's device or network, in the middle, or on the server.

Step 1: separate local from remote

Test the site elsewhere. Use Down From Where to check from several locations, and try the same URL on mobile data and on Wi-Fi, and in another browser on the same device.

• Fails everywhere: the server or its network is the cause. Skip to the owner section.
• Fails on one network only: the router, DNS, or a filter on that network is dropping it.
• Fails in Safari only: a Safari setting, content blocker or Apple service is involved.

If you are a visitor on iPhone, iPad or Mac

1. Reload, then wait a few minutes. The message itself suggests a busy server.
2. Toggle Wi-Fi and mobile data. On iPhone, test the same page on cellular. If it works, the Wi-Fi network is the problem.
3. Turn off iCloud Private Relay for the network, or for the Wi-Fi network in its settings, to test. Private Relay proxies Safari traffic, and some sites or networks drop those connections.
4. Turn off VPN, DNS profiles and content blockers. Check Settings, VPN & Device Management, and Safari's Extensions. Disable ad and tracker blockers for the site.
5. Check Limit IP Address Tracking in the Wi-Fi network's details and test with it off.
6. Clear website data. On iPhone: Settings, Safari, Clear History and Website Data. On Mac: Safari, Settings, Privacy, Manage Website Data, remove the site.
7. Test the IPv6 path. Some servers answer badly over IPv6. A different network, or temporarily disabling IPv6 on the router, can reveal it.
8. Restart the router and the device.
9. Update iOS or macOS. Old releases can lack current TLS behavior.
10. Check the date and time are set automatically.

If you own the site

Since there is no error code, reproduce the failure from a command line, with a Safari-like client behavior (modern TLS, SNI, HTTP/2):

curl -vI --http2 https://example.com/ 2>&1 | grep -E "Connected|SSL|TLS|HTTP/|error|closed"
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>&1 | head -n 20

If you get a certificate and a normal response, look at conditions specific to Apple clients (below). If the connection closes during the handshake, follow the PR_END_OF_FILE_ERROR checklist: listener, SNI, certificate load, firewall.

Apple-specific TLS requirements

Apple platforms enforce certificate rules that other clients may not.

• Certificate lifetime: Apple's policy limits the validity of publicly trusted TLS certificates; certificates that exceed the limit are rejected by Safari. Check Apple's current policy documentation for the exact maximum and effective date.
• Chain and key requirements: the server must send the full chain, with SAN entries and strong keys. Test with the SSL Checker. A missing intermediate is a typical Safari-only failure; see incomplete certificate chain.
• Protocol versions: Apple requires modern TLS; servers limited to old versions fail. Use the TLS Version Checker and read ERR_SSL_OBSOLETE_VERSION.

Server and network causes

• Firewall, WAF or fail2ban closing connections for some addresses, including iCloud Private Relay egress ranges.
• Server overload: exhausted workers or file descriptors drop new connections. See too many open files and PHP-FPM reached pm.max_children.
• Proxy or load balancer idle timeouts shorter than the backend's.
• Broken IPv6 where the AAAA record points to a host that is not serving HTTPS. Check with the DNS Checker and the Port Checker, and curl with -6.
• Crashing backend that kills the connection mid-response; see ERR_INCOMPLETE_CHUNKED_ENCODING.

Check headers and response

Use the HTTP Header Checker to confirm the server returns a clean response. Add an Uptime Monitor so intermittent drops are recorded with timestamps.

Next steps

• Read err connection refused, timed out and reset explained.
• Review why is my website down.
• Compare with ERR_CONNECTION_RESET.
• See SSL and TLS certificate errors explained.

FAQ

Does this mean the website is down?

Not always. The server may be up but dropping this connection because of overload, a firewall rule or a handshake problem. Check from other networks.

Should I wait a few minutes like Safari suggests?

It is worth one retry. If it persists on every attempt and network, the cause is persistent and waiting will not help.

Can Private Relay cause it?

It can, when a site or network blocks Apple's relay addresses. Turn it off for the network to test.

Why does it work in Chrome on the same Mac?

Chrome and Safari differ in TLS behavior, extensions and Apple service integration. The difference points to Safari-specific settings or certificate rules.

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.