Perplexity Comet With Clash: China Access Setup Guide

Who this guide is for

Perplexity Comet is attracting attention because it combines an AI assistant with a Chromium-based browsing experience. Instead of opening a separate chatbot, you can ask questions about the page you are reading, summarize research, compare sources, or continue a task across several tabs. That promise is appealing, but users in China may encounter a less convenient first launch: Comet may remain on a loading screen, sign-in pages may not complete, sources may fail to open, or the browser may report that a network request timed out.

These symptoms do not always mean that Comet itself is damaged. The browser may need to reach several different services for authentication, assistant requests, page retrieval, update checks, telemetry, and content delivery. One hostname may load through your current connection while another is unreachable or resets during a long request. A normal browser VPN toggle can also be too broad, too opaque, or ineffective for a Chromium application that uses its own networking process.

This guide explains how to connect Perplexity Comet with a Clash-compatible client in a controlled and observable way. The examples focus on Clash Verge Rev and Mihomo, but the same ideas apply to Clash Verge, Clash for Windows, ClashX, and Clash for Android when the client exposes system proxy, rule mode, or TUN controls. You should use a legitimate Clash subscription or a proxy service that you are authorized to access, follow local laws and service terms, and avoid treating this tutorial as a guarantee that every Perplexity feature is available in every region.

Understand why Comet may need more than one route

A browser session that looks like one action to the user can contain many network operations. When you enter a prompt in Comet, for example, the application may first verify the account session, contact an assistant endpoint, retrieve an answer, load citations, and open source pages in separate requests. A sign-in flow may add redirects, cookies, captcha resources, and static JavaScript files from different domains. If only one part of that chain is routed through Clash, the visible result can be an apparently random failure.

For this reason, do not begin by copying a long list of unverified domain rules from a forum post. Service infrastructure changes, hostnames can be regional, and a rule written for an earlier Comet build may become irrelevant after an update. Use the Connections or Logs view in your Clash client while reproducing one specific problem. Record the hostname, process, policy, and result. This evidence is more useful than guessing from the name of the application.

• Authentication traffic: sign-in, account verification, session refresh, and redirect requests may be handled by a different host family from the assistant itself.
• Assistant traffic: prompts, streamed responses, and conversation history can use long-lived HTTPS connections that expose unstable nodes quickly.
• Source traffic: Comet may open ordinary websites that should follow a different policy from the AI service.
• Application traffic: update checks, crash reports, static assets, and browser background services may continue even when no tab is open.

A useful first test is to switch Clash temporarily to Global mode, select a responsive node, and relaunch Comet. If sign-in and assistant requests become reliable, the result suggests a routing or DNS-policy problem rather than proof that Global mode is the best permanent configuration. If Global mode changes nothing, investigate the account, application version, node quality, and system permissions before adding more rules.

Prepare Clash before opening Comet

Start with a clean baseline. Close other VPN applications, proxy managers, and network extensions that may compete for the same system settings. Two clients can both display an enabled switch while listening on different ports or restoring different proxy values after a restart. During diagnosis, one active routing controller is easier to understand than several overlapping tools.

Open Clash Verge Rev or your preferred client and confirm that the profile has loaded successfully. A profile normally contains proxy nodes, groups, DNS behavior, and rules. If the profile has expired, contains no usable proxies, or cannot update, Comet troubleshooting will produce misleading results. Keep subscription URLs private: they often contain an account token that allows anyone who obtains it to consume your traffic allowance.

Note the HTTP or mixed port shown by your client. Common installations use a local address such as 127.0.0.1 with a port configured by the profile, but you should not assume a specific number. The port in your application must match the port displayed by Clash. A browser pointed at the wrong port can look exactly like a browser with no proxy at all.

Connect Perplexity Comet to Clash step by step

The following workflow is designed to isolate one variable at a time. Menu names can differ between Comet releases and operating systems, so use the equivalent setting when an exact label is unavailable.

1. Launch Clash first. Wait until the profile has finished loading and a proxy group shows at least one available node. Do not start with an unhealthy or overloaded node simply because it is listed first.
2. Choose a comparison mode. Select Global mode for a short diagnostic test, then choose a node with stable latency. Global mode sends more traffic through the selected proxy, so use it only long enough to determine whether routing is involved.
3. Enable the system proxy. Turn on the system proxy switch in Clash. On Windows, check the operating system proxy panel; on macOS, check the active network service under Network settings. Confirm that the address and port match Clash exactly.
4. Open Comet after the proxy is active. Starting the browser after the system setting is enabled reduces the chance that a long-lived process keeps an old networking state. If Comet was already open, quit it completely rather than closing only the visible window.
5. Test sign-in before testing AI features. Open the account page and complete authentication. If the sign-in page loops, record the failing hostname in Clash Logs instead of repeatedly submitting credentials.
6. Run a small assistant request. Ask a simple question that does not require a large file or a complicated research task. Observe whether the response begins, streams continuously, and finishes without a timeout.
7. Open a few ordinary sources. Try a page that you are authorized to access and compare its behavior with the assistant response. A successful assistant request does not prove that every source website will be reachable through the same route.
8. Return to Rule mode. Once Global mode works, switch to Rule mode and repeat the sign-in and assistant tests. The goal is to identify the smallest useful routing policy rather than leaving every application on the proxy indefinitely.

When using TUN mode, treat it as a separate experiment. TUN can capture applications that ignore ordinary system proxy settings, but it also changes DNS handling and may affect local services, games, printers, corporate networks, or banking applications. Enable it only after recording the behavior of the regular system proxy. If TUN fixes Comet immediately, inspect the logs to learn which process or request was bypassing the regular proxy instead of assuming that TUN must remain enabled permanently.

Build a reliable routing policy

Rule mode is usually the better long-term choice because it lets you route selected services while keeping local websites and devices on a direct path. A practical policy should be based on observed traffic, not on an oversized collection of guessed keywords. Start with the hostnames that clearly failed during your test, add them to an appropriate proxy group, and then retest after each meaningful change.

Keep the rule order in mind. Clash generally evaluates rules from top to bottom, so a broad DOMAIN-SUFFIX, GEOIP, or final DIRECT rule placed before a specific proxy rule can capture traffic too early. A rule that appears correct but never matches is often a placement problem. After editing a profile, reload it, clear stale browser state only when necessary, and watch a fresh connection in the logs.

• Place specific service rules before broad regional or catch-all rules.
• Use a stable proxy group rather than a node that changes automatically during every test.
• Keep local network ranges, printers, router addresses, and internal work services on DIRECT when appropriate.
• Do not proxy all traffic merely because one Comet request failed; broad routing can introduce latency and break local access.
• Document every custom rule so you can remove it when Comet changes its infrastructure.

Some users prefer a separate policy group for AI services and another for general browsing. That arrangement makes failures easier to classify. If Comet’s assistant works through the AI group but source pages fail through the browsing group, you have two independent routing problems rather than one mysterious application failure. Conversely, if both groups fail on the same node, test another node before changing the entire rule design.

DNS deserves equal attention. A hostname can resolve to an address that is reachable from one network but not another, and fake-IP or redirection settings can affect how the browser presents the destination to Clash. Avoid changing several DNS options at once. Record the current mode, make one controlled adjustment, reload the configuration, and compare the resulting Connections entries. If only numeric connections appear or the requested hostname is missing, examine DNS and sniffing behavior before rewriting domain rules.

Troubleshoot common Comet and Clash failures

Comet stays on a loading screen

First check whether Clash records any new requests when the loading screen appears. If there are no requests from Comet, the browser may be using a cached state, a different process, or a proxy setting that it does not inherit. Quit Comet completely, confirm the system proxy, and relaunch it. If requests appear but repeatedly use DIRECT, fix the rule match or temporarily compare Global mode. If the requests use a proxy but reset, choose another node and compare several attempts rather than judging from one latency number.

The sign-in page loops or returns an error

Authentication can fail because redirects, cookies, scripts, and account endpoints do not share the same policy. Check whether the redirect hostname is being blocked, sent DIRECT, or routed through an unstable node. Avoid deleting all browser data immediately; doing so can create another login challenge without solving the route. Try a private window only as a controlled comparison, and make sure the device clock is correct. If the account provider rejects the login even through a confirmed stable connection, stop changing Clash rules and investigate account or service-side restrictions.

The answer begins but stops midway

Partial streaming failures often indicate an unstable node, connection reuse problem, or timeout-sensitive path. Compare a short answer with a longer answer, then try a different node from the same group. Check whether the connection remains open in Clash Logs while the browser is waiting. If the node handles ordinary pages but fails on long-lived streams, it may be unsuitable for assistant traffic. A different provider or route may be necessary; endlessly increasing browser retries can duplicate requests and make diagnosis harder.

The assistant works but source pages do not

This result is not unusual. Source websites apply their own regional policies, bot protection, authentication requirements, and rate limits. Make sure the page is legally and legitimately available to you. Check the source hostname in the log and decide whether it should use the same group as the assistant. A direct local source may work better on DIRECT, while an overseas source may require a proxy. Do not interpret a blocked publisher page as evidence that Comet or Clash is malfunctioning.

Privacy, security, and maintenance habits

Routing Comet through Clash does not make every activity anonymous. The proxy operator may see connection metadata, the websites you visit can still identify your account, and Comet itself may process prompts, page content, or browsing context according to its own policies. Do not paste passwords, private keys, customer records, confidential company documents, or regulated personal data into an AI browser unless you have verified the service’s data handling requirements.

Use encrypted subscription delivery when your provider supports it, protect your local Clash controller with an authentication secret, and avoid exposing the external controller API to the public internet. A local mixed port should normally listen only on the loopback interface unless you have a deliberate LAN-sharing design and understand its security implications. If you share Clash with another device, use an access-controlled LAN address and firewall rules rather than binding administrative endpoints broadly.

After Comet updates, repeat a small verification checklist: open the application, confirm sign-in, send a short prompt, open one source, and inspect the logs. Infrastructure and browser behavior change over time, so a policy that worked last month may become unnecessarily broad or stop matching. Keep a backup of the original profile before editing, and remove temporary Global or TUN experiments when the diagnosis is complete.

Frequently asked questions

Do I need TUN mode to use Comet with Clash?

No. Begin with the regular system proxy because it is easier to verify and less disruptive to local traffic. Use TUN mode only when logs show that Comet or one of its processes ignores the system proxy. TUN may solve that specific limitation, but it also changes DNS and traffic interception behavior, so test it separately and keep a record of the change.

Should I leave Clash in Global mode?

Global mode is useful as a diagnostic baseline because it quickly shows whether a selected node can handle Comet. It is not automatically the best permanent configuration. Rule mode can keep local services direct, reduce unnecessary proxy usage, and make it easier to assign different policies to the assistant and source websites. Move back to Rule mode after confirming the node works.

Why does one node work while another node fails?

Nodes differ in congestion, geographic path, protocol support, DNS behavior, and handling of long-lived HTTPS streams. A low latency result from a short ping does not guarantee stable assistant streaming. Compare several nodes with the same small Comet test, observe connection completion in the logs, and favor consistent behavior over the lowest displayed latency.

Can Clash guarantee access to every Comet feature in China?

No. Clash controls routing; it cannot override account eligibility, regional availability, publisher restrictions, application bugs, subscription limits, or service-side policy. Use the service only where permitted, follow applicable regulations and terms, and treat routing changes as a troubleshooting tool rather than a guarantee of availability.

Compared with one-click VPN applications that hide routing decisions and offer little evidence when an AI browser stalls, Clash gives you visible connections, selectable nodes, rule-based separation, and a practical Global-versus-Rule comparison. Those controls are especially valuable when Comet’s assistant works but authentication or source pages do not, because you can identify the failing path instead of repeatedly reinstalling the browser. If you want that level of control across Windows, macOS, Android, or other supported platforms, a Clash client provides a more transparent starting point for this setup.

Download Clash for free and browse freely →