Identify Where the Request Fails Before Changing Settings

If ChatGPT will not load through Clash, first determine whether the failure is limited to ChatGPT or affects the whole proxy connection. A blank page, a sign-in loop, an error saying the request timed out, and a page that loads without sending messages can have different causes. Changing DNS, switching to Global mode, and editing rules simultaneously may hide the real cause rather than fix it.

Clash clients such as Clash Verge Rev manage the configuration and expose controls; the running core, often mihomo, resolves names, matches rules, and connects through the selected proxy. A green client status or a successful latency test does not prove that ChatGPT requests are reaching the right destination through a working route. Use the client’s Proxies, Connections, and Logs pages to check what happens to a fresh request.

  1. Open a website that you know should use the proxy. If it also fails, check the selected node, proxy group, and system proxy or TUN status before focusing on ChatGPT.
  2. Try ChatGPT in a private browser window, or test the official app if you normally use a browser. This helps distinguish a browser session problem from a routing problem.
  3. Note the exact symptom and time: for example, whether the sign-in page loads, whether the chat page opens, and whether sending a new message is what times out.
  4. In Clash, open Connections immediately after reproducing the problem. Look for requests associated with the browser or app and check the destination, matched rule, policy, and connection result.

Check Proxy Mode, Group Selection, and Node Connectivity

Start with the active configuration, not just the subscription list. An imported profile may be visible without being selected, and a proxy group may point to another group rather than directly to a node. On the Proxies page, follow the group choices until you can identify the actual node used for traffic. For an initial test, manually select a known working node if your configuration allows it.

In Rule mode, the core evaluates the configuration’s rules in order and sends each request to the policy specified by the first matching rule. A ChatGPT request might therefore use a proxy, go DIRECT, or be rejected, depending on the effective rules and group selections. In Global mode, requests covered by the global proxy policy use the selected proxy group instead of being routed by ordinary rule matches. Global mode is useful as a short diagnostic comparison, but it is not automatically the best permanent setting.

What you observe What to check first Useful next test
Most websites fail Active configuration, selected node, core status, and system proxy or TUN state Test a known working website and inspect its connection in Clash
Other sites work, but ChatGPT does not ChatGPT-related requests, matched rules, and the selected policy Compare Rule mode with a brief Global mode test
The page opens, but sign-in loops Browser cookies, extensions, DNS results, and requests to supporting services Use a private window and inspect new connections during sign-in
Chat loads, but replies time out Node stability, connection errors, and whether requests are consistently proxied Try a different stable node and send a short test message

Use Global Mode as a Short Test

Switch to Global mode only long enough to repeat the same action, such as opening the ChatGPT page or sending one test message. If the request works in Global mode but fails in Rule mode, the result points toward rule matching or a policy-group choice. Return to Rule mode after the comparison and correct the narrow routing issue where possible. If both modes fail in the same way, investigate the node, DNS, browser, app, or network instead of repeatedly changing rules.

A successful result in Global mode does not mean every request related to ChatGPT now follows a sensible route for everyday use. Global routing can also proxy websites and local resources that your normal rules send DIRECT. Use it as a controlled test, not as proof that a configuration is fixed.

Inspect Rule Matching and DNS Results

When only ChatGPT is affected, check the actual connection records before editing YAML. In Connections, reproduce the issue and look for requests created at that moment. Record the destination hostname when visible, the matched rule, the selected policy, and whether the connection was closed, timed out, or sent through a proxy. A browser session may contact several services, so a single successful request to the main page does not establish that all sign-in or chat requests have the same route.

Do not assume that one fixed hostname list covers every ChatGPT feature or future service change. Web pages, authentication, static resources, and real-time connections can involve different destinations. If a rule needs adjustment, use hostnames or rule providers supported by your configuration and put specific rules before broad catch-all rules. Keep the existing provider’s documented policy-group names; a rule that references a group that does not exist can fail to provide the intended route.

# Illustrative ordering only; use a policy group that exists in your configuration.
rules:
  - DOMAIN,example-service.invalid,Proxy
  - MATCH,Final

The hostname above is a placeholder, not a ChatGPT domain to copy. The practical point is ordering: a specific rule must appear before a broad rule that would otherwise match first. Avoid pasting unverified domain lists from old posts. Check the current connection log and use the service or configuration provider’s current guidance to identify destinations that need a proxy.

Test DNS Without Changing Everything

DNS problems can appear as a slow first load, a browser error before a connection is established, or inconsistent access across devices. Check whether the relevant hostname resolves and whether the result changes when you reconnect or switch networks. If the core uses enhanced DNS handling, note the current mode, such as fake-IP or redir-host, and test one controlled change at a time. DNS fields and defaults differ between core versions and configurations, so do not replace the whole DNS section with a snippet written for another setup.

  • Use the Connections or Logs view to see whether a request reaches the point of establishing a proxy connection.
  • Check the core log for DNS errors, failed lookups, or configuration validation messages around the time of the test.
  • If changing DNS behavior, save a copy of the original configuration and restart or reload the active profile as the client requires.
  • Repeat the same request after the change, then restore the previous setting if there is no clear improvement.

Run a Controlled Test in Clash

This sequence helps separate a bad node from a routing or client issue. Menu labels vary across Clash Verge, Clash Verge Rev, Mihomo-based clients, and mobile apps, but the relevant pages are usually named Profiles or Configurations, Proxies, Connections, and Logs. Test on one device and one network, and do not update the profile halfway through the comparison.

  1. Confirm the active profile. Open the configuration page and verify that the intended profile is enabled. Check for a parse error or a core-start failure in Logs before testing websites.
  2. Select a known candidate node. Open Proxies and follow the relevant policy group to its actual member. Avoid relying on a group label alone; a group named “Proxy” can still point to DIRECT or to another group with no working selection.
  3. Check basic connectivity. Run a node test if the client provides one, then open a separate website that normally uses the proxy. A latency result is only evidence that a test request succeeded; it does not guarantee stable access to every service.
  4. Make the traffic path explicit. Enable the system proxy for a browser test, or enable TUN if the application does not honor the system proxy. Do not toggle both repeatedly while testing. Confirm the client reports the expected state.
  5. Reproduce the exact ChatGPT symptom. Open the page or send one short message, then immediately inspect Connections. Note which policy was selected and whether the request completed.
  6. Compare Rule and Global mode briefly. Repeat the same action on the same node. If only Global mode works, focus next on rule order and the policy referenced by matching rules.
  7. Try one different node. Keep the mode and other settings unchanged. If the second node works, the first may be unsuitable or unstable for this destination; if neither works, continue with DNS, app, browser, or network checks.

For a TUN test, first confirm that the client successfully started the TUN service and that the operating system granted the required permissions. TUN routes traffic through a virtual network interface; it is not simply another name for the system proxy. It can capture applications that ignore system proxy settings, but it also introduces additional routing, DNS, and permission variables. If a browser works with the system proxy but a desktop app does not, testing TUN may help identify an application that bypasses the system proxy. Turn it off again if it does not change the observed result.

When testing on Windows, check whether another VPN, security product, or network filter is active. On Android, distinguish the Clash VPN service from a separate device VPN, since two VPN-based services may not run concurrently. On macOS, verify that the system accepted the network extension or VPN permission. These checks are more informative than disabling a firewall or security tool without evidence.

Resolve Login Loops and Message Timeouts

If the login page repeatedly returns to sign-in, first test in a private window. If that works, clear the affected site’s cookies and cached data or temporarily disable browser extensions that block scripts, cookies, or cross-site requests. Keep any saved login information secure. A browser session can also be affected by the device’s clock: check that automatic date and time are enabled, since incorrect time can interfere with secure connections.

If the page opens but sending a message times out, look for the failed request at the moment the response stalls. A node can pass a quick latency test yet lose long-lived or repeated connections under load. Select a different stable node, repeat the same short prompt, and compare the logs. Avoid running several latency tests while judging a live conversation; concurrent tests can add load and make results less comparable.

If both browser and app fail, test another network, such as switching between Wi-Fi and a mobile connection where available. If ChatGPT works on another network with the same Clash profile and node, the original network may be interfering with DNS, outbound connections, or the proxy server’s reachability. If only one browser or device fails, concentrate on that client’s proxy behavior, permissions, extensions, cached session, and DNS state.

  • Rule mode fails, Global mode works: Inspect the matched rule, rule order, and the policy group it selects. Return to Rule mode and correct only the relevant routing behavior.
  • One node fails, another works: Keep the working node selected for the test and check the first node’s stability or provider status.
  • Browser works, app fails: Check whether the app follows the system proxy. Test TUN only if appropriate, and verify that the client actually established its virtual interface.
  • Both fail on one network: Compare DNS and connection behavior on another network, then check whether the local network or upstream route is involved.
  • Nothing changes after a DNS adjustment: Restore the original DNS settings and continue with the connection log, selected policy, and node.

Before making a lasting configuration change, save the active profile or duplicate it if the client supports profile copies. After a successful fix, return to the normal mode, repeat the same test, and confirm the matching rule and policy in Connections. This final check ensures the service works through the intended route rather than only through a temporary Global-mode setting.