Fix Gemini Not Working With Clash: Timeout Troubleshooting

Why Gemini Times Out With Clash

Gemini may stop loading, display a connection error, or remain stuck on a blank page when it is used through Clash. In many cases, the problem is not that Gemini is permanently unavailable and not necessarily that your subscription has expired. The more common explanation is that the request is taking an unexpected route, matching a rule that sends it DIRECT, or reaching Google through a node that is slow, overloaded, or unsuitable for AI services.

Gemini is not a single-domain application. A normal session can involve the main Gemini website, Google account authentication, API endpoints, static assets, security checks, WebSocket connections, and content delivery domains. If only one part of this traffic is proxied, the page may open but fail after login. If DNS resolution is inconsistent, Gemini may resolve to an unreachable address even though other websites work normally. A timeout therefore needs to be diagnosed as a routing problem rather than solved by repeatedly switching random nodes.

This guide provides a structured troubleshooting process for Clash Verge, Clash Verge Rev, Mihomo, and other Clash-compatible clients. You will first identify whether Clash is actually handling Gemini traffic, then verify domain rules, DNS behavior, node quality, and browser-side state. The goal is to change one variable at a time so that you know exactly which fix worked.

1Identify What Is Actually Failing

Start by describing the symptom precisely. Different symptoms point to different layers of the connection. If gemini.google.com never opens and the browser reports a timeout, routing, DNS, or node reachability is the first suspect. If the page opens but the sign-in screen loops, authentication traffic may be using a different route. If you can sign in but messages never receive a response, the selected node may be unstable or a required API connection may be blocked.

Before editing YAML, perform a short baseline test. Open the Clash dashboard and confirm that the system proxy or TUN mode is enabled. Then visit Gemini in a private browser window. At the same time, watch the Connections, Logs, or Requests panel in your client. Search for domains containing google, gemini, or gstatic. The exact panel name differs between clients, but the principle is the same: you need to see which policy group handled the request.

• No Gemini-related request appears: the browser may be bypassing Clash, the system proxy may be disabled, or another VPN and proxy application may be taking control.
• The request appears as DIRECT: a rule is bypassing the proxy, or the final catch-all rule is not what you expected.
• The request uses a proxy group but times out: test another node and inspect latency, packet loss, and connection errors.
• The website loads but authentication fails: check Google account domains, cookies, DNS consistency, and whether the browser is mixing direct and proxied connections.
• Only one browser fails: extensions, cached service workers, secure DNS, or browser proxy settings may be overriding the client configuration.

2Confirm That Gemini Uses the Proxy

The most frequent cause of a Gemini timeout is a routing decision that sends the request outside Clash. Rule-based clients do not automatically know that every Google service should use a proxy. A profile may contain a broad DOMAIN-SUFFIX,google.com,DIRECT rule, a regional rule provider may classify a domain incorrectly, or a privacy rule may appear before your custom Gemini rule. Clash evaluates rules from top to bottom, so the first matching rule wins.

Inspect the Connection Logs

Open Gemini and monitor the request list while refreshing the page. Click a relevant connection and check its destination, process, and policy. The policy should normally be a proxy group rather than DIRECT when direct access to Gemini is unavailable on your network. Do not rely only on the dashboard's global mode indicator; global mode can still be affected by TUN exclusions, browser-specific proxy settings, or an application bypass list.

On Windows, verify that the browser is not configured with a separate manual proxy. On macOS, check both the system network proxy and any browser extension that manages proxy profiles. If TUN mode is enabled, avoid running a second VPN at the same time because two virtual adapters can produce loops, inconsistent DNS results, or traffic that never reaches the Clash core. Temporarily disable other network tools during testing.

Add Explicit Gemini Rules

If the logs show DIRECT or an unexpected policy, place explicit rules above broad Google, region, advertising, or final matching rules. The following example is a starting point for a Mihomo-compatible YAML profile:

Replace Gemini with the name of an existing proxy group in your profile. Do not paste this block blindly if that group does not exist. You can instead use a stable group such as Proxy or the provider's automatically generated select group. The purpose of the rules is not to proxy every Google domain forever; it is to create a clear test path. Once Gemini works, you can reduce the list and observe which domains are genuinely required.

3Fix DNS Resolution and Fake-IP Conflicts

DNS is another common reason for a timeout. The browser first needs an IP address for each hostname, and the resolver used by Clash may return a result that is filtered, hijacked, stale, or unreachable from the selected node. A page can therefore fail before the proxy has an opportunity to establish a normal connection. DNS problems are especially confusing when the main Gemini hostname resolves correctly but an authentication or static-content hostname does not.

Review the DNS Settings

In Clash Verge Rev or another Mihomo client, open the active profile and inspect the DNS section. A practical configuration for testing can look like this:

This example is intended for diagnosis, not as a universal profile. Your provider may already supply a DNS section, and duplicating incompatible keys can produce unexpected behavior. If your network or client has trouble with HTTPS DNS, test the provider's recommended resolvers instead. The important points are that Clash should handle the lookup, the DNS behavior should be consistent with your proxy mode, and the selected resolver should not return unusable regional results.

Clear Cached DNS State

After changing DNS settings, reload the profile and restart the Clash core. Then close and reopen the browser. On Windows, you can flush the operating system cache with:

In fake-IP mode, some applications retain old mappings until their connections are closed. Use the client's connection panel to close existing Gemini and Google connections, or restart the client if the panel does not provide a reliable clear function. If fake-IP causes the browser or another Google application to malfunction, test redirection-host mode or add an appropriate fake-IP filter according to the profile's documentation. Do not assume that fake-IP is automatically better in every environment.

4Choose a Stable Node for Gemini

If routing and DNS are correct, the node itself becomes the leading suspect. A node can show a low ping in a Clash delay test and still fail to load Gemini. ICMP latency measures only a limited part of the path; it does not guarantee that HTTPS, long-lived connections, authentication requests, or Google services will work. A heavily shared address may also be rate-limited or have a poor reputation.

Test several nodes from different locations while keeping the same rules and DNS configuration. For every test, record whether the page loads, whether sign-in completes, and whether a short prompt receives a response. Useful selection criteria include:

• Stable HTTPS connections: the node should complete repeated connections without resets or handshake timeouts.
• Low packet loss: a slightly higher but stable latency is usually better than a fast node with frequent interruptions.
• Reasonable geographic location: select a region where Gemini is officially available and avoid unnecessary long-distance routing.
• Clean IP reputation: if one node repeatedly triggers verification or fails while others work, the address may be blocked or overcrowded.
• Suitable protocol support: ensure the Mihomo core supports the node's protocol and that TLS, SNI, and transport parameters are imported correctly.

If every node fails in the same way, the issue is probably not node quality alone. Return to rule matching, DNS, system proxy status, and account or regional requirements. If only one node fails, remove it from the active group or ask the provider whether the address is temporarily restricted.

5Validate the Browser, Client, and Final Fix

Once Gemini begins to load, verify that the solution is stable rather than accepting a one-time success. Browser state can hide the real result. An old cookie may preserve a failed session, while a browser extension may silently route only some requests. Test in a private window first, then repeat in your normal profile after confirming that the connection is healthy.

Reset Local Browser State Carefully

Disable proxy-switching extensions temporarily and turn off browser-level secure DNS if it is bypassing the resolver behavior you are testing. Clear cookies and site data for Gemini and Google authentication only when necessary; signing out of every Google service can create additional verification steps. Also check that the system clock is accurate, because incorrect time can cause TLS and account authentication failures that look like network timeouts.

For a clean comparison, test three addresses separately: https://gemini.google.com, the Google sign-in page, and a simple static Google resource. Observe each request in Clash. If the main page is proxied but sign-in is DIRECT, add or correct the authentication rule. If all requests are proxied but only one node fails, keep the rule set unchanged and switch nodes. This method isolates the failing layer without unnecessary profile changes.

Make the Fix Permanent

After identifying a working configuration, document the changes. Save a backup of the profile before editing it, especially if the profile is generated from a subscription. Subscription updates can overwrite manual rules, so use the client's profile manager, a merge configuration, or a provider-supported override when available. Keep custom rules near the top and add a comment explaining why they exist.

Finally, restart the core, confirm the selected policy group, and run the same complete-session test again. A successful result means more than a page opening: Gemini should load repeatedly, authentication should remain available, and a prompt should receive a response without repeated timeout messages. If the service later stops working, compare the current node, profile version, DNS configuration, and rule logs with your recorded baseline. That comparison is much faster than starting from scratch.