Google AI Studio Clash Setup Guide for Stable Access

Why Google AI Studio Needs More Than a Global Proxy

Google AI Studio is a browser-based workspace for testing Gemini models, experimenting with prompts, reviewing generated code, and connecting prototypes to the Gemini API. When the service is available in your region, it can feel deceptively simple: open the site, sign in with a Google account, select a model, and start chatting. When access is restricted or the connection is unstable, however, the failure rarely appears as one clear error. The page may remain on a loading screen, the model selector may stay empty, a prompt may return a generic network error, or a long response may stop halfway through generation.

A common reaction is to switch Clash to Global mode and send every connection through the same proxy. That can prove whether a proxy is needed, but it is not always a good permanent configuration. Google AI Studio uses several related services for authentication, static assets, API requests, telemetry, model metadata, and streaming responses. Some of these hosts may work through a direct connection while others require a stable proxy path. Sending everything through a distant or overloaded node can add latency, create account verification loops, or make ordinary Google services slower.

The more reliable approach is rule-based routing. Keep local traffic and services that already work on DIRECT, then route the Google AI and Gemini-related destinations through a predictable proxy group. This guide focuses on the practical workflow: prepare a Clash profile, confirm the mixed port, choose a suitable mode, add focused domain rules, test DNS and streaming behavior, and troubleshoot the most common browser-side problems.

Prepare a Stable Clash Profile Before Testing

Start with the profile rather than the browser. In Clash Verge Rev, Clash Verge, or another Mihomo-based client, open the Profiles page and import the subscription URL supplied by your provider. Prefer an HTTPS subscription link copied from the provider’s account dashboard. Avoid pasting a URL from an untrusted forum post, because a profile can contain proxy servers, external rule providers, DNS settings, and potentially unsafe routing behavior. After the profile appears, click it to make it active, then wait until the client finishes parsing all proxies and proxy groups.

Next, open the proxy selection page and test several nodes instead of choosing the first item in the list. For AI work, a low ping value is useful but not sufficient. Gemini responses can remain open for a long time, so a node that answers a short latency test may still be poor at maintaining a streaming connection. Check whether the node has stable packet delivery, reasonable download speed, and enough capacity during the hours when you normally use AI Studio. A nearby node with consistent performance is often better than a very distant node that occasionally reports a slightly lower ping.

Confirm the local listener used by applications on your computer. Many Clash installations use 7890 for a mixed HTTP and SOCKS port, although the actual value may be different. In the client’s settings, look for Mixed Port, HTTP Port, or SOCKS Port. A mixed port is convenient because browsers and command-line tools can use the same endpoint with the appropriate protocol. Do not assume that a port number shown in an old tutorial still matches your installation.

If the profile uses TUN mode, treat it as an additional routing layer rather than a replacement for clear rules. TUN can capture applications that ignore the operating system proxy, but it also makes DNS behavior, virtual IP ranges, and bypass settings more important. For a first test, keep the configuration simple: use a normal system proxy or mixed-port browser path, confirm that AI Studio works, and only then enable more advanced TUN or fake-IP options.

Choose the Google AI and Gemini Routing Rules

Clash evaluates rules from top to bottom. The first matching rule wins, so a broad rule placed above your AI-specific rules can send traffic to the wrong group. A focused configuration normally places local and private network exceptions first, followed by the destinations that need the proxy, and finally a general fallback such as MATCH,DIRECT or MATCH,Proxy, depending on your privacy and connectivity goals.

Google changes infrastructure over time, and no short domain list can guarantee coverage for every account or feature. Still, the following domains are commonly relevant when opening AI Studio and using Gemini-related services:

• aistudio.google.com for the main Google AI Studio web application.
• ai.google.dev for developer documentation, examples, and related landing pages.
• generativelanguage.googleapis.com for Gemini API requests made by applications and development tools.
• accounts.google.com for Google account authentication and session flows.
• googleapis.com and selected Google API hosts used by supporting services.
• gstatic.com or other Google static-content hosts when scripts and interface assets are loaded separately.

Do not blindly proxy every Google domain just because one AI Studio request failed. Google Search, Gmail, Drive, YouTube, authentication, and developer APIs can use different endpoints and may have different latency requirements. A practical first layer is to route the explicit AI Studio and Gemini API hosts through the same stable proxy group, then add authentication or asset domains only if the browser log shows that they are failing through the direct path.

rules:
  - DOMAIN,aistudio.google.com,AI
  - DOMAIN,ai.google.dev,AI
  - DOMAIN,generativelanguage.googleapis.com,AI
  - DOMAIN-SUFFIX,googleapis.com,AI
  - DOMAIN,accounts.google.com,AI
  - MATCH,DIRECT

The group name AI in this example is only a placeholder. Replace it with the name used by your profile, such as Proxy, Google AI, or a provider-managed group. If your profile already includes rule providers, inspect their ordering before adding local rules. A provider rule set placed above your custom entries may override them; a provider rule set placed below a broad GEOIP or MATCH rule may never be reached.

Configure Browser Proxy and DNS Behavior

There are two main ways for a desktop browser to use Clash. The first is the system proxy switch exposed by the Clash client. This is convenient for browsers and many desktop applications, but it may not affect every process. The second is TUN mode, which operates closer to the network layer and can capture applications that ignore system proxy settings. For Google AI Studio in a normal desktop browser, system proxy plus Rule mode is usually the easiest baseline. Enable TUN only when you have a specific application that cannot follow the mixed port or when your setup requires process-wide capture.

Browser extensions that change proxy behavior can interfere with Clash. If Chrome or Edge has a proxy extension installed, disable it temporarily while testing. Multiple proxy layers can produce confusing results: the browser may send a request to one local port while Clash expects another, or the extension may bypass the system proxy for selected domains. Private browsing mode is useful for isolating stale cookies and extensions, but remember that Google account login can still be affected by security checks and device recognition.

DNS deserves equal attention. With ordinary system-proxy mode, the browser may resolve a hostname locally before sending the connection through Clash. If the DNS response is blocked, poisoned, or inconsistent with the selected route, the proxy node itself may never receive a usable request. Mihomo configurations commonly offer redirection, fake-IP, or enhanced-mode DNS options. These can improve consistency, but changing several DNS settings at once makes diagnosis harder. Record the original values, change one layer at a time, and restart Clash after a major DNS modification.

If you use fake-IP mode, check that the browser and operating system are not applying a conflicting DNS policy. Also review the fake-IP filter list. Some Google authentication or local-network domains may need to remain excluded, while AI Studio and API hosts should not be accidentally forced into a bypass list. A synthetic address by itself is not an error; the important question is whether the final connection is mapped back to the intended hostname and routed through the correct proxy group.

After changing DNS, clear only the caches that are relevant to the test. Restarting the browser can discard an old connection pool, while flushing the operating system DNS cache can remove stale answers. Do not repeatedly delete all Google cookies as a first response, because that can trigger additional sign-in verification. First capture the symptom, test the route in Clash, and then clear browser data if the evidence points to a session problem rather than a network problem.

Test AI Studio with a Controlled Workflow

Open Google AI Studio only after the Clash profile, node, rules, and browser path are ready. Use a new tab and watch the Clash connection or request log while the page loads. You should see requests for the AI Studio host and supporting Google services. Select the matching entries and verify which rule and proxy group handled them. If the page opens but the log shows that the important requests were sent DIRECT, your browser is probably not using the expected proxy or a higher-priority rule is taking precedence.

Test in stages rather than submitting a complicated prompt immediately. First confirm that the landing page and account session load. Then open a simple prompt, ask for a short response, and observe whether the model returns a complete answer. Finally, test a longer response or code generation task that keeps the connection open for more time. This progression distinguishes DNS and authentication failures from streaming instability. A setup that handles the first page but fails only on long responses usually points to node quality, connection reuse, timeout behavior, or an overloaded proxy group.

1. Check the page: Confirm that the interface loads without a blank model selector or repeated refresh loop.
2. Check the session: Sign in only when the account page and AI Studio page are using a consistent route. Switching nodes during login can trigger additional verification.
3. Check a short prompt: Use a simple request that should produce a small answer. Confirm that the response begins and finishes.
4. Check streaming: Send a longer request and watch for pauses, truncated output, or a connection error after several seconds.
5. Check the log: Match the failed request to its hostname, rule, node, and error type before editing the YAML.

For developers using the Gemini API, test the API path separately from the AI Studio website. A browser can work while a local script fails because the script does not inherit the system proxy. Conversely, a command-line request can work through an explicit proxy while the browser still has stale cookies or an extension conflict. Use the mixed port explicitly in the application’s supported proxy setting, and never publish a subscription URL, access token, API key, or complete profile in a screenshot or diagnostic log.

curl --proxy http://127.0.0.1:7890 https://generativelanguage.googleapis.com

The command above is only a connectivity check and does not authenticate an API request. A successful HTTP response, even an authorization error, can prove that the hostname was reached through the local proxy. A DNS failure, connection refusal, or timeout points to a different layer. Replace the port if your Clash installation uses another mixed listener.

Troubleshoot Loading, Login, and Streaming Failures

Blank Page or Endless Loading

Start by checking whether the browser can resolve and connect to aistudio.google.com. If there is no corresponding entry in the Clash log, the request may be bypassing Clash, blocked by a browser extension, or failing before the network connection is created. If the request appears as DIRECT, inspect rule order. If it uses the intended proxy but times out, test another node and compare the result without changing the rest of the configuration.

Repeated Google Login Verification

Repeated verification can occur when the apparent network location changes during the session, when cookies are stale, or when account security systems detect unusual sign-in behavior. Keep one node selected while logging in, avoid rapidly switching between Global and Rule modes, and do not open several simultaneous login attempts. If ordinary Google services work but AI Studio alone fails after authentication, route the authentication host consistently during the complete sign-in flow and inspect whether redirects are being split between DIRECT and proxy paths.

The Model Selector Is Empty

An empty selector often means that the main page loaded but a supporting API request did not. Look for blocked or failed calls to Google API domains in the Clash log. Add only the missing host or a narrow suffix rule, then reload the page. Avoid immediately adding all Google domains to the proxy group, because that hides the actual failing dependency and can create new problems with account or Workspace services.

Responses Stop During Generation

Mid-response failures are usually related to node stability rather than the initial page route. Select a less congested node, keep the connection on one proxy group, and test a shorter response. If short prompts succeed while long generations fail, compare nodes at different times of day and inspect whether the proxy provider imposes connection duration or traffic limits. Disabling HTTP/3 or QUIC temporarily can also be a useful diagnostic step when the client, network, or upstream node handles UDP poorly; do not treat that switch as a universal fix.

Maintain the Configuration Without Breaking Access

AI services evolve quickly. Google may introduce new hostnames, change API behavior, or move a feature behind a different frontend. That does not mean you should copy every new rule list you see online. Keep your custom rules in a documented override or a separate configuration layer when your client supports it. This makes provider subscription updates less likely to erase your changes and gives you a clear rollback path.

Review the profile after each subscription refresh. Confirm that the proxy group still exists, the selected node is available, and your custom rules remain above broad fallback rules. If a profile update changes the group name, your custom rule may point to a group that no longer exists. Clash can then reject the configuration or route the traffic unexpectedly. Export a known-good copy before major edits and keep sensitive credentials out of shared backups.

Use the narrowest practical routing policy. Route AI Studio and Gemini API traffic through a stable group, leave local services direct, and add authentication or static-content domains only when testing shows they need the same path. This reduces latency for unrelated Google products, limits the amount of traffic exposed to a third-party proxy, and makes the request log readable when something fails. For teams or developers, write down the selected mode, mixed port, DNS mode, and rule purpose so another person can reproduce the setup without guessing.

Compared with tools that rely on a single application-wide tunnel or require manual proxy edits for every browser profile, Clash gives you clearer rule ordering, visible request logs, flexible node groups, and the option to use the same policy across Windows, macOS, Linux, Android, and router deployments. Other clients may be perfectly adequate for a quick single-device connection, but they can become cumbersome when AI Studio, API scripts, account login, and ordinary Google traffic need different treatment. If you want a maintained client with rule-based control and multiple platform options, visit the Clash download page to get the latest available build and download Clash for a more manageable Google AI Studio setup.