ChatGPT Not Working With Clash? Fix Proxy, DNS, and Rules

1. Identify where the connection fails

“ChatGPT does not work” can describe several different failures: the page may not open, sign-in may loop, the interface may load without its conversation list, or a response may stall after you submit a prompt. These symptoms do not all point to the same cause. A browser can reach the website while a separate API or static-resource request is failing, and a successful proxy connection does not prove that every domain used by the service follows the same route.

Start by recording the exact symptom, the time it occurred, and whether it affects one browser, all browsers, or the ChatGPT app as well. Note the client and running core, the active profile, the current mode, and whether traffic reaches the core through the system proxy or TUN. Client names alone are not enough to establish which core or configuration is active: check the client’s core information or startup log.

• Page does not open: Check the browser’s proxy settings, the client’s connection list, DNS results, and the selected outbound.
• Sign-in fails or repeats: Check whether the login page and the main site are routed consistently. Also try a private window to distinguish a stale cookie or extension issue from a proxy failure.
• Page loads but content is missing: Look for failed requests to additional domains in the browser’s network panel and the Clash connection list. Do not assume the main page’s domain is the only one that matters.
• Requests time out after loading: Check the connection’s final policy and node, then compare the result with another healthy node and a separate network.

Check the service’s official status information and try an ordinary, unrelated HTTPS site through the same proxy. If many sites fail, investigate the core, node, or local network first. If only ChatGPT fails, focus on the domains and routes involved in that service. Status checks are useful context, but they do not replace a local connection test.

2. Check the mode, proxy path, and node

The client must first capture the browser’s request before routing rules can affect it. In most desktop clients, system-proxy mode configures supported applications to send traffic to the local proxy listener. It does not automatically capture every program. TUN mode can capture more system traffic, including applications that ignore the system proxy, but it requires compatible core support and may need elevated network permissions. TUN is not a universal fix for a browser that has an incorrect proxy configuration.

For a controlled test, use the client’s supported controls to confirm that the core is running and that the browser’s request appears in the connection list. In Clash Verge or Clash Verge Rev, labels and menus can vary by release, but check the active profile, core status, mode, proxy controls, and connection view rather than assuming that a toggle has applied successfully. If you use another client, find the equivalent controls for its running core.

1. Confirm the active configuration is the one you intended to test. A profile switch or subscription update may have replaced a local edit.
2. For rule diagnosis, select Rule mode. Global mode sends traffic through the selected global policy and does not test the normal rule list; Direct mode bypasses proxy routing.
3. Verify that the browser is using the system proxy configured by the client, or use the client’s documented TUN setup if the browser is not reaching the core.
4. Open the connection list, start a fresh ChatGPT page load, and check whether new connections appear. Inspect their matched rule, policy group, and selected node where the client exposes these fields.
5. Test a different available node in the same group. A node that appears selectable is not necessarily reachable or suitable for this destination.

If the request does not appear in the connection list, changing a domain rule will not help yet: traffic has not reached the routing stage you are trying to diagnose. Check the browser’s proxy setting, operating-system proxy state, client service status, and any other proxy or network-filtering software. If the request appears but repeatedly fails to connect to the proxy server, test another node and check the network path to that node.

Changing mode is a diagnostic test, not a reason to leave all traffic on a broad policy indefinitely. Record the original mode and restore the intended setup after testing. If Global mode works while Rule mode fails, that is evidence to inspect the matching rule or policy group—not proof that every domain needs a permanent global override.

3. Trace domain rules and policy groups

In Rule mode, the core evaluates rules from top to bottom. The first matching rule determines the policy for that connection. A rule for the main website does not automatically cover every host used for sign-in, scripts, images, or API requests. The domains used by a service can change, so use the actual failed connections in the client rather than relying on an old copied list.

Inspect several relevant entries in the connection list and note the destination host, matched rule, policy name, and final outbound. If the client shows an IP address instead of a domain, DNS handling or domain recovery may be involved. If the rule points to a group, open that group and check its currently selected member. A correctly matched rule can still fail when its group selects an unavailable node.

The following fragment illustrates where to put explicit rules. It is not a complete configuration: replace Proxy with a policy group that actually exists in your active configuration. Preserve your other required rules and place these entries above broader rules that would otherwise match first.

mode: rule

rules:
  - DOMAIN-SUFFIX,chatgpt.com,Proxy
  - DOMAIN-SUFFIX,openai.com,Proxy
  - MATCH,Proxy

These example domain suffixes are starting points, not a complete or permanent inventory of service dependencies. Add another host only after confirming that it is relevant in the connection list. A rule for openai.com can match that domain and its subdomains, but it does not match unrelated domains. Likewise, rules should not be added simply because a hostname appeared in an unrelated browser request.

Many subscription profiles are generated or merged by the client. Editing a downloaded file directly may have no effect after a refresh, or may be overwritten when the profile is reapplied. Use the client’s supported override mechanism, or edit the active configuration in the way its documentation specifies. After applying a change, inspect the effective configuration and confirm that there are no duplicate top-level fields, misspelled policy names, or rules hidden below a catch-all such as MATCH.

4. Test a targeted fix, one change at a time

Use this sequence to narrow the issue without changing several network settings at once. Keep a copy of the original profile or note the existing values so you can roll back. For each test, use the same browser, network, and page action; otherwise, it is difficult to tell which change affected the result.

1. Establish a baseline. Confirm that the core is running, record the mode and selected policy, and test an unrelated HTTPS site. Note whether the ChatGPT request appears in the connection list and whether it fails immediately or after waiting.
2. Check node health. Select a different node in the same proxy group, then reload the page once. If the result changes, compare the old and new nodes and leave the group on a node that is actually reachable. Avoid repeatedly refreshing during a timeout; repeated attempts can create noisy logs and make comparison harder.
3. Compare modes briefly. If the active mode is Rule, compare a controlled request through the client’s Global policy. If that works, return to Rule mode and inspect the rule match and group selection. Do not interpret a Global-mode success as a reason to leave all traffic on Global permanently.
4. Correct a confirmed rule mismatch. If the connection list shows a relevant host going to DIRECT or the wrong group, add or adjust a domain rule in the active configuration. Put it above the broader rule that currently captures the connection, apply the profile, and verify the new match in the connection list.
5. Test DNS only if evidence points there. If lookups fail, addresses change unexpectedly, or the core reports DNS errors, check its DNS settings and whether the browser is using the resolver path you intend. Flush the operating system’s DNS cache only when appropriate for that system, then retry once. Do not change DNS mode merely because a web page times out.
6. Confirm the outcome. Test a fresh page load and, if relevant, sign-in or a new conversation. Check that both the main page and the failing related requests now use the expected policy and complete successfully.

For a basic DNS observation, query a relevant hostname with the operating system’s normal resolver tools, for example nslookup chatgpt.com on systems that provide nslookup. This tells you what that resolver returned at that moment; it does not prove that the browser used the same resolver, that the address is reachable through the selected route, or that the service is healthy. Compare results only as diagnostic evidence, and avoid treating a particular IP address as a fixed configuration value.

When testing from a terminal, make sure the command uses the same proxy path as the browser before comparing results. A terminal request that goes direct and a browser request that uses Clash are not equivalent tests. If you do not know how the terminal inherits proxy settings on your operating system, prefer the client’s connection list and browser diagnostics over an ambiguous command-line result.

5. Distinguish DNS, browser, and service-side failures

DNS is one possible cause, not a catch-all explanation for every timeout. A DNS lookup failure usually appears before a usable destination address is available. A TCP timeout points to a connection attempt that did not complete in time; the address in the log matters, because it may identify the proxy server rather than the ChatGPT destination. A TLS or certificate error is a different stage again. Read the complete error and correlate it with the connection record instead of making a change from one generic word such as “timeout.”

Fake-IP mode can return a synthetic address maintained by the core, rather than the destination server’s public address. That behavior is not automatically an error. Problems may occur if a client caches an old answer, if the connection does not return to the core that owns the mapping, or if a particular application handles the result unexpectedly. If you suspect a stale mapping, use the client’s documented DNS-cache controls and restart only the relevant application or core as needed. Switching DNS modes changes more than the displayed address and should be a measured test.

Use the browser’s developer tools when the main document loads but the interface is incomplete. In the Network panel, reproduce the issue once and inspect failed requests, status codes, and hostnames. A request that is blocked by a browser extension, rejected by the service, or waiting on a slow server can look different from a connection that never reached the core. Do not share a network export without removing cookies, authorization data, and other sensitive headers.

Try a clean browser profile or a private window with extensions disabled, while keeping the same Clash configuration and network. If that fixes the issue, investigate site data, extensions, cached service workers, or browser-specific proxy settings before changing core rules. If the same failure occurs across browsers and devices on the same network, compare a separate trusted network and check service status. These comparisons help separate browser-local problems from local network, route, and service-side problems.

If the connection appears to complete through the expected node but the application still returns an error, preserve the timestamp, error message, matched rule, and node name for further investigation. The response may come from the service, an account or session condition, or another dependency; adding broader domain rules cannot fix every application-level response. Reauthenticate only through the official service interface, and do not provide credentials to a third-party diagnostic tool.

6. Restore and document a working configuration

Once the cause is identified, return to the intended operating mode and remove temporary test changes that did not help. Keep only verified rules in the correct order, use a policy group that exists in the active profile, and confirm that subscription refreshes do not erase the fix. If the profile is managed remotely, use its supported override or ask its maintainer about persistent customization rather than repeatedly editing a generated file.

After applying the final configuration, verify three things: the browser request appears in the core’s connection list, the expected rule and outbound are selected, and the page or action that previously failed completes. Repeat the test after restarting the client if the settings are not persistent. If it fails again, record the core and client versions, operating system, mode, time, relevant error, and redacted connection details. This is more useful than reporting only that “ChatGPT is blocked.”

Do not leave debug logging enabled indefinitely; return to the normal log level after reproducing the issue. Avoid publishing subscription links, controller credentials, account data, or complete browser request headers. If a minimal rule, known-good node, and verified proxy path still fail while other sites work, check current service status and use the service’s official support options for account- or service-specific errors.