Fix ChatGPT Not Working With Clash: Access Troubleshooting

ChatGPT can appear to be unavailable even when Clash itself is running normally. The browser may show a timeout, a blank page, an endless verification loop, or a generic network error. In many cases, the problem is not the subscription or the account. It is usually caused by one of four layers: the system proxy is not active, the selected node cannot reach OpenAI services, the routing rules send ChatGPT traffic directly, or DNS and TUN interception are inconsistent.

This guide provides a focused way to fix ChatGPT not working with Clash on Windows, macOS, Linux, Android, and similar Mihomo-based clients. The goal is not to change every setting at once. Instead, test one layer at a time: verify the active proxy, check a known-good node, confirm the rule match for OpenAI domains, then enable TUN only when ordinary system proxy mode cannot capture the traffic.

Identify the Failure Layer First

Before editing a YAML file or switching DNS modes, describe the exact symptom. Different symptoms usually point to different causes, and a precise observation can save a great deal of trial and error.

SymptomMost likely causeFirst test
Every website is slow or unavailableClash is not connected, the port is blocked, or the selected node is downOpen a simple public website and test the node from the client
Other sites work, but ChatGPT times outOpenAI traffic is routed directly or the node cannot reach the serviceInspect the rule match for chatgpt.com and openai.com
ChatGPT opens but remains on verificationIncomplete domain routing, blocked cookies, DNS inconsistency, or unstable exit IPUse a different node and check related domains in connections
The browser works, but the desktop app does notThe app ignores the system proxy or needs TUN interceptionCheck whether the application supports an HTTP proxy setting
Only one device failsLocal proxy mode, DNS cache, firewall, or client-specific configurationCompare the same node and profile on another device
ChatGPT works briefly, then disconnectsNode instability, connection reuse problems, or frequent IP changesRun a latency and availability test over several minutes

Keep the troubleshooting scope narrow. Do not simultaneously replace the profile, change the DNS provider, enable TUN, install browser extensions, and modify system firewall rules. If the problem disappears, you will not know which change helped. A controlled sequence also makes it easier to undo an unsafe or unnecessary setting.

Start with the simplest question: can the currently selected Clash node open a normal HTTPS website? If the answer is no, ChatGPT-specific rules are not the first issue to fix. Restore a working proxy connection before changing routing.

Verify Clash and the System Proxy

A Clash dashboard can show that the core is running while applications still connect directly. These are separate states. The core may be healthy, but the system proxy toggle may be disabled, another application may be occupying the configured port, or the browser may have its own proxy settings.

First, check the client status:

  • Confirm that the Clash or Mihomo core is running without an error.
  • Confirm that the active profile has loaded successfully and contains proxy nodes.
  • Check the HTTP or mixed port shown by the client, such as 7890 or another local port.
  • Enable the client's System Proxy option for normal browser traffic.
  • Make sure no VPN, corporate proxy, browser extension, or second Clash instance is overriding the same settings.

On Windows and macOS, system proxy mode is normally enough for browsers and many desktop applications. On Android, the equivalent may be a VPN-based mode provided by Clash for Android or Mihomo-compatible clients. On Linux, desktop environments differ: some applications read the desktop HTTP proxy, while command-line tools may require explicit environment variables.

You can test a local HTTP proxy from a terminal. Replace the port if your client uses a different value:

Test the Local HTTP Proxy
curl -I -x http://127.0.0.1:7890 https://chatgpt.com
curl -I -x http://127.0.0.1:7890 https://www.google.com

A successful response does not necessarily mean that the page will load perfectly, but it confirms that a process can reach the local proxy and that Clash is accepting HTTP proxy requests. If the command reports “connection refused,” check the port number and whether the core is running. If the request hangs, inspect the selected node and the Clash connection log.

Also test the browser independently. Open its network or proxy settings and verify whether it is set to use the operating system proxy. Private browsing mode can help identify extensions that block scripts or modify requests. Clear only the site data for ChatGPT if necessary; deleting all browser data is rarely the best first step.

Check Traffic in the Dashboard

Open the Connections or Logs panel in Clash, then load https://chatgpt.com in the browser. You should see requests for the main site and related OpenAI domains. Observe three details:

  • Whether a connection appears: no entry usually means the browser is bypassing Clash.
  • Which rule matched: a DIRECT result indicates that routing may be too broad or ordered incorrectly.
  • Which proxy group was selected: a failed or unexpected group can send traffic through an unsuitable node.

This dashboard observation is more reliable than guessing from the interface icon. A green Clash icon only confirms that the client is enabled; it does not prove that ChatGPT traffic is using the intended proxy.

Select and Validate a Working Node

Not every node that passes a latency test can access every service. A latency check usually measures whether a small request reaches a test URL. It does not guarantee that the node can establish a stable TLS session, resolve all required domains, or maintain long-lived streaming connections used by ChatGPT.

Start by manually selecting a node from a region that normally provides stable access to the service. Avoid judging a node only by its displayed ping. A node with a slightly higher latency may be much more reliable than one with a low ping but frequent packet loss.

Test factorWhat to observePractical interpretation
LatencyResponse time to the test URLUseful for ranking nodes, but not a complete access test
AvailabilityWhether repeated checks succeedRepeated failures indicate an unstable or overloaded node
Page loadingChatGPT homepage, login, and conversation viewConfirms more than a simple TCP or HTTP health check
Streaming stabilityWhether generated replies continue without interruptionReveals packet loss, timeout, or long-connection problems
Exit IP consistencyWhether the public IP changes during a sessionFrequent changes can trigger repeated verification or login checks

When testing, use the same browser, profile, and account. Open the homepage, sign in, start a short conversation, and wait for the response to finish. Then repeat the test with a second node. If one node works and another does not, do not immediately modify DNS or TUN. The evidence points to node quality, route availability, or the node's exit network.

Once you identify a reliable node, assign it to a dedicated proxy group rather than leaving ChatGPT traffic tied to an unknown default. A simple group can make the intended route visible and easier to change later.

Dedicated OpenAI Proxy Group
proxy-groups:
  - name: OpenAI-Proxy
    type: select
    proxies:
      - node-us-01
      - node-jp-01
      - Auto-Select
      - DIRECT

Use the exact node names from your profile. YAML is sensitive to indentation, spelling, and duplicate names. If a referenced node does not exist, the group may not behave as expected. After editing, reload the profile and confirm that the group appears in the client before testing the website again.

Correct OpenAI Routing Rules

Clash evaluates rules from top to bottom and uses the first matching rule. This ordering is critical. A broad rule such as GEOIP,CN,DIRECT, a catch-all domain provider, or a final MATCH,DIRECT can send ChatGPT requests out directly if the OpenAI rules appear later in the file.

Place the service-specific rules before broad regional or final rules. The exact domains may change over time, so inspect the live connection list and maintain the list according to the services you actually use. A practical starting point is:

OpenAI Routing Rule Example
rules:
  - DOMAIN-SUFFIX,chatgpt.com,OpenAI-Proxy
  - DOMAIN-SUFFIX,openai.com,OpenAI-Proxy
  - DOMAIN-SUFFIX,oaistatic.com,OpenAI-Proxy
  - DOMAIN-SUFFIX,oaiusercontent.com,OpenAI-Proxy
  - MATCH,PROXY

The last rule in this example is intentionally broad. If your configuration uses a regional direct rule or several rule providers, place the OpenAI entries above them. If your profile uses a provider for application categories, inspect its contents rather than adding duplicate rules blindly. Duplicate rules are not always harmful, but they make diagnosis harder and can hide an ordering mistake.

When the page loads partially, watch the dashboard while refreshing it. Static files, API requests, authentication requests, and conversation streams may use different hostnames. If the main page uses the proxy but a required API or content domain is marked DIRECT, the interface can look loaded while login or message generation fails.

Do not route every domain through a random node as a permanent fix. A temporary broad proxy rule can help isolate a routing problem, but it may increase latency and send unrelated private or local traffic through the proxy. Narrow the rule set again after identifying the required domains.

Follow This Hands-On Troubleshooting Sequence

The following sequence is designed to produce one clear result at each stage. Perform it in order and record the outcome. If a step fixes the problem, stop there before making further changes.

  1. Close extra network tools. Temporarily disable another VPN, proxy extension, traffic filter, or second Clash process. Multiple interception layers can create loops or conflicting routes.
  2. Reload the profile. Confirm that the configuration loads without YAML errors and that the expected proxy group is available.
  3. Enable system proxy mode. Use the local HTTP or mixed port shown in the client. Do not assume the default port is correct.
  4. Test a normal HTTPS site. If it fails, select another node and inspect the connection log. Do not edit ChatGPT rules yet.
  5. Open the Clash dashboard connection view. Load ChatGPT and verify that requests appear. No request means the browser or application is bypassing Clash.
  6. Inspect the matched rule. Confirm that ChatGPT and OpenAI domains are assigned to OpenAI-Proxy or another intended proxy group, not DIRECT.
  7. Test two or three nodes. Use the same page and the same short prompt. Keep the node that completes the full sequence reliably, not merely the one with the lowest ping.
  8. Clear limited site data. Remove cookies and cached data only for ChatGPT if an old session is stuck in a verification loop. Then restart the browser.
  9. Check DNS only after routing is confirmed. If the dashboard shows DNS failures, timeouts, or inconsistent domain resolution, review the DNS mode and upstream servers.
  10. Enable TUN as a final capture method. Use it when the application ignores the system proxy or when traffic is not visible in Clash despite correct browser settings.

After each change, repeat the same test. A useful test is to open the site, sign in, send a short message, and wait for the complete response. Testing only the homepage can miss failures in the API or streaming connection.

Use TUN Mode Only When Necessary

System proxy mode works at the application level. Programs that understand HTTP or SOCKS proxy settings can send traffic to Clash, but some applications ignore those settings, use their own networking stack, or connect through protocols that are not handled by a standard browser proxy. TUN mode creates a virtual network interface and lets Clash intercept more traffic at the system level.

TUN is particularly useful when the browser works but a desktop ChatGPT application does not, when a command-line client bypasses the system proxy, or when the client reports no connection even though the application is clearly making requests. Mihomo-based clients commonly expose TUN settings such as auto route, strict route, DNS hijacking, and the virtual interface stack.

Enable TUN carefully:

  • Run the client with the permissions required by your operating system.
  • Enable automatic route installation if your client recommends it.
  • Use DNS hijacking only when you understand how it interacts with your local network and existing VPN software.
  • Keep system proxy mode and TUN mode from creating duplicate or circular paths.
  • Exclude local networks, printers, routers, and other private destinations if they stop working.

For Mihomo configurations, a basic TUN section may look like this, although field support varies between clients and versions:

Basic Mihomo TUN Example
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

Do not copy this block into an older Clash client without checking its documentation. Classic Clash builds and different graphical clients may use different supported fields. If the client provides a graphical TUN switch, use that first and inspect the generated configuration. When TUN is enabled, test both ChatGPT and local resources. A successful ChatGPT connection is not enough if it breaks local network access or causes all DNS requests to loop.

Check DNS, Browser, and Firewall Conditions

DNS problems can look like proxy failures. If the domain resolves to an unusable address, the request may never reach the rule engine in the expected form. Mihomo commonly works well with fake-IP DNS when TUN interception is enabled because domain-based rules can be applied before the real destination IP is exposed. However, fake-IP is not a universal cure. Some applications require real IP responses, and an incorrectly configured fake-IP range can cause connection failures.

Change one DNS variable at a time. Confirm that the DNS server is reachable, that the selected mode is supported by your client, and that the dashboard does not show repeated resolution errors. Flush the operating system DNS cache after a configuration change, then restart the browser so it does not reuse stale results.

Browser state is another common source of confusing behavior. A corrupted service worker, blocked third-party cookies, strict content filtering, or an extension that rewrites headers can prevent the application from completing its login flow. Test with a clean private window, then disable extensions temporarily if the private window works. Avoid installing unknown “proxy fix” extensions; they can override Clash and expose credentials or traffic.

Finally, inspect local security software. Firewalls and endpoint protection products may block the Clash core, its local port, the TUN driver, or a newly created virtual adapter. Allow the specific Clash application through the firewall rather than disabling all protection. On managed work or school networks, outbound proxy traffic may also be restricted by policy; in that situation, changing local YAML rules cannot override the network administrator's controls.

Use the connection log as your source of truth. If a request is visible and matched to the intended proxy group, the remaining investigation belongs to the node, DNS, TLS, browser session, or remote service. If no request is visible, fix traffic capture first.

Keep the Fix Stable and Easy to Maintain

Once ChatGPT works, write down what solved the problem: the client version, profile name, selected group, working node region, system proxy or TUN mode, and any DNS change. This small record prevents you from repeating the entire investigation after a profile update or device restart.

Prefer a dedicated OpenAI-Proxy group and a short, clearly ordered rule set. Use an automatic test group only after confirming that its test URL reflects the type of reliability you need. A node with excellent latency to a generic test endpoint may still be poor for long-lived HTTPS and streaming traffic. Set a reasonable test interval and avoid switching nodes too aggressively, because frequent exit-IP changes can cause repeated verification challenges.

Review rule providers periodically. A provider may add a broad rule above your local service rule, change a domain list, or become temporarily unavailable. Keep local overrides near the top when your client supports them, and reload the configuration after updates. If a future change breaks ChatGPT, compare the current connection log with the notes from the working setup instead of resetting every setting.

The most reliable fix is usually straightforward: activate the correct proxy mode, choose a stable node, route the relevant OpenAI domains through that node, and use TUN only for applications that bypass ordinary proxy settings. With this layered approach, you can isolate the actual failure and maintain a Clash configuration that remains understandable rather than accumulating unrelated workarounds.

Get Started

Take Full Control of Your Traffic with Clash

Available on Windows, macOS, Linux, Android, and iOS. Flexible rules, simple setup, ready to use.

Download Free View Setup Guide →
Get Started

Take Full Control of Your Traffic with Clash

Available on Windows, macOS, Linux, Android, and iOS. Flexible rules, simple setup, ready to use.

Download Free View Setup Guide →
Download Clash
All platforms supported. One-click traffic control, no complex setup required.
Download Free