Preface
Perplexity Comet is attracting attention as an AI-focused browser because it combines ordinary web navigation with search, summarization, page analysis, and assistant-style workflows. Those features depend on several services working together: the browser interface, Perplexity account endpoints, streaming connections, search APIs, content delivery networks, and sometimes third-party authentication providers. If even one part of that chain is slow or unreachable, Comet may appear to freeze, show an empty response, or repeatedly ask you to sign in.
Clash can make this experience more reliable by giving you control over DNS handling, proxy selection, split tunneling, and application routing. However, simply turning on Global Mode is not always the best solution. A distant or overloaded node can increase latency, while an incomplete rule set can send account traffic through one route and streaming traffic through another. The result may be a browser that opens normally but fails when an AI response begins.
This guide explains how to pair Perplexity Comet with Clash on Windows, macOS, and other supported desktop environments. The examples are designed for Clash Verge Rev and Mihomo, but the same ideas apply to other Clash-compatible clients. Always follow the laws, network policies, and service terms that apply to your location, and use an account and proxy service that you are authorized to use.
Technical Goal
Keep Comet’s login, search, page-loading, and streaming traffic on a consistent, healthy route while allowing unrelated local services to remain DIRECT.
1How Comet Uses the Network
Before changing Clash rules, it helps to understand why Comet can behave differently from a normal browser. A regular web page may need only one HTTPS request to load its main document. An AI browser often performs many requests in parallel. It may resolve several hostnames, retrieve JavaScript and fonts from a content delivery network, connect to an account service, request search results, and maintain a long-lived connection while an answer is generated.
These requests do not necessarily use the same protocol. Standard page resources usually travel over HTTPS, while live answers may depend on streaming HTTP or WebSocket-style connections. If your client supports UDP forwarding, some browser functions may also use HTTP/3 or QUIC. A proxy node that is excellent for ordinary web pages may be poor at maintaining a stable long-lived stream.
Typical symptoms and what they suggest
| Symptom | Likely area to inspect | First test |
|---|---|---|
| Comet cannot open or stays blank | DNS, system proxy, or blocked connection | Test the same service in another browser |
| Sign-in loops or returns to the login page | Mixed routing, cookies, or unstable IP reputation | Use one node and a private window |
| Search works but AI answers stop midway | Streaming connection, timeout, or overloaded node | Switch to a lower-latency node |
| Pages load slowly but other sites are normal | Rule matching or a poor regional route | Review active connections in Clash |
Important Limitation
Clash controls your local routing; it cannot repair an expired account, a service outage, an unsupported region, or a proxy IP that the destination service has chosen to restrict.
2Prepare Clash Before Opening Comet
A stable setup begins with a clean baseline. Update your Clash client and its Mihomo core when a trusted release is available, then confirm that your subscription has not expired. Old cores may mishandle newer transport behavior, and an outdated profile can contain obsolete rules or unavailable policy groups.
Open your client’s Profiles page and select the profile you actually intend to use. Many connection failures happen because a user edits one YAML file while Clash is running a different profile. After selecting the profile, verify that the configuration parses successfully and that the proxy groups contain at least one reachable node.
Recommended baseline settings
- Use Rule mode instead of Global Mode for everyday browsing.
- Choose a stable proxy group with an automatic health check or latency test.
- Enable the system proxy if Comet follows the operating system proxy settings.
- Use TUN mode only when ordinary system proxy mode does not capture the required traffic.
- Keep the first test simple: one profile, one policy group, and one known-good node.
- Record your original settings before changing DNS, TUN, or fake-IP options.
For Windows and macOS, start by testing system proxy mode. It is easier to diagnose because the browser’s TCP connections are visible without adding another virtual network layer. If Comet ignores the system proxy, or if DNS and non-browser requests continue to escape, enable TUN mode according to your client’s documentation. TUN mode may require administrator permission and can affect every application on the computer.
Pro Tip: Change One Variable at a Time
Do not enable TUN mode, replace DNS, change the node, and rewrite all rules simultaneously. A controlled sequence makes it much easier to identify the setting that solved or caused the problem.
3Configure DNS and Routing for Comet
DNS is often the hidden cause of inconsistent access. If Comet’s hostname is resolved by a local resolver while the actual HTTPS request uses a remote proxy, the returned address may be unsuitable for your route. Local DNS interception, stale browser records, and split resolution can also make one part of the service work while another part fails.
In a Mihomo profile, a practical starting point is encrypted or remote DNS resolution combined with fake-IP mode. The exact syntax and available options depend on the core version, so validate the profile after editing it. The following example is a baseline rather than a universal prescription:
After saving the profile, restart the Clash core rather than only minimizing the window. Then clear Comet’s cached DNS data if the browser provides that option, close all Comet windows, and reopen it. If fake-IP mode causes a local application to malfunction, add that application or domain to the appropriate fake-IP filter list instead of abandoning the entire DNS configuration.
Build narrow rules before broad rules
Rules are processed from top to bottom. A broad rule placed too early can capture traffic before a more specific rule gets a chance to match. Keep your service-specific rules above generic rules such as a final proxy or fallback rule. Avoid copying a large rule set from an unknown source without reviewing it; an untrusted ruleset may redirect traffic in ways you cannot easily observe.
The domains above are examples of categories that may appear in an AI browsing workflow, not a guarantee of every endpoint Comet will use. Services can change their infrastructure, and routing every Google or CDN domain through a proxy may affect unrelated websites. Watch the Connections panel in Clash while opening Comet, signing in, performing a search, and loading a page. Add only the domains that are demonstrably required.
4Hands-On Comet and Clash Setup
Once the baseline is ready, use the following sequence. Performing the steps in order creates a reproducible test and prevents old browser sessions from hiding the result.
- Open the active proxy group in Clash and run a latency test against several nodes.
- Prefer a node with consistent results rather than one with the lowest single ping.
- Keep the selected node fixed during the first Comet test so that changing IP addresses does not invalidate the session.
- Check that the node supports the traffic type required by your profile and that the subscription has remaining traffic.
- Enable system proxy mode in Clash and confirm that the operating system reports the proxy as active.
- Open a separate browser and load a simple HTTPS website to verify basic connectivity.
- Review Clash’s connection log. The request should show the expected policy group rather than DIRECT.
- If Comet is not visible in the log, close every Comet process and relaunch it after enabling the proxy.
- Open Comet in a fresh window and sign in using the normal account flow.
- Load a lightweight public page first, then ask Comet to summarize that page.
- Watch the Clash connection list while the answer is being generated. Look for failed connections, repeated retries, or a policy that changes unexpectedly.
- Test one longer page and one follow-up question before changing any configuration.
- If system proxy mode does not capture Comet, enable TUN mode and grant the requested permissions.
- Restart Comet and repeat the same lightweight page and summary test.
- Check for duplicate VPN, security software, or corporate network filters that may conflict with the virtual interface.
- When the test succeeds, document the working mode and node before optimizing further.
A Reliable Test Pattern
Use the same node, the same profile, and the same test page for each change. This separates network problems from Comet account, cache, or page-specific problems.
5Improve Stability Without Over-Proxying
Once Comet works, optimization should focus on consistency rather than maximum tunnel coverage. Sending every domain through a remote node can increase page load time, introduce unnecessary latency, and make local services less reliable. A selective policy group is usually easier to maintain.
Choose nodes for streaming quality
For AI responses, sustained performance matters more than a quick initial connection. Compare packet loss, repeated disconnects, and response continuity. A node with a slightly higher ping but stable bandwidth may outperform a low-ping node that becomes congested after several seconds. If your provider offers multiple regions, test locations that are geographically close to both you and the service infrastructure.
Keep the session on one route
Automatic selection is convenient, but frequent node switching can make account sessions appear unusual and can interrupt long responses. Use automatic testing to identify a good node, then pin that node while diagnosing Comet. If you use a URL-test group in daily operation, set a reasonable interval instead of switching on every small latency fluctuation.
Handle IPv6 and QUIC deliberately
If your local IPv6 connection is not routed through Clash, Comet may attempt a direct IPv6 connection even while IPv4 traffic uses the proxy. Temporarily disabling IPv6 in the profile or operating system can help isolate this issue. Similarly, if browser traffic over HTTP/3 behaves inconsistently, test with the client’s UDP support configured correctly or temporarily allow the browser to fall back to TCP. Do not change both variables at once.
Use browser isolation for diagnosis
Extensions, cached service workers, content blockers, and copied browser profiles can all affect Comet. Test with a fresh profile or private window, then re-enable extensions one by one. Avoid repeatedly deleting cookies while switching nodes, because that can create additional login challenges and makes it harder to distinguish a routing error from a session problem.
| Goal | Recommended approach | What to avoid |
|---|---|---|
| Fast page loading | Route only required AI and account domains through a healthy group | Proxy every local CDN and intranet domain |
| Stable answer streaming | Use one low-loss node with steady bandwidth | Frequent automatic node changes |
| Reliable name resolution | Use one consistent Clash DNS strategy | Mixing browser, ISP, and proxy DNS without a plan |
| Easy troubleshooting | Keep a small, documented rule set | Adding unreviewed rule providers blindly |
6Troubleshoot Common Access Failures
Comet does not open at all
First determine whether the problem is local to Comet. Close the browser, verify that Clash is running, and test the same destination in another browser using the same proxy mode. If every application fails, inspect the node, subscription status, DNS logs, and system time. If only Comet fails, check whether it has its own proxy preference, a damaged cache, or a security application blocking its executable.
Login keeps repeating
Use a single node for the entire login process. Do not alternate between DIRECT, a proxy, and a second region while cookies are being created. Confirm that the system clock is correct, allow essential cookies, and temporarily disable extensions that modify headers or block scripts. If the service rejects the node’s IP reputation, changing Clash rules will not solve it; use an authorized, stable connection and consult the provider’s support resources.
Search works but summaries fail
This usually points to a second endpoint or streaming path that is not matching your rules. Watch the Clash log while starting an answer and compare the failed hostname with the successful search request. Check whether the failed connection is being sent DIRECT, whether it is repeatedly reconnecting, and whether the selected node has enough bandwidth. Add a narrow rule only after confirming the destination is part of the workflow.
Comet is slow after enabling TUN
TUN mode may conflict with another VPN, antivirus web filter, or corporate endpoint agent. Disable competing network filters for a controlled test, then compare system proxy mode and TUN mode. Also inspect whether large local downloads are being sent through the same policy group. A correct TUN setup should not require routing every application through the AI node.
DNS changes made things worse
Restore the last working profile and confirm that the YAML indentation is valid. Test with IPv6 disabled, then compare fake-IP and redir-host behavior if your client supports both. Some local applications require a fake-IP filter, while others do not work correctly with synthetic addresses. Keep a backup of every working profile so you can recover quickly after experimentation.
Read the Connection Log
The connection log is more useful than guessing from the browser screen. Record the hostname, matched rule, selected policy, connection status, and timing for one successful request and one failed request.
Frequently Asked Questions
Does Perplexity Comet require Clash to work?
No. Comet can work without Clash when the local network, account, and service region are supported. Clash is useful when you need controlled routing, consistent DNS handling, or a more reliable path for specific traffic. It should be treated as a routing tool, not as a guarantee of service availability.
Should I use Global Mode for Comet?
Global Mode can be useful as a short diagnostic test because it reveals whether the selected proxy path works at all. For daily use, Rule mode is usually better. It lets you route confirmed Comet and account domains through one policy group while keeping local websites, banking services, and workplace resources on their intended connection.
Is TUN mode always necessary?
No. Start with system proxy mode. Enable TUN only when Comet or its related traffic does not appear in the Clash connection log, or when DNS and non-browser requests bypass the proxy. TUN mode offers broader capture but also introduces more variables and may require additional permissions.
Why does changing nodes fix the issue temporarily?
A node change can replace a congested route, a failed resolver path, or an IP address with poor reputation. If the problem returns frequently, investigate node quality, automatic switching intervals, DNS consistency, and the specific failed hostname instead of changing nodes indefinitely.
Perplexity Comet works best with a measured Clash configuration: start with one reliable node, verify DNS behavior, observe real connections, and add only the rules that the workflow requires. With a stable route and a small, understandable profile, you can reduce login loops, incomplete AI responses, and random page failures without sacrificing the performance of the rest of your browsing.