Why Gemini times out when Clash is enabled

If Gemini will not open through Clash, the visible symptom is often less informative than it looks. A browser may show a blank page, keep loading indefinitely, return a generic network error, or open the chat interface while failing when you send a prompt. Developers may see a request timeout from an SDK, an interrupted stream, or a connection reset after several seconds. These outcomes do not automatically mean that Gemini is unavailable or that your account is blocked. In many cases, the request simply took a path that could not reach the required Google endpoint reliably.

This guide is designed for the practical search intent behind queries such as Gemini not working with Clash, Gemini timeout fix, and Clash Gemini connection failed. The goal is not to copy a large rule set from an unknown forum post. Instead, you will follow an observable sequence: confirm that Clash is actually active, test the selected node, inspect the connection record, verify that Google traffic is not going DIRECT, and then investigate DNS, TUN mode, or application-specific proxy behavior. Each step removes one possible cause, so you do not change five settings at once and lose the evidence that could have identified the fault.

Before troubleshooting, keep two boundaries clear. First, Clash is a traffic-routing client; it does not provide an account, an API key, or permission to use a service. You still need an authorized Gemini account or API arrangement. Second, a successful browser test does not prove that every application uses the same route. Chrome may follow the system proxy while a terminal, desktop wrapper, Docker container, or Python process ignores it. Treat the browser, command-line tools, and API clients as separate traffic sources until the logs show otherwise.

Classify the failure before changing configuration

A short classification prevents unnecessary edits. Start by reproducing the problem once with Clash enabled and once with it disabled, provided that doing so complies with your network and service policies. Record what changes: page loading, sign-in redirects, prompt submission, response streaming, or only a particular application. The exact stage matters because Gemini-related traffic can involve more than one hostname and more than one type of connection.

  • Immediate authentication error: messages about an invalid credential, expired session, or unavailable account usually belong to the account layer rather than Clash.
  • Page loads but prompts hang: the initial web assets may be reachable while an API, streaming, WebSocket, or event endpoint is routed incorrectly.
  • Everything fails only when Clash is on: suspect the active mode, node health, DNS path, or a rule that sends Google traffic to an unsuitable policy.
  • Browser works but an API script fails: inspect proxy environment variables and the script’s own transport settings before editing browser rules.
  • Global mode fixes Rule mode: the node is probably usable, while a rule order, domain match, GEOIP decision, or DIRECT exception is wrong.
  • Only long responses time out: investigate node congestion, connection reuse, idle timeouts, HTTP/2 behavior, and stream handling rather than relying only on a quick ping.

Do not interpret a generic timeout as proof that the Gemini service itself is down. A timeout means that the client did not receive the expected response within its waiting period. The cause could be DNS resolution, TCP establishment, TLS negotiation, a rejected route, packet loss, an overloaded relay, or an application that is not using Clash at all. Write down the time of the test, the selected group, the operating system, and the application. That small incident note becomes useful when you compare several nodes or review the Connections panel.

Verify the active Clash mode and test the node

Open the Clash client dashboard and confirm that the profile you think is active is actually loaded. Subscription updates can replace a profile, and some clients preserve the profile name while changing its providers or groups. Check the running configuration, the selected proxy group, and the current mode. In most clients, Rule mode is the appropriate starting point because it allows local services to remain DIRECT while selected destinations use a proxy. Global mode is a diagnostic tool: it sends nearly all supported traffic through the chosen proxy and can reveal whether your rules are the main problem.

Next, test the selected node rather than trusting its green status icon. A latency number measures a narrow probe and may not represent the node’s ability to sustain an encrypted connection to Google services. Open the proxy group, test several candidates, and compare both latency and stability. A node with slightly higher latency but consistent successful requests is often better for Gemini than a fast-looking node that drops long-lived streams. If the client supports a URL test, use a permitted, reliable endpoint and repeat the test at different times. Congestion can vary significantly during peak hours.

Use this controlled sequence:

  1. Select one known-good node and leave it unchanged during the first test.
  2. Open the Gemini web interface in a fresh private window, then sign in only if the page loads normally.
  3. Send a short prompt and observe whether the response begins, streams continuously, and finishes.
  4. Switch to a second node without changing the profile or browser, then repeat the same prompt.
  5. Return to the Clash logs and compare the destination, policy, timing, and termination reason for each attempt.

If every node fails in the same way, a node-only explanation becomes less likely. If one group works and another does not, stop modifying DNS for the moment and investigate the provider group, node quality, or geographic egress. If Global mode works but Rule mode fails, preserve the successful node and focus on policy matching. A controlled comparison is more valuable than repeatedly clicking the same “延迟测试” button while the application uses a different group.

Inspect Connections: prove how Gemini traffic is routed

The Connections, Logs, or Traffic panel is the most useful source of evidence in a Clash timeout investigation. Keep it open while reproducing the issue. Search for the hostname associated with the failing request and inspect whether the connection was assigned to the expected proxy group, a fallback group, or DIRECT. Look at the rule that matched the request. A domain can appear healthy in one browser tab and still be misrouted in another process because the destination hostname, port, or DNS result differs.

Google services can use several host families depending on whether you are opening the web application, completing authentication, loading static resources, sending prompts, or using an API client. Do not build a routing policy solely from a static list copied from an old tutorial. Search the live logs during a failed request, identify the actual destinations, and verify that the relevant Google traffic follows the intended policy. Avoid broad rules that accidentally proxy your entire network when a smaller, auditable rule set is sufficient.

Rule order is critical. Clash evaluates rules from top to bottom and normally stops at the first match. A premature DOMAIN-SUFFIX, GEOIP, or catch-all rule can capture a request before the Google-specific rule gets a chance to run. A typical diagnostic arrangement places deliberate domain rules above broad geographic or final rules, followed by a clearly defined fallback:

rules:
  - DOMAIN-SUFFIX,googleapis.com,Gemini
  - DOMAIN-SUFFIX,googleusercontent.com,Gemini
  - DOMAIN-SUFFIX,google.com,Gemini
  - GEOIP,LAN,DIRECT
  - MATCH,DIRECT

The names in this example are placeholders for your own policy groups, and the exact domains required depend on the product and current service behavior. Do not paste it unchanged into a production profile. Confirm every match in the logs, make sure the group exists, and keep local network exceptions above broad rules where appropriate. If your profile uses rule providers, inspect the provider contents and update interval as well. A provider may contain an old DIRECT exception that silently overrides your local intention.

After changing rules, reload the configuration and clear stale connections. Existing HTTP/2 sessions, browser service workers, or pooled sockets may continue using the old decision. Close the affected tab or application, clear only the relevant site data if necessary, and create a new test connection. The point is to test the new policy, not to observe a connection that was opened before the reload.

Check DNS, fake-IP behavior, and TUN mode

When the connection log shows the expected rule but Gemini still times out, investigate name resolution and packet handling. Clash may be configured with a fake-IP mode, redirection mode, or enhanced DNS mode. These features can work well, but they create another layer where a hostname, synthetic address, and application behavior must agree. A browser that supports the client’s interception model may work while an older application caches the synthetic address incorrectly or bypasses the intended resolver.

Begin with the simplest comparison. Temporarily use a resolver configuration recommended by your network administrator or trusted provider, reload Clash, and repeat the test. Avoid mixing several unrelated public resolvers without understanding who receives the query and which transport is used. DNS results can vary by location, and a resolver that is fast for ordinary websites may return an unusable answer for the route you selected. If your client offers separate “DNS through proxy” or “respect rules” options, change one option at a time and record the result.

Common DNS clues include:

  • The browser waits before any connection appears in the Clash log, suggesting resolution or application bypass.
  • The log shows a destination IP but the application reports a hostname certificate error, suggesting hostname preservation or interception trouble.
  • Different applications resolve the same service to different addresses and only one succeeds.
  • Changing from fake-IP to redirection or a compatible mode fixes the issue without changing the node.

TUN mode is useful when an application ignores system proxy settings, uses its own networking stack, or cannot be configured with an HTTP or SOCKS proxy. Enable it only after confirming that the client has the required permissions and that no other VPN, firewall extension, DNS filter, or corporate security agent is competing for traffic. On Windows and macOS, overlapping virtual adapters can create loops or routes with a lower priority than the Clash interface. On Linux, inspect the route table and service logs rather than assuming the interface was installed correctly.

Use TUN as a targeted diagnostic, not as a universal cure. If Gemini begins working only after TUN is enabled, the application probably was not honoring the system proxy. Keep the mode if it is acceptable for your environment, but document what it captures, what remains DIRECT, and how to disable it safely. If TUN produces more failures, return to the previous state and inspect routing conflicts, DNS mode, and permissions. A stable proxy client is preferable to a permanently enabled feature whose behavior you cannot explain.

Fix command-line and API client timeouts separately

A successful Gemini browser session does not automatically configure the Gemini CLI, Python SDK, Node.js script, or Docker workload. These clients may require an explicit HTTP or SOCKS proxy, may read only uppercase environment variables, or may reject a proxy protocol that the desktop client exposes. Check the documentation for the specific tool and use the proxy format it supports. Do not assume that setting a browser preference changes the environment inherited by a terminal process.

For a diagnostic shell session, you might inspect whether proxy variables exist:

env | grep -i proxy
curl -I https://generativelanguage.googleapis.com

The command above is only a visibility check; an HTTP header response alone does not validate your account or prove that a streaming Gemini request will succeed. If you configure variables such as HTTPS_PROXY, keep their scope limited to the intended shell or service, and mirror lowercase variants only when the client documentation calls for them. Review NO_PROXY carefully. An overly broad entry can send Google traffic DIRECT even though the desktop Clash dashboard looks correct.

For Docker, systemd, CI runners, and IDE terminals, verify the process environment from inside the actual execution context. A variable exported in your interactive shell may not reach a system service. Conversely, a service may retain an old proxy value after you change the desktop client. Restart the relevant process after configuration changes and inspect its logs for connection, TLS, and timeout details. When possible, use a short request with a small output rather than a long generation while validating the route.

Long streaming requests need a healthy path, not merely a reachable path. A node can pass a quick test but drop idle periods, mishandle HTTP/2 reuse, or become saturated when responses remain open. Try another node, reduce concurrency, update the client, and compare a short prompt with a longer one. Do not compensate for a broken route by setting an extremely large timeout; that only makes the failure slower and can conceal resource exhaustion. If the API returns a clear HTTP status, preserve it in your notes because a server-side refusal and a local socket timeout require different next steps.

A repeatable recovery checklist

After making changes, return to a known baseline and test in a fixed order. First, confirm the Clash profile, mode, and selected group. Second, test one stable node and watch the live connection log. Third, verify that the actual Gemini-related destinations match the intended policy instead of DIRECT. Fourth, reload the configuration and close stale browser or application sessions. Fifth, compare DNS modes only if routing rules and node health look correct. Sixth, enable TUN only when the failing application does not honor the system proxy. Finally, test the exact client that originally failed, using the same account, operating system, and request type.

Keep a small change log with entries such as “node B succeeded in Rule mode,” “Global mode changed the rule match,” or “TUN fixed the CLI but introduced a DNS conflict.” This prevents circular troubleshooting and makes rollback straightforward. Remove temporary broad rules after the cause is understood, avoid exposing subscription URLs in screenshots, and do not leave debugging credentials or verbose logs in shared folders. If the issue persists across several authorized networks, healthy nodes, and correctly routed destinations, compare the client’s error with the service status and account documentation. At that point, further Clash edits may not be the productive path.

Compared with one-click VPN applications that often hide the selected route, provide limited per-domain evidence, or apply the same tunnel policy to every application, Clash gives you a more inspectable workflow: you can see the connection, test node groups, place specific rules before broad matches, and choose TUN only when an application needs it. That control does require a little more discipline, but it makes a Gemini timeout reproducible instead of mysterious; if you want to apply the same troubleshooting approach across your devices, the official download page is a sensible next step.

Download Clash for free and browse freely →