Google Gemini Node with Socket Proxy cause Socket Hang Up error

[luohaiyi]

Google Gemini Node + Socket Proxy = Socket Hang Up at 60s ?

The problem/error/question

When using the Google Gemini Node with socket proxy, the node would come to an error of

The connection to the server was closed unexpectedly, perhaps it is offline. You can retry the request immediately or wait and retry later.

with Full Message of

socket hang up

at exactly the 60 second.

As I’m using the system socket proxy, this issue could caused by this in following aspect:

1. n8n / Node.js
2. socket proxy hosting software
3. socket proxy service provider
4. other aspects (Google service, unstable network connection, etc.)

However, in Google AI Studio console, the content is generated with normal status (status code 200), but with more than one minute. And the error at Google Gemini Node always occurs at 60s. And I have tried 2 socket proxy hosting software & 2 socket proxy service provider. I think the issue may caused by the n8n / Node.js, Just as Gemini suggested:

Your assessment is basically correct. This issue is highly likely not a code bug in n8n itself, nor a problem with Google’s servers. Instead, it is caused by the interaction between the Node.js HTTP client’s default behavior and the idle connection timeout mechanism of your proxy software (ClashX).

When Gemini takes longer than 60 seconds to generate content without Streaming enabled, the TCP connection sits in an “idle” state (no data transmission). The underlying Node.js Socket or ClashX’s connection tracking mechanism believes the connection is dead and actively cuts it off (Socket Hang Up).

Below is the detailed analysis and solution:

1. Root Cause Analysis

You need to understand why it happens specifically at 60 seconds and why the error is socket hang up:

• The “False Death” State of Non-Streaming:
  When you send a request to Gemini, Google’s server will not send any data until the complete answer is generated (if you have not enabled Streaming). This results in zero TCP packet exchange between the client (n8n) and the server between the 0-second mark and the 61-second mark.

• Socket Timeout:

  • Node.js Layer: Although n8n’s global default timeout is usually quite long, the Google SDK called internally by @n8n/n8n-nodes-langchain (or the underlying fetch/axios implementation) may inherit the default socket idle timeout from Node.js or the library settings (typically 1-2 minutes, but often affected by the OS or middleware).

  • Proxy Layer (ClashX): This is the prime suspect. Clash (and the underlying Clash Core) has a keep-alive or idle timeout mechanism for TCP connections. If a connection is established but sees no traffic for 60 seconds (because Gemini is “thinking”), the proxy software—in order to save resources—may deem the connection invalid and forcibly close the Socket.

• Error Interpretation:
  Full message: socket hang up implies that the connection was reset by the peer or an intermediate link, rather than being an HTTP protocol-level error like 408 Request Timeout or 504 Gateway Timeout. This confirms that the TCP link was broken physically/network-wise.

… …

My environment

n8n (2.8.3) self hosted on MacOS with apple silicon (15.7.3) via docker

Socket proxy hosting software: including ClashX and Clash Verge. And in Clash Verge, I tried both with and without the following config:

keep-alive-interval = 10 #in second

keep-alive-idle = 10 #in second

disable-keep-alive = false

The error message

A: Error always occurs at exactly 60s

B: The Google Gemini Node Output with error

C: Error details

{
  "errorMessage": "The connection to the server was closed unexpectedly, perhaps it is offline. You can retry the request immediately or wait and retry later.",
  "errorDetails": {
    "rawErrorMessage": [
      "socket hang up"
    ]
  },
  "n8nDetails": {
    "nodeName": "CV Writer",
    "nodeType": "@n8n/n8n-nodes-langchain.googleGemini",
    "nodeVersion": 1.1,
    "resource": "text",
    "operation": "message",
    "itemIndex": 0,
    "time": "2026/2/20 02:52:24",
    "n8nVersion": "2.8.3 (Self Hosted)",
    "binaryDataMode": "filesystem",
    "stackTrace": [
      "NodeOperationError: The connection to the server was closed unexpectedly, perhaps it is offline. You can retry the request immediately or wait and retry later.",
      "    at ExecuteContext.router (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/@n8n+n8n-nodes-langchain@file+packages+@n8n+nodes-langchain_f5f6d470dc34e93454118c7ffd3feae3/node_modules/@n8n/n8n-nodes-langchain/nodes/vendors/GoogleGemini/actions/router.ts:64:10)",
      "    at processTicksAndRejections (node:internal/process/task_queues:105:5)",
      "    at ExecuteContext.execute (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/@n8n+n8n-nodes-langchain@file+packages+@n8n+nodes-langchain_f5f6d470dc34e93454118c7ffd3feae3/node_modules/@n8n/n8n-nodes-langchain/nodes/vendors/GoogleGemini/GoogleGemini.node.ts:15:10)",
      "    at WorkflowExecute.executeNode (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/n8n-core@file+packages+core_@[email protected]_@opentelemetry+exporter-trace-otlp_4dbefa9881a7c57a9e05a20ce4387c10/node_modules/n8n-core/src/execution-engine/workflow-execute.ts:1039:8)",
      "    at WorkflowExecute.runNode (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/n8n-core@file+packages+core_@[email protected]_@opentelemetry+exporter-trace-otlp_4dbefa9881a7c57a9e05a20ce4387c10/node_modules/n8n-core/src/execution-engine/workflow-execute.ts:1218:11)",
      "    at /usr/local/lib/node_modules/n8n/node_modules/.pnpm/n8n-core@file+packages+core_@[email protected]_@opentelemetry+exporter-trace-otlp_4dbefa9881a7c57a9e05a20ce4387c10/node_modules/n8n-core/src/execution-engine/workflow-execute.ts:1655:27",
      "    at /usr/local/lib/node_modules/n8n/node_modules/.pnpm/n8n-core@file+packages+core_@[email protected]_@opentelemetry+exporter-trace-otlp_4dbefa9881a7c57a9e05a20ce4387c10/node_modules/n8n-core/src/execution-engine/workflow-execute.ts:2298:11"
    ]
  }
}

My workflow

In short, I use the Google Gemini Node with gemini-3-pro-preview model, and letting gemini generate a very long content which always needs more than 60s, with google search tool and formatted (JSON) output.

What I would like to know

1. Is there anyone who has the same issue when using Google Gemini Node with socket proxy?
2. Is there anyone who use socket proxy with Google Gemini Node but do not have this issue? And could you please share your environment and socket proxy setting?
3. If the socket proxy is not used, can Google Gemini Node receive the result if it generate more than 60s?
4. Is there any method that I can use to solve this problem still using Google Gemini Node with socket proxy? Even if the generation time can exceed from 60s to 3~5mins.

More to say

I have read some related articles like this:

Intermittent ECONNRESET / socket hang up errors in HTTP Request node on Google Cloud Run (Docker)

Hi team, I’m facing intermittent ECONNRESET / socket hang up errors when using the HTTP Request node. Problem description I am seeing frequent HTTP Request node failures that: Occur intermittently (not on every execution) Happen across multiple workflows Affect different HTTP Request nodes each time (not always the same node) Occur roughly once per day per workflow The errors mostly happen in HTTP nodes where I call service APIs, for example: Uploading files to Google Cloud S…

However, the error in my case is always occurs at exactly 60s, which indicates that may not caused by unstable server or unstable internet connection.

In addition, I cannot use Retry On Fail function, as it only let Gemini generate with the same prompt again and may probably using more than 60s and cause the same issue.

Still, I have some alternatives like using HTTP Node or AI Agent Node (While I still not test whether these Nodes may encounter same issue), I still want to solve this problem.

Last but not least, thanks for all who can solve this issue or everyone who share your own experience!

[achamm]

hey, the 60s timeout is almost certainly coming from the proxy layer since that’s such a suspiciously round number. Quickest fix would be bumping the idle connection timeout in your Clash config — look for something like keep-alive-interval or the TCP timeout settings in ClashX/Clash Verge and set it higher than 60s so it stops killing the connection while Gemini is thinking. If that doesn’t work or you want more control on the n8n side, you could switch to the HTTP Request node and hit the Gemini REST API directly — that way you get access to the timeout field under Options and can set it to 120000ms or whatever you need. Just POST to https://generativelanguage.googleapis.com/v1beta/models/gemini-3-pro-preview:generateContent with your API key as a query param. You’d need to format the request body yourself but it’s pretty straightforward. Another option — enable streaming in the Gemini node if your use case allows it. That keeps the connection alive with chunks instead of going silent for 60+ seconds, so the proxy won’t see it as idle. And yeah, the AI Agent node would have the exact same problem since it’s the same underlying HTTP connection going through the same proxy. Any node that makes a long-running request through Clash will hit this.