Gemini 3 With Clash: China Access and Routing Setup Guide

Gemini 3 can be difficult to use from mainland China when access, login, or API requests depend on domains that are not consistently reachable on the local network. A proxy client may appear to be running correctly while Gemini still shows a blank page, rejects sign-in, or fails during a long API request. In most cases, the problem is not solved by simply turning on the global proxy mode. You need a valid Clash subscription, a suitable proxy group, reliable DNS handling, and rules that send Gemini-related traffic through the intended route. This guide explains how to set up Gemini 3 with Clash in a practical way, without requiring you to understand every advanced proxy term.

Understand the Access Problem Before Changing Settings

Gemini is not a single-domain service. The web interface, Google account login, static assets, API endpoints, safety checks, and authentication flows may use different hostnames. A browser can successfully open one page while a background request to another domain fails. This is why a simple test such as “the Gemini homepage loads” does not always prove that the whole service is working.

There are usually four separate connection stages:

• DNS resolution: your device must resolve the correct address for each Gemini or Google endpoint.
• TCP and TLS connection: the selected node must establish a stable encrypted connection to the remote service.
• Account authentication: Google login may redirect through several domains and may require cookies, JavaScript, and accurate system time.
• Streaming or API traffic: Gemini responses can remain open for a long time, so an unstable node may work for a short page load but fail during generation.

These stages also explain why different symptoms require different fixes. A DNS failure should not be treated as a bad password. A login loop may be caused by blocked authentication resources rather than by the Gemini route itself. A response that stops halfway through generation often points to packet loss, node overload, or an idle timeout.

Clash does not provide network access by itself. It is a routing client and rule engine. You still need a lawful, trusted subscription or a proxy server that you are authorized to use. The subscription must contain nodes that can reach the required services, and the client must support the proxy protocols used by those nodes. Clash Verge, Clash Verge Rev, Mihomo-based clients, Clash for Android, and other compatible clients may expose slightly different menus, but the underlying logic is similar.

Import a Subscription and Confirm the Client Is Ready

The fastest setup method is normally to import a subscription URL supplied by your provider. A subscription is a remote configuration that can contain proxy nodes, proxy groups, rules, and DNS settings. It is more convenient than entering every server manually, but it also means that the provider controls much of the configuration. Read the provider's privacy and usage terms, and avoid subscription URLs obtained from unknown public posts.

1. Open your Clash client and find the Profiles, Profiles Management, or similarly named page.
2. Paste the subscription URL into the import field, then select Import or Download.
3. Wait until the profile finishes downloading. If the request fails, check whether the subscription URL itself is reachable and whether another network tool is interfering.
4. Activate the imported profile. Downloading a profile is not the same as using it; the active profile must be marked as selected.
5. Open the proxy or connections page and confirm that at least one node is visible.
6. Select a node manually before enabling automatic selection. This gives you a known starting point for troubleshooting.

On Clash Verge or Clash Verge Rev, names such as Profiles, Proxies, and Rules are usually visible in the main navigation. On Clash for Android, the equivalent controls may be under the profile, proxy, or dashboard tabs. Mihomo-based clients can expose additional features such as TUN mode, rule providers, and fake-IP DNS. Do not enable every advanced feature at once. First confirm that ordinary proxy traffic works.

Profile: downloaded and active
Node: selected manually
Mode: Rule
System proxy: enabled for browser testing
TUN: disabled during the first test
DNS: Clash-managed DNS enabled
Browser: no second VPN or proxy extension active

Use Rule mode for a normal Gemini setup. Global mode sends nearly all traffic through the selected node, which can be useful for a short diagnostic test but is inefficient for daily use. Direct mode bypasses the proxy and is expected to fail when the required service is not reachable directly. If Gemini works only in Global mode, that is a useful clue: the node is probably fine, but the rule list does not cover all required domains.

System proxy mode is enough for many desktop browsers. TUN mode is more comprehensive because it can capture applications that do not respect the operating system's HTTP or SOCKS proxy settings. However, TUN also affects DNS, local network access, games, package managers, and other applications. Enable it only after the basic browser test works, and check for conflicts with another VPN, firewall, antivirus filter, or virtual network adapter.

Build Reliable Gemini Routing Rules

The purpose of a Gemini rule is simple: traffic for the service and its authentication dependencies should be sent to a proxy group, while private addresses, local services, and ordinary domestic traffic should remain direct. The exact domains can change as Google updates its infrastructure, so avoid assuming that one visible hostname represents the entire service.

A practical rule strategy has three layers:

• Private and local networks first: keep localhost, LAN devices, and internal domains direct so that local services continue to work.
• Explicit service rules next: send Gemini and relevant Google account traffic to a dedicated proxy group.
• General fallback last: decide whether unmatched traffic should use a broader proxy group or go directly.

Rule order matters. Clash processes rules from top to bottom and uses the first matching rule. If a broad rule appears before a specific Gemini rule, the specific rule may never be reached. Likewise, putting a final MATCH,DIRECT line before service rules will send everything direct.

rules:
  - DOMAIN-SUFFIX,gemini.google.com,Gemini-Proxy
  - DOMAIN-SUFFIX,ai.google,Gemini-Proxy
  - DOMAIN-SUFFIX,googleapis.com,Gemini-Proxy
  - DOMAIN-SUFFIX,gstatic.com,Gemini-Proxy
  - DOMAIN-SUFFIX,googleusercontent.com,Gemini-Proxy
  - DOMAIN-SUFFIX,accounts.google.com,Gemini-Proxy
  - DOMAIN-SUFFIX,google.com,Gemini-Proxy
  - DOMAIN,localhost,DIRECT
  - GEOIP,PRIVATE,DIRECT,no-resolve
  - MATCH,DIRECT

This is an illustrative starting point, not a universal domain list. Sending every Google domain through a proxy can increase latency and may cause unexpected behavior for services you want to use directly. Conversely, sending only gemini.google.com through the proxy may not be enough if login or API requests use another host. Watch the connection log while opening Gemini and signing in. Any failed request associated with the login or generation flow should be evaluated before adding a new rule.

For API users, the hostname depends on the API product and SDK. A browser-based Gemini session and an application using a Google AI API may not use the same endpoint. Read the official SDK documentation for the endpoint you are authorized to call, then add a narrow domain rule instead of blindly proxying all traffic. Keep API keys out of Clash configuration files that may be uploaded or shared.

Choose a Proxy Group That Matches the Task

A manual select group is best for initial troubleshooting because you can compare nodes without the client silently switching between them. After you find a stable node, a url-test group can automatically select a low-latency option. Low ping alone does not guarantee a good Gemini experience: long-lived HTTPS requests, throughput, packet loss, and regional reachability are also important.

proxy-groups:
  - name: Gemini-Proxy
    type: select
    proxies:
      - Auto-Select
      - node-us-01
      - node-jp-01
      - DIRECT

  - name: Auto-Select
    type: url-test
    proxies:
      - node-us-01
      - node-jp-01
      - node-sg-01
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80

Replace the example node names with names that actually exist in your profile. If the imported configuration already defines a proxy group with a similar purpose, reuse it rather than creating duplicate groups. A duplicate group can make rule management confusing and may not contain the nodes you expect.

Configure DNS and TUN Mode Carefully

DNS is often the hidden reason that a rule appears correct but does not work. If the device resolves a domain incorrectly before Clash can apply a domain rule, the connection may be sent to the wrong address or fail before the proxy is involved. Mihomo generally works well with fake-ip DNS and TUN mode, but compatibility should be tested rather than assumed.

A cautious DNS configuration can look like this:

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query
  fallback:
    - https://8.8.8.8/dns-query
  fake-ip-filter:
    - +.lan
    - localhost.ptlogin2.qq.com

Configuration keys and accepted behavior can vary between Clash versions and Mihomo builds. If the client reports an unknown field, use the syntax documented by that client instead of copying the example unchanged. Some desktop clients manage DNS internally, while others expose a complete YAML editor. After changing DNS, restart the core or reload the profile and clear the DNS cache when the client provides that option.

Fake-IP mode returns a reserved placeholder address and keeps an internal mapping between that address and the original domain. This allows Clash to apply domain rules more reliably. Certain games, local discovery tools, banking applications, and older software may not behave well with fake IP. If only one application breaks after enabling it, add a narrowly targeted fake-IP filter or switch that application to a compatible mode instead of disabling DNS protection globally.

TUN mode is useful when the browser or application ignores system proxy settings. Enable it after confirming the service works through ordinary system proxy mode. On Windows, check that no other virtual adapter is active. On macOS, approve the requested network extension. On Android, remember that only one VPN-style service can usually own the system VPN slot at a time. If enabling TUN causes all network access to stop, turn it off first, then inspect the core log and permissions.

Test Login, API Requests, and Streaming Separately

After importing the profile and applying rules, test the workflow in stages. First open the Gemini page. Then sign in or open an existing session. Finally send a short prompt and a longer prompt. Each stage checks a different part of the route.

1. Open Clash's connection log and clear old entries.
2. Select one node in the Gemini-Proxy group.
3. Open the Gemini website and observe which domains are contacted.
4. Confirm that those requests match the intended proxy rule rather than DIRECT.
5. Sign in and watch for redirects that fail or repeat continuously.
6. Send a short prompt, then test a response that takes longer to generate.
7. Repeat with a second node without changing the rules.

If the page is blank, inspect blocked JavaScript, static content, and DNS requests. If login loops, keep the browser clock correct, temporarily disable privacy extensions that block Google cookies, and verify that all authentication requests use the same stable route. Avoid switching countries or nodes repeatedly during one login session because unusual location changes can trigger additional account verification.

If a response starts correctly and then stops, compare nodes using the same prompt. A node with slightly higher latency but lower packet loss may perform better than the lowest-ping node. Also check whether the client, operating system, router, or upstream provider has an idle timeout. Streaming connections need a stable path for the entire response, not merely a successful handshake.

For API troubleshooting, make sure the application inherits the proxy settings you configured. Many command-line tools and SDKs do not automatically use a desktop system proxy. Depending on the library, you may need to configure an HTTP proxy, SOCKS5 proxy, or a local TUN route in the application itself. Never paste an API key into a public issue, a shared YAML profile, or a screenshot of the terminal.

Common Failures and Practical Fixes

• Gemini opens but assets are missing: check the connection log for blocked Google static-resource domains and move the matching rules above the final catch-all rule.
• Login keeps returning to the sign-in page: use one stable node, verify the device clock, clear affected cookies, and check whether account-related domains are being sent direct.
• Only Global mode works: your node is probably reachable, but Rule mode lacks one or more service rules. Use the log to identify the missing domain.
• Every domain resolves to a strange address: inspect fake-IP and DNS settings, then confirm that no second DNS service or VPN is intercepting requests.
• One application fails while the browser works: the application may ignore system proxy settings. Test TUN mode or configure the application's proxy support directly.
• Nodes show low delay but Gemini is unstable: latency tests are not the same as sustained streaming tests. Try a different region or a fallback group and compare packet loss.
• The profile imports but no nodes appear: the subscription may have expired, require authentication, or return an incompatible format. Recheck the URL and the client's core compatibility.
• Rules seem correct but old behavior remains: reload the profile, restart the Clash core, flush DNS where appropriate, and create a new browser test session.

Keep changes small and reversible. Record which node, mode, DNS setting, and rule change produced an improvement. This simple habit prevents a temporary success from becoming an unrepeatable configuration.

FAQ: Gemini 3 and Clash

Do I need Global mode to use Gemini 3?

No. Global mode is useful as a short diagnostic test, but Rule mode is better for daily use. A dedicated Gemini proxy group can route only the required service and authentication traffic while keeping local and ordinary traffic direct.

Why does Gemini load while Google login fails?

The login flow may use additional Google domains, cookies, redirects, and security checks. Watch the Clash connection log during sign-in and make sure those requests follow the same stable proxy route. Also verify system time and temporarily test without extensions that block scripts or cookies.

Is TUN mode required?

Not for most desktop browser tests. System proxy mode is usually sufficient when the browser respects HTTP or SOCKS settings. TUN mode becomes useful for applications that ignore those settings, but it introduces more variables and should be enabled only after the basic route works.

Which node is best for Gemini?

There is no permanent universal answer. Choose a node with stable access to the service, low packet loss, acceptable response time, and reliable long-lived connections. Test several nodes with the same prompts, then use manual selection or a carefully tuned url-test group.

A reliable Gemini 3 setup is built by separating the problem into layers: confirm the subscription, choose a known-good node, route service and login domains explicitly, configure DNS conservatively, and test streaming behavior rather than only page loading. Once the route is stable, you can enable TUN mode, automatic node selection, or more advanced rule providers one feature at a time. This approach keeps the configuration understandable and makes future troubleshooting much faster.