Fix Gemini Not Working in Clash: Timeout Troubleshooting Guide

What “Gemini Not Working” Looks Like in Clash

Google Gemini failing in a Clash environment does not always mean that the proxy server is unusable. A node can open ordinary websites while Gemini remains stuck on a loading spinner, returns a connection error, or times out after the page has already loaded. The service involves several separate connections: the web interface, account authentication, API requests, streaming responses, static resources, and sometimes WebSocket-style long-lived connections. If only one of those paths is routed incorrectly, the result can look like a complete outage.

The first useful distinction is whether the failure happens before or after the Gemini interface appears. If the page never opens, start with the selected node, basic routing, DNS resolution, and TLS connectivity. If the page opens but sending a prompt hangs, inspect the service domains used for API requests and streaming responses. If text appears briefly and then stops, a long-lived connection may be timing out, being reset by the node, or being interrupted when Clash changes the active proxy group.

Do not immediately replace the entire configuration. A full replacement can hide the actual cause and may introduce a second problem, such as an incompatible rule provider, an incorrect DNS mode, or a node group that selects a server with poor support for long connections. Troubleshoot from the outside in: verify the node, identify the connection selected by the rules, check DNS behavior, then test TUN and application-specific routing.

Observed symptom	Most likely area	First action
The page does not load at all	Node, DNS, or basic proxy routing	Test another node and inspect Clash logs
The page loads but prompts time out	Service-domain rules or unstable outbound	Route Gemini-related traffic through one tested proxy group
Login loops or account verification fails	Authentication domains, cookies, or region consistency	Keep authentication and Gemini traffic on the same exit region
Responses start and then stop	Streaming connection, node quality, or TUN handling	Try a stable node and compare system-proxy with TUN mode
Only one application fails	Application proxy support or process routing	Check whether that application actually enters Clash

Step One: Verify the Node Before Editing Rules

A timeout is often blamed on a rule when the selected server is simply overloaded, geographically unsuitable, or unable to maintain the type of connection Gemini requires. Before changing YAML, switch to a known working node in the client and test again. Use the same browser, the same account, and the same prompt so that the comparison changes only one variable at a time.

Open Clash Verge, Clash Verge Rev, Clash for Windows, ClashX, Clash for Android, or another Mihomo-based client and confirm that the configuration is active.
Open the proxy group used by the final matching rule. Select one node manually instead of leaving the group on an automatic choice.
Wait several seconds after switching, then reload the Gemini page in a private window or clear only the affected site data if the previous session is stuck.
Send a short prompt and observe whether the request finishes, streams gradually, or fails at the same point.
Repeat the test with a second node from a different region or provider. Record the result rather than switching repeatedly without a baseline.

A good node for Gemini is not necessarily the node with the lowest HTTP latency. The client may report a fast handshake or delay to the proxy endpoint, while the complete route to the service has packet loss, congestion, filtering, or poor international transit. Long responses also expose problems that a simple latency test does not reveal. A node that loads a small webpage may still reset a streaming response after thirty or sixty seconds.

Keep the exit region consistent during testing. Moving between regions can trigger additional account verification, change service availability, or produce different DNS answers. If login succeeds through one region but requests fail through another, first confirm whether the issue follows the region or follows the node. That distinction is more valuable than changing multiple settings at once.

Do Not Judge a Node by Delay Alone

Clash's delay measurement usually tests a small HTTP request to a configured URL. It does not guarantee that Gemini authentication, API traffic, DNS resolution, and long streaming responses will all work through the same server. Test the actual service after selecting a node.

Step Two: Confirm That Gemini Traffic Uses the Intended Proxy

Clash evaluates rules from top to bottom. The first matching rule decides the outbound, so a broad GEOSITE, GEOIP, DOMAIN-KEYWORD, or rule-provider entry placed above your service-specific rule can send Gemini traffic to DIRECT. A final MATCH rule may also point to a group that contains an unreliable node or an unintended regional policy.

Open the client’s connections or logs panel while loading the page and sending a prompt. Search for the destination domains shown by the active connections. Do not rely only on the visible page address: a web service commonly uses separate domains for the interface, authentication, static assets, API calls, telemetry, and response delivery. The connection list tells you which destinations are actually being contacted and which policy group handled them.

If the client provides a rule-test or connection-detail view, inspect the exact matched rule. A result such as DOMAIN-SUFFIX,...,DIRECT explains why a request bypassed the proxy; a result such as MATCH,Proxy means the request reached the catch-all and may not have matched a dedicated service rule. The goal is not to force every Google-owned destination through one policy indiscriminately. The goal is to identify the destinations involved in the failed request and give them a predictable outbound.

Use Narrow Rules Instead of a Broad Keyword

A broad keyword rule containing a short word such as google can affect search, update services, account pages, media, and unrelated applications. It may also create unexpected loops when a DNS resolver or rule-provider address contains the same keyword. Prefer exact domains or suffixes for the service domains confirmed in your connection log. Keep the rules above broad regional rules and above the final catch-all.

# Illustrative structure only: replace SERVICE_GROUP with your real group name
rules:
  - DOMAIN-SUFFIX,example-service.invalid,SERVICE_GROUP
  - DOMAIN-SUFFIX,example-auth.invalid,SERVICE_GROUP
  - MATCH,GLOBAL

The domains in this example are deliberately placeholders. Do not paste them into a live profile. Use the actual destinations displayed by your client, and use the exact syntax supported by your selected core. Some clients expose a rule editor rather than allowing direct YAML changes; in that case, make the equivalent policy-group adjustment in the editor and reload the configuration.

Check the Matched Rule, Not Just the Group Name

A group can be configured correctly while a request never reaches it. The connection detail, matched rule, and final outbound together provide the useful diagnosis. If one of those three is missing, the test is incomplete.

Step Three: Check DNS, Fake-IP, and Resolver Reachability

DNS problems can appear as proxy timeouts because Clash needs an address before it can establish many outbound connections. If a service hostname resolves to an unusable address, resolves inconsistently between direct and proxied paths, or is intercepted by a local network, the browser may keep retrying until it reports a timeout. This is especially confusing when ordinary websites continue to work.

First determine which DNS mode the profile uses. In fake-ip mode, Clash returns an address from the reserved 198.18.0.0/15 range to applications and keeps the real domain-to-IP mapping internally. Seeing such an address in a local lookup is not automatically a failure. In redir-host mode, the application receives the resolved address directly, so a wrong or region-specific answer is more visible to the application.

Inspect the DNS section for three separate concerns. nameserver provides normal upstream resolution, fallback supplies alternative answers when filtering rules reject or distrust the primary result, and default-nameserver bootstraps hostnames used by encrypted DNS servers. Do not place URL-form entries such as DoH or DoT addresses into default-nameserver when the selected core expects plain IP bootstrap resolvers.

Run a lookup for the affected service hostname using the operating system tool and note whether it returns promptly.
Compare the result while Clash is stopped, while system proxy mode is enabled, and while TUN mode is enabled.
Check the Clash DNS or debug log for resolution errors, bootstrap failures, refused queries, and repeated retries.
Temporarily test a known-good resolver path without changing the entire profile. Keep the test short and restore the intended privacy and routing policy afterward.
Reload the configuration after DNS changes, then close and reopen the affected application so it discards cached connections.

Avoid adding a long list of random resolvers. More upstreams do not automatically mean more reliability; they can increase races, inconsistent answers, and troubleshooting noise. Use a small set of reachable resolvers and ensure their traffic is routed in a way that does not depend on the domain being resolved by the same broken path.

Do Not Disable DNS Protection as a Permanent Fix

Turning off Clash DNS handling may make one test appear to work by returning control to the operating system, but it can also bypass your routing policy and recreate local DNS leaks. Use that change only as a controlled comparison, then correct the resolver or interception path instead.

Step Four: Compare System Proxy and TUN Mode

System proxy mode and TUN mode do different jobs. System proxy mode changes the HTTP and SOCKS proxy settings that compatible applications use. It is usually the simplest first test, but an application may ignore those settings, use its own resolver, or open a connection type that the configured system proxy does not capture. TUN mode creates a virtual network interface and can capture more system traffic, including applications that do not understand HTTP proxy settings.

Use a controlled comparison rather than enabling every advanced option at once. Start with system proxy mode and a browser known to honor the operating system proxy. If Gemini works there but fails in TUN mode, inspect TUN-specific settings: auto route, interface detection, DNS hijacking, IPv6 handling, and the selected stack. A malformed route can send traffic into a dead interface, while incomplete DNS hijacking can leave name resolution outside Clash.

TUN Checks on Desktop and Mobile

Windows: approve the driver and firewall permissions, then check whether another VPN or virtual adapter is competing for the default route. Disable competing tunnel software during the test.
macOS: confirm that the network extension or privileged helper is allowed. If the extension is blocked, TUN may appear enabled in the interface while traffic still follows the normal route.
Android: accept the VPN permission prompt and check Android's per-app VPN or bypass list. Battery optimization can also stop the client in the background, interrupting long responses.
Mihomo-based clients: verify that dns-hijack, auto-route, and auto-detect-interface are compatible with the local network. The exact field names and available controls vary by client version.

IPv6 deserves a separate check. If the system prefers IPv6 but the node or rules handle only IPv4, the browser may attempt an unreachable address before falling back. As a diagnostic, compare behavior with IPv6 temporarily disabled or with an explicit IPv4 preference. If that fixes the timeout, do not leave the workaround unexplained; adjust the profile, node capability, or network route so both address families are handled deliberately.

Step Five: Handle Streaming and Long-Lived Requests

Gemini responses are often delivered progressively rather than as one small completed download. That makes connection stability more important than a fast initial page load. A node may complete the TLS handshake and download the interface but reset an idle-looking stream, enforce a short connection lifetime, or lose packets under sustained traffic. Changing the browser alone will not repair an outbound that cannot maintain the response.

For testing, select a single stable node and keep the proxy group from switching automatically. URL-test and fallback groups can change members when their health check changes; that is useful for general browsing but can interrupt an active request. Run a short prompt first, then a longer prompt, and note whether failure occurs during connection establishment, the first response, or continued streaming.

Check the Clash log for connection closed, connection reset, handshake timeout, context canceled, or no-active-connection messages. The wording varies by core and client, but the timing matters. A failure immediately after rule matching points toward routing or DNS. A failure after a predictable number of seconds points more toward node policy, transport quality, or a timeout enforced along the path.

Test result	Interpretation	Recommended next move
All service requests fail on one node	Node or exit-path problem	Choose another node and compare the same request
Page loads, but every prompt stalls	API or streaming destination is misrouted	Inspect connections and add a narrow proxy rule
Short prompts work, long prompts stop	Stream stability or connection lifetime issue	Use a less congested node and disable automatic switching during testing
System proxy works, TUN fails	TUN route, DNS hijack, or adapter conflict	Review TUN settings and competing virtual adapters
Only one browser fails	Browser DNS, extension, or proxy behavior	Test a clean profile and disable browser-level secure DNS temporarily

Browser, Login, and Application-Level Checks

When the network path is healthy but Gemini still reports an error, isolate the browser layer. Open a private window with extensions disabled, or create a temporary clean browser profile. Content blockers, script filters, privacy extensions, and browser-level secure DNS can prevent the interface from contacting a required endpoint even though Clash shows a healthy proxy connection.

Keep the account and service traffic on a consistent exit region during a session. Repeatedly changing regions while a login cookie is being issued can trigger additional verification or cause the application to invalidate a session. This is not fixed by adding more proxy rules. Sign out if necessary, close old tabs, select one tested node, and sign in again through that same route.

On Android and desktop systems, check whether the application is excluded from the VPN or TUN route. A browser opened before the VPN was enabled may retain direct connections until it is restarted. Some applications also use a separate proxy setting, while others ignore the system proxy and require TUN capture. Restart the application after every major routing change and verify its new connections in Clash rather than assuming that the restart used the intended path.

A Clean Reproduction Is Faster Than Random Changes

Use one browser, one account, one node, one proxy group, and one short prompt. Once that combination works, add automatic groups, TUN mode, extensions, and custom rules one at a time. The first change that reintroduces the timeout identifies the layer that needs correction.

A Safe Configuration Workflow

Before editing a profile, export or duplicate the current configuration so that every change can be reversed. Record the active client version, core type, proxy mode, selected node, DNS enhanced mode, and the exact error time. Logs are much easier to interpret when you know which node and mode were active at the moment of failure.

Update the client and mihomo core only if the current versions are clearly outdated or the client reports a known compatibility problem. Do not change client, core, profile, and node simultaneously.
Test a manually selected node with the existing rules. If it works, the automatic group is the first place to investigate.
Inspect the connection list and confirm the actual service destinations and matched outbounds.
Correct DNS resolution and bootstrap behavior, then reload the configuration.
Compare system proxy and TUN mode with all other variables held constant.
Only after the path is known to work, re-enable rule providers, automatic selection, browser extensions, and other advanced features one by one.

When a subscription profile is updated, local rule edits may be overwritten. If your client supports a local override or merge configuration, place the narrow service rules there and document their purpose. Otherwise, keep a small copy of the tested rules so that they can be restored after the next subscription update. Avoid editing generated provider files directly because those changes may disappear without warning.

FAQ: Gemini and Clash Timeouts

Why does Gemini open while sending a prompt times out?

The interface and the prompt request may use different destinations or connection patterns. Check the Clash connection list while submitting a prompt, confirm that the new destinations use the intended proxy group, and test a stable manually selected node. If the route is correct, compare a short and long response to identify a streaming or node-stability problem.

Should every Google-related domain be sent through the proxy?

No. A broad keyword rule can route unrelated traffic and make future troubleshooting harder. Start with the domains observed in the failed request, use narrow suffix or exact-domain rules, and keep those rules above broad regional rules. Authentication may require related destinations, so verify the actual connection log instead of guessing from the page address alone.

Can fake-ip cause Gemini to stop working?

Fake-IP itself is not automatically incompatible. It becomes a problem when DNS hijacking is incomplete, the client bypasses Clash DNS, the profile has an unsuitable fake-IP filter, or an application receives an address it cannot use correctly. Compare fake-ip with redir-host as a controlled test and inspect DNS logs before changing the mode permanently.

Why does system proxy work but TUN mode time out?

This usually points to TUN-specific routing, DNS hijacking, IPv6 preference, firewall permissions, or a competing VPN adapter. Review auto-route, interface detection, DNS interception, and the application bypass list. Keep system proxy mode as a temporary working baseline while correcting the TUN path.

Final Checklist Before Replacing the Profile

Use the following order when Gemini still reports a timeout: select a known-good node, verify that the active connection enters Clash, inspect the matched rule, confirm DNS resolution, compare system proxy with TUN, and test a clean browser session. If the failure follows every node and every mode, check the account or service status separately. If it follows only one node, one group, one browser, or one routing mode, keep the rest of the configuration and fix that specific layer.

The most reliable solution is usually a small correction: a service destination moved from DIRECT to the intended proxy group, a resolver path repaired, a TUN permission restored, or an unstable automatic node replaced. Keeping the change narrow preserves working domestic routes, reduces side effects, and makes the next timeout much easier to diagnose.