# Atlas error "Connection reset by server" (ECONNRESET): how to fix it > Retry first: Atlas marks ECONNRESET retryable. If "Connection reset by server" persists, a corporate proxy, VPN, or firewall is dropping the TLS connection to the provider. Atlas shows the APIError message "Connection reset by server" with metadata code ECONNRESET when the TLS connection to the provider is dropped underneath it, and the fix is to retry, because Atlas marks ECONNRESET retryable. If retries keep failing, a corporate proxy, VPN, or firewall is dropping the connection, and an idle-timeout on that proxy is the usual culprit on long generations. ## Symptom The assistant message carries an APIError with the message "Connection reset by server" and metadata containing code ECONNRESET. ## Cause Atlas's toError inspects the Node SystemError code. On ECONNRESET it produces a retryable APIError and records the code, the syscall, and the raw message in metadata, so a reset connection surfaces as "Connection reset by server" rather than as an opaque crash. ## Fix 1. Retry the message. Atlas marks ECONNRESET retryable, so a repeat attempt is the intended first response. 2. Check for a corporate proxy, VPN, or firewall dropping the TLS connection to the provider, and take the provider host out of that path. 3. Test connectivity to the provider host outside Atlas to confirm the reset is not local to your machine. 4. If "Connection reset by server" only happens on long generations, suspect an idle-timeout on the proxy rather than the provider. 5. Read the metadata Atlas recorded: the code, the syscall, and the raw message together identify which call was reset. ## Why does Atlas say Connection reset by server Atlas says "Connection reset by server" when the Node SystemError code on a failed request is ECONNRESET. Atlas's toError inspects that code, produces a retryable APIError, and records 3 things in metadata, the code, the syscall, and the raw message, so the reset is traceable rather than opaque. ECONNRESET is the operating system telling Atlas that the far end of the TCP connection went away abruptly. Atlas does not guess at what happened. It reads the Node SystemError code directly, and when that code is ECONNRESET, it constructs an APIError whose human message is "Connection reset by server" and whose metadata preserves three things: the code, the syscall that failed, and the raw underlying message. Those three fields are the evidence trail. If you are unsure whether you are looking at an authentication failure, a content block, or a network reset, the ECONNRESET code in metadata settles it immediately. ## How to fix Connection reset by server in Atlas Step 1 of the documented fix is to retry the message, since Atlas marks ECONNRESET retryable. Step 2 is to look for a corporate proxy, VPN, or firewall dropping the TLS connection to the provider, then remove the provider host from that path so "Connection reset by server" stops recurring. A retry is the correct first move because a reset is often a one-off. When retries do not clear it, the reset is being caused by something that will reset it again, and in practice that something sits between your terminal and the provider. Corporate proxies, VPN clients, and firewalls all terminate TLS connections they consider stale, disallowed, or suspicious. Add the provider host to a bypass list, or test from a network without the proxy in front of it. The caveat worth stating plainly: Atlas cannot prevent a network device from resetting a connection, so the fix here changes the network path, not an Atlas config key. ## How to test whether the reset is local or remote Step 3 of the documented fix is to test connectivity to the provider host outside Atlas. If a plain connection to the same provider host from the same machine also resets, the problem lives in your network path, not in Atlas and not in the provider's API. Take Atlas out of the loop entirely and reach the provider host directly from the machine that failed. A reset that reproduces outside Atlas proves the network path is at fault, which immediately redirects the investigation to the proxy, VPN, or firewall on that path. A connection that succeeds outside Atlas but fails inside it is worth reporting with the metadata Atlas captured, since the code, syscall, and raw message from the ECONNRESET path are exactly the details needed to diagnose it. Running the test from a second network, such as a phone hotspot, is a fast way to separate the corporate path from the machine. ## Why Connection reset by server only happens on long generations Step 4 of the documented fix applies when "Connection reset by server" appears only on long generations: suspect an idle-timeout on the proxy rather than the provider. A model producing a long answer holds 1 connection open for a long time, and a proxy that measures idleness by bytes will reset it. The pattern is diagnostic. Short prompts finish inside the proxy's timeout window and never reset. Long ones cross it and die. If your Atlas sessions succeed on quick questions and fail with ECONNRESET whenever the model works on something substantial, you are almost certainly looking at an idle-timeout, not at a flaky provider. The fix belongs with whoever administers the proxy: raise the idle-timeout, or exempt the provider host from it. Retrying the same long message will simply hit the same timeout again, so retry alone will not clear this variant. ## How to verify the Connection reset by server fix worked Verify the "Connection reset by server" fix in Atlas by re-running the longest generation that previously failed and confirming 0 new APIErrors arrive with ECONNRESET in metadata. A short test message is not enough, because an idle-timeout reset only shows on long-running connections. Reproduce the original conditions as closely as you can. Use the same provider, the same model, and a prompt that produces a long enough response to hold the connection open past the point where it broke before. Then check the assistant message for an APIError. Clean completion with no "Connection reset by server" and no ECONNRESET code in metadata is the confirmation. If you also see Atlas report ProviderResponseStreamError in the same session, the underlying connection is still being cut, and the network path still needs work. ## FAQ ### What does ECONNRESET mean in Atlas ECONNRESET is the Node SystemError code Atlas reads when the connection to the provider is reset. Atlas's toError turns it into a retryable APIError with the message "Connection reset by server" and stores the code, syscall, and raw message in metadata. ### Is Connection reset by server retryable in Atlas Yes. Atlas produces a retryable APIError on ECONNRESET, so retrying the message is the first documented step. Retries will not help if a proxy idle-timeout is resetting every long generation. ### Can a corporate proxy cause Connection reset by server in Atlas Yes. A corporate proxy, VPN, or firewall dropping the TLS connection to the provider is a documented cause. Take the provider host out of that path and retry. ### Why does Atlas only reset the connection on long responses When "Connection reset by server" appears only on long generations, the likely cause is an idle-timeout on the proxy rather than the provider. Long generations hold one connection open long enough to cross that timeout. ### How do I check if ECONNRESET in Atlas is a local network problem Test connectivity to the provider host outside Atlas from the same machine. If the reset reproduces without Atlas, the network path is at fault, not Atlas or the provider API. ### Where does Atlas record the ECONNRESET details Atlas records the code, the syscall, and the raw message in the APIError metadata. Those three fields identify exactly which call was reset. --- Canonical HTML: https://runatlas.sh/resources/troubleshooting/connection-reset-by-server Source of truth: aeo_pages row `/resources/troubleshooting/connection-reset-by-server` (segment: Troubleshooting) (this file is generated from it, never hand-edited). Licence: Atlas is proprietary with a free core. It is not open source and there is no public source repository.