Why "Gemini Won't Load" Happens: Web UI and AI Studio Hit Different Host Groups

The browser-based Google Gemini (gemini.google.com and nearby hosts) fires concurrent requests to authentication, assets, telemetry, and global CDN edges alongside the conversation UI itself. Google AI Studio adds editor state, model listings, preview calls, and billing/quota checks—most of which resolve through ai.google.dev and related domains. When you include the Generative Language API (generativelanguage.googleapis.com and friends) called from SDKs or backend code, you end up with a topology where the page may render while the API times out: classic partial success.

A Clash split routing setup that "mostly works" can amplify this: broad GEOIP rules absorb some hosts before your specific rules fire, or a fast-cycling url-test group reassigns the outbound mid-session. The page stalls, the stream cuts, and it looks like a server outage. DNS pollution and DoH configuration are covered in the companion DoH guide; this article focuses on domain grouping and policy design.

💡
Scope of this guide OpenAI traffic is covered in the ChatGPT and OpenAI API guide; Anthropic in the Claude routing guide. This article is scoped to Google AI domains and how to split the web UI from AI Studio and API traffic.

Three Surfaces: Chat Web, AI Studio, and the API

Thinking in surfaces simplifies configuration. First, the chat web UI used by most end users. Second, Google AI Studio for prompt engineering, key management, and previews. Third, the Generative Language API powering SDK and server-side workloads. All three use HTTPS, but the hostnames and the acceptable exit region may differ. For example, you might prefer a low-latency node for the conversation UI, a stable US node for AI Studio where billing is anchored, and a separate policy for API calls that aligns with your quota region.

Hostname lists shift with product updates, so treat your connection logs as ground truth rather than relying on static community lists alone. Common starting candidates are gemini.google.com, OAuth and asset subdomains under google.com, ai.google.dev, generativelanguage.googleapis.com, and potentially *.googleapis.com or *.gstatic.com. Avoid widening suffixes beyond what logs confirm—googleapis.com is shared with BigQuery and other cloud APIs that may have different routing needs.

YAML Example: Separate Web and AI Studio Policy Groups

The snippet below is a conceptual starting point. Replace node and proxy-provider names with your own.

proxy-groups:
  # Browser Gemini (consumer chat UI)
  - name: GEMINI-WEB
    type: select
    proxies:
      - JP-GEMINI-WEB
      - US-GEMINI-WEB
      - DIRECT
  # Google AI Studio (developer console)
  - name: AI-STUDIO
    type: select
    proxies:
      - US-AISTUDIO-STABLE
      - JP-AISTUDIO-STABLE
      - DIRECT
  # Generative Language API (SDK / server)
  - name: GEMINI-API
    type: select
    proxies:
      - US-GEMINI-API
      - DIRECT

rules:
  # Place these BEFORE broad GEOIP / MATCH rules
  - DOMAIN-SUFFIX,gemini.google.com,GEMINI-WEB
  - DOMAIN-SUFFIX,ai.google.dev,AI-STUDIO
  - DOMAIN-SUFFIX,generativelanguage.googleapis.com,GEMINI-API
  # Optional: widen only after log evidence
  # - DOMAIN-SUFFIX,googleapis.com,GEMINI-API
  # ... GEOIP / MATCH ...

Because googleapis.com is shared across Google Cloud services, start with specific API subdomains and expand only when logs reveal missing hostnames. To survive subscription refreshes without rewriting rules, use prepend-rules or a merge layer as described in the Clash Meta overrides guide.

Fixed Nodes and Policy Groups: Don't Rely Solely on Health Checks

Long-lived TLS connections and streaming responses are vulnerable to mid-session node switches. A tight url-test group that re-evaluates every few seconds can flip the outbound while a response body is still transferring—producing handshake interruptions and retry bursts that users experience as "Gemini not loading" or "AI Studio stalling." The node quality is fine; the routing churn is the culprit.

A practical fix is to use a select group with one verified node for debugging, then graduate to a fallback group with a generous probe interval once you have a stable baseline. If you need multi-region coverage, start by fixing a single region and confirming symptoms disappear before re-introducing automatic selection. Watch the connection logs: if the node name changes during a failed request window, the churn is confirmed.

Rule Order and Partial Success: Prevent Hosts from Slipping Through

The most common failure pattern: a broad GEOIP,CN,DIRECT rule or catch-all appears early in the chain, and Google AI rules are buried beneath it. Depending on how DNS resolves, some subdomains land on DIRECT while others hit the proxy—so the tab opens but AI Studio API calls time out, or the chat UI renders but streaming stops. The fix is structural: put specific domain rules before broad geo rules.

The general split-routing framework for domestic DIRECT and overseas PROXY is covered in the split routing strategy guide. Think of the Google AI rules here as a narrow layer inserted on top of that base configuration. Logs are more reliable than YAML reading for confirming the actual match order at runtime.

DNS, fake-ip, and SNI: Eliminate Name-to-Route Mismatches

In fake-ip mode, the relationship between the hostname shown in the UI and the actual transport destination is indirect. A rule that appears to match may still route traffic unexpectedly when the fake IP mapping doesn't align with your domain rules. During debugging, disable the browser's built-in Secure DNS to avoid competing with Clash DNS and creating a double-resolver conflict. For a mode comparison, see the fake-ip vs redir-host article.

HTTPS requires that the SNI in the ClientHello matches the server's certificate. Enterprise HTTPS inspection, transparent proxies, or browser extension filters operating between you and Clash can introduce mismatches that look like random connection failures on Google AI services. When symptoms appear, test with a minimal configuration—Clash only, extensions disabled—to isolate whether the failure is above or below the Clash layer. TLS-specific patterns overlap with the Claude SNI guide for general reference.

Ops Notes: Single Account, Multiple Exits, and Log Hygiene

Accessing the same Google account from geographically distant exits in a short window can trigger re-authentication prompts or additional verification steps. If you use different nodes for AI Studio and the chat UI, consider aligning them to the same region first and observing whether the friction decreases. Outside of legitimate technical needs, routing patterns that circumvent regional policies may conflict with Google's terms of service—use good judgment.

For efficient triage, filter logs by hostname and record the policy name and actual node together. When sharing debug output with teammates, scrub API keys and personal identifiers, and map rule line numbers to the corresponding YAML blocks so the same pattern can be reused when the same issue recurs.

TUN and System Proxy: Align Browser and CLI on the Same Path

Browsers follow the OS proxy or TUN mode capture. CLI tools and scripts typically need HTTPS_PROXY or ALL_PROXY set explicitly, and they must point to the correct loopback address and mixed-port. When routing from WSL or Docker to a host-side Clash, also verify that DNS resolution isn't stalling inside the container before the request ever leaves. See the WSL2 guide for host-IP and environment-variable specifics.

The shared principle across all capture layers: distinguish "latency" from "host slipping to DIRECT" by reading rule hits. When long streams cut mid-response, suspect per-host rule gaps before blaming node quality.

⚠️
Legal and terms compliance Follow the network policies of your access environment, applicable local regulations, and Google's terms of service. This article is reference material for aligning traffic to its intended path in environments where you have legitimate access rights.

Troubleshooting Checklist by Symptom

Chat web UI is unstable but AI Studio loads

Confirm in logs that gemini.google.com and OAuth/asset neighbors are hitting GEMINI-WEB. Check whether a broad rule is absorbing them first. Temporarily fix the node to a single value and retest for reproducibility.

AI Studio stalls or partially loads

Prioritize confirming that ai.google.dev and any related hostnames from your logs are landing on AI-STUDIO. Mixing API and Studio traffic into the same policy can push requests to unintended exits.

API calls time out from CLI or SDK

Verify that generativelanguage.googleapis.com and logged variants are matching GEMINI-API and not falling through to DIRECT. Cross-reference DNS resolution with the DoH companion guide if the resolver path is suspect.

Summary: Group, Pin, and Verify

In 2026, Google's AI surfaces remain split across distinct host groups—chat web, AI Studio, and the Generative Language API each resolve differently and tolerate different exit characteristics. This guide organized them into separate Clash policy groups, showed how to pin a fixed node to suppress routing churn, and walked through rule ordering to prevent partial-success failures. DNS and DoH design are delegated to the companion article, keeping this one focused on domain grouping and policy architecture.

If you haven't set up a client and subscription yet, grab a maintained build from our download page and import your subscription following the subscription URL guide, then layer these Google AI rules on top. → Download Clash for free and route Gemini and AI Studio traffic the way you intend