Fix ChatGPT Not Working With Clash: Check Rules, DNS, And Nodes

Identify Where the Connection Fails

When ChatGPT will not open through Clash, the visible symptom does not tell you which part is broken. The browser might not be using the system proxy, Clash might be in Direct mode, a routing rule might select the wrong policy, DNS might return an unusable address, or the selected node might fail to reach the service. A blank page, a sign-in loop, and an error while sending a message can therefore have different causes.

Start by recording the exact symptom and the path you are testing. Does chatgpt.com fail before the page appears, or does the page load but fail during sign-in or message submission? Does the same browser work when Clash is turned off? Does another device on the same network work? Change one setting at a time and retest; changing the mode, DNS, rules, and node together makes it much harder to identify the cause.

Also check whether the service is available for your account and in your location, and whether your network or proxy provider permits access to it. A proxy configuration cannot correct an account restriction, service outage, or provider-side policy. Avoid repeatedly refreshing a page that is already returning an access or rate-limit message; repeated requests can make the symptom less clear.

Keep a short test log with the time, client and core versions, active mode, policy shown for the request, and node tested. Do not include subscription URLs, access tokens, cookies, or private account information. The log helps distinguish a repeatable routing fault from a temporary service or network problem.

Check the System Proxy and Active Mode

A Clash desktop client normally combines a graphical interface with a proxy core. The interface manages configuration, proxy groups, and system integration; the core accepts connections, applies rules, and connects to the chosen proxy. Turning on the system proxy does not necessarily route every application, and enabling TUN is a separate way to capture eligible traffic. Begin with the simplest path your browser supports: the system proxy.

1. Confirm that the intended configuration is active and that the core is running. Check the client’s logs for configuration errors, failed provider updates, or repeated core restarts.
2. Open the client’s system-proxy control and enable it. Confirm that no other VPN or proxy application is replacing the operating system’s proxy settings.
3. Check the actual mode in the client. For the first test, use Rule mode with an applicable rule, or Global mode with a known working proxy group. Direct mode sends traffic directly and is not a test of the proxy route.
4. Open the connection list or traffic view while refreshing chatgpt.com. If no related connection appears, the browser may be bypassing the system proxy or the request may not be reaching the local listener.

Client labels and menu locations differ between Clash Verge, Clash Verge Rev, Clash for Windows, and other applications. Verify the state shown by the installed client rather than relying on instructions for a different version. If you use a browser proxy extension, check whether it overrides system settings or excludes the site from its proxy list.

If the client exposes local listener settings, use the address and port shown in that client. Do not assume that every installation listens on 127.0.0.1:7890; ports can be changed, and HTTP, SOCKS, and mixed listeners are not interchangeable in every application. If the browser is configured manually, verify that its proxy type and port match a listener that is actually running.

Route ChatGPT Domains Through the Intended Policy

In Rule mode, the core checks the active rules from top to bottom. The first matching rule determines the policy; a correct rule placed below a broader matching rule may never be reached. Check the connection details for the exact domain, matched rule, policy group, and selected node. A rule that sends the main page through a proxy does not prove that every sign-in or page resource follows the same route.

ChatGPT uses more than a single web address. The main site, authentication, static resources, and other service components can use different hostnames, and these may change over time. Start with the domains visible in the connection list when reproducing the failure. Common starting points include chatgpt.com and domains under openai.com; do not treat this as a permanent or exhaustive list of every dependency.

rules:
  - DOMAIN-SUFFIX,chatgpt.com,Proxy Select
  - DOMAIN-SUFFIX,openai.com,Proxy Select
  - MATCH,Your Existing Policy

This is a syntax example, not a complete configuration. Replace Proxy Select and Your Existing Policy with names that exist in your active proxy-groups and rules. Preserve your existing rules and place specific service rules above broad rules that could send the same traffic to DIRECT or another policy. If you use a managed subscription, prefer its supported override or rule configuration rather than editing a generated file that will be overwritten at the next update.

• Use a domain rule for a domain, not a full URL. Do not put https://, a path, or a query string in a DOMAIN-SUFFIX value.
• Make sure the policy name matches exactly, including spaces and capitalization where applicable.
• Check whether a rule provider is enabled and current. A rule visible in a local file may not be active if the provider failed to load.
• Do not add broad IP rules without evidence. A service can use changing addresses or shared hosting, so an IP rule may route unrelated traffic or stop working later.

For a controlled comparison, temporarily use Global mode with a known working proxy group, if your client supports it. If ChatGPT works in Global mode but not Rule mode, the issue is likely in rule matching, the chosen rule policy, or a domain that was not covered. If it fails in both modes, continue with the node, DNS, and network checks rather than adding increasingly broad rules.

Run a Controlled Test of Rules, DNS, and Nodes

Use this sequence to narrow down the fault without changing several variables at once. Keep the same browser, network, and test page while changing only the item named in each step. A successful page load is useful, but also try signing in and sending one short message; those actions can use additional requests and may reveal a connection that drops after the initial page load.

1. Confirm that Clash is handling the request. Enable the system proxy, open chatgpt.com, and inspect the live connection list. If no relevant traffic appears, fix the browser or operating-system proxy path before changing DNS rules.
2. Test a known proxy policy. In Global mode, select a node that has recently connected successfully. Retry the page once and note whether the connection is accepted, rejected, or left pending. Return to Rule mode after the test.
3. Compare the rule result. In Rule mode, inspect the exact matched rule and policy. If the selected policy is Direct or an unintended group, adjust the rule order or policy assignment, then repeat the same test.
4. Compare a second node. Keep the same mode and policy group, changing only the selected node. A different result suggests that the first node, its exit network, or the provider’s route to the service is involved.
5. Check DNS behavior. If the browser reports a name-resolution error or the connection list shows an unexpected destination, check the client’s DNS status and logs. Clear the browser’s DNS cache only after recording the current result, then retry once.
6. Compare another network or device. If practical, test the same configuration on a different network, or compare another device on the current network. This helps separate a local client issue from router, ISP, or provider behavior.

Do not interpret a single successful latency test as proof that a node can sustain every application connection. A URL test measures a request to its configured endpoint; ChatGPT can involve different destinations and longer exchanges. If the page repeatedly stalls after a node appears connected, test a second stable node and check the client logs for timeouts or connection resets.

Check DNS, Browser State, and Connection Stability

DNS problems can look like routing problems because the connection must first identify an address for a hostname. Clash clients and mihomo configurations can use different DNS modes, including fake-IP behavior. The correct choice depends on the active configuration and how the client handles DNS; changing a DNS mode without understanding its effects can break other applications or make domain-based rules less reliable.

Start with evidence from the client rather than adding arbitrary public DNS addresses. Look for DNS errors in the core log, compare whether the same hostname resolves on another device, and check whether the connection details show the expected domain. If you change DNS settings, make one change, restart or reload the core as required by the client, and repeat the same test. A DNS change cannot repair a node that cannot reach the destination.

Browser state can also contribute. A stale site cache, blocked cookies, strict privacy extensions, or a browser profile configured with a separate proxy can interfere with sign-in. Test in a private window or a clean browser profile without disabling security protections for the whole device. If the clean profile works, re-enable extensions one at a time to identify a local browser conflict.

• Check that the device clock and time zone are correct; authentication and secure connections depend on valid certificate timing.
• Temporarily test with browser extensions that change DNS, proxy, privacy, or request filtering disabled, then restore them after the comparison.
• Do not install certificates or turn off TLS verification to address a timeout. That does not fix a routing failure and can expose account traffic to interception.
• Do not repeatedly switch DNS servers, TUN, and rules in one session. Record the current settings and revert a test that does not improve the result.

When reporting a problem to a client or proxy provider, include the time of the failure, client and core versions, mode, the matched policy, node label, and a short log excerpt with private data removed. Redact subscription links, usernames, authorization headers, cookies, and account identifiers. A connection result and a sanitized log are more useful than a screenshot of credentials or the full configuration.

Decide Whether the Fault Is Local or Provider-Side

Use the comparisons to choose the next action. If the browser’s traffic never appears in Clash, focus on the system proxy, browser configuration, and other VPN software. If the request appears but receives the wrong policy, correct the rule or group selection. If the rule and policy are correct but only one node fails, report the node-specific result to the provider or choose another node. If all nodes fail only on one network, investigate local DNS, firewall, router, and upstream network conditions.

Keep the configuration as narrow as possible. A small set of verified domain rules is easier to maintain than routing all traffic through a broad rule added as a guess. After a working change, test the main page, sign-in, and one message in both the browser and any other application you use. Then check that unrelated sites still follow their intended policies.

Client interfaces and mihomo core versions do not expose identical settings, so consult the documentation for the specific client and core in use before applying advanced DNS or TUN changes. If you need a different client build for testing, use the download page and follow the installation instructions for your platform.