Clash subscription update failed? Fix parse errors, expired links & User-Agent issues

Separate ChatGPT timeouts from other failures

When ChatGPT does not load through Clash, “it doesn’t work” can describe several different problems: the page never opens, sign-in loops, the interface loads but replies stall, or a request ends with a network error. Those symptoms can point to different layers. A timeout may come from the selected node, a rule sending traffic DIRECT, DNS returning an unusable address, or an application connection that is not captured by the system proxy. Changing nodes repeatedly before identifying the symptom can hide the cause rather than fix it.

Start by noting exactly what happens and when. Does chatgpt.com fail to open, or does the site load and then stop when you submit a prompt? Does the same issue affect other sites using the proxy? Does ChatGPT work in a private browser window, on another device, or with Clash temporarily disabled? Record the approximate time, active profile, mode, selected policy group, and whether TUN is enabled. Avoid including account credentials, conversation contents, or subscription links in any diagnostic notes you share.

• Page does not open: Check DNS, the rule match, the selected egress, and whether the browser is using Clash at all.
• Page opens but sign-in fails: Check whether related authentication requests use the same working proxy route. A cached session or browser extension can also affect the result.
• Prompt submission stalls: Check connection logs while submitting once. The page may load successfully even when a later API or streaming connection is failing.
• Only one node fails: Test a second node with the same mode and rule configuration before changing DNS or reinstalling the client.

Verify Clash mode and the actual rule

Clash can route traffic in rule, global, or direct mode, though the labels and menu locations differ between clients such as Clash Verge Rev, Clash for Windows, ClashX, and mobile clients. In rule mode, the core checks rules from top to bottom and uses the policy on the first matching rule. The proxy group you selected in the interface only affects connections routed to that group. In global mode, connections generally use the selected global policy, subject to client and configuration behavior. In direct mode, traffic is not sent through the selected proxy policy.

First confirm that the client is started, the intended profile is active, and the core is running without configuration errors. Then check the mode and open the connection or log view. Load ChatGPT or submit one test prompt and find the new connections. Look for the requested hostname, the matched rule, the policy group, the final node, and the connection result. This is more reliable than assuming that a changed node affects every application.

• If the connection shows DIRECT, inspect the matched rule and rule order. A broad direct rule placed above a ChatGPT-related proxy rule may take precedence.
• If it shows a proxy group, open that group and verify which node it currently selects. A group can contain another group, so check the final node rather than stopping at the first policy name.
• If there is no connection entry, the application may not be using the system proxy, TUN may not be capturing it, or the request may not have been made during the time window you are viewing.
• If the connection is rejected or times out, note the log detail and compare another node. A timeout is not, by itself, proof of a DNS failure.

For a temporary routing test, switch to a known working proxy policy and reload the site. In rule mode, you can also add a narrow test rule above conflicting rules, provided the policy name exists in the active configuration:

rules:
  - DOMAIN-SUFFIX,chatgpt.com,PROXY
  - MATCH,FINAL

PROXY above is only an example policy name. Replace it with the name of an existing proxy group in your configuration. Do not paste the example blindly if your profile uses another group name, and do not add a second rules: section. Rule syntax and supported rule providers depend on the core and configuration. A temporary rule for one domain also does not automatically route every related sign-in or service request; use the connection view to identify the actual hostnames involved, and avoid adding broad rules based only on guesses.

Check the node and test the local proxy port

Once the connection is confirmed to use a proxy policy, test whether the selected node can establish ordinary HTTPS connections. Manually choose a second node in the same group, if available, and repeat the same page load. Keep the mode, profile, browser, and network unchanged. If one node works and another consistently times out, the issue is likely related to that node or its route. If several nodes fail while unrelated local proxy tests also fail, check the core, local port, and network before editing ChatGPT rules.

Most desktop clients expose a local HTTP, SOCKS, or mixed proxy port. The port is configurable; 7890 is a common example, not a universal default. Confirm the actual value in the client or active configuration. For example, a configuration may contain:

mixed-port: 7890
allow-lan: false
mode: rule

If the local HTTP or mixed port is 7890, you can ask curl to use it for a basic HTTPS request:

curl -I --proxy http://127.0.0.1:7890 --max-time 15 https://chatgpt.com/

Replace the port with the one configured on your device. A response from the server indicates that this particular request completed through the local proxy, but it does not prove that browser sign-in, every related hostname, or long-lived response streaming works. An HTTP status such as 403 is also different from a connection timeout: it means an HTTP response was received, not that the route necessarily matches the service’s access requirements. If the command reports that it cannot connect to 127.0.0.1, check whether the client and core are running and whether the port is correct.

Use the client’s connection log to confirm which node handled this test if the client records command-line proxy requests. If the command succeeds through one node but the browser still fails, focus on browser proxy settings, extensions, cached sessions, or traffic capture. If it fails through multiple nodes, compare with another ordinary HTTPS destination and note whether the failure is a local refusal, DNS error, TLS error, or timeout. Each result points to a different layer.

Inspect DNS without changing every setting

DNS can contribute to connection failures, but it is only one possible cause. Clash or mihomo may resolve names through the system resolver, configured upstreams, or an enhanced DNS mode such as fake-IP, depending on the profile and core. The client may also apply DNS settings differently from a browser using secure DNS. A successful lookup does not confirm that the selected proxy node can reach the destination, and changing DNS servers does not correct a rule that routes traffic DIRECT.

Check the core log around the time of a failed request for messages mentioning DNS resolution, a failed upstream, or a hostname that could not be resolved. Compare the same request with another node while leaving DNS settings alone. If the error explicitly indicates resolution failure, then inspect the active DNS configuration and confirm that its upstream servers are reachable from the current network. If the log shows a resolved address followed by a connection timeout, investigate the route, node, and policy instead.

• Confirm that the active profile’s DNS section is the one you are editing; some clients apply overrides or generate configuration from a subscription.
• Check whether the browser has secure DNS enabled. It may send DNS requests independently of the system resolver, so browser behavior can differ from other applications.
• Do not add guessed IP addresses to the hosts file. Service addresses can change, and pinning an old address can create a new failure.
• Do not switch several DNS fields at once. Change one setting, restart or reload the core if required, and repeat the same test so the result can be interpreted.

Run a controlled rule, DNS, and TUN test

Use the following sequence to isolate the failure. Change one factor at a time and keep a short note of the result. This avoids mistaking a coincidental improvement for a confirmed fix.

1. Record the baseline. Note the client and core versions, active profile, mode, proxy group, selected node, local proxy port, and TUN state. Capture the exact browser error and time, but do not record passwords or private account data.
2. Confirm a fresh connection. Close the failing ChatGPT tab, open the client’s connection view, then load the site once. Check whether a new connection appears and what rule and policy it uses. If the connection is absent, investigate application capture before adjusting the node.
3. Test a working node. Keep rule mode and all other settings unchanged. Select a node that has recently worked for ordinary HTTPS traffic, reload ChatGPT, and check the log again. If this resolves the issue, compare the original and replacement nodes before changing DNS.
4. Compare rule mode with a temporary global test. If the client supports it, select global mode briefly and route through the same known working group. Do not leave the client in global mode if your normal setup requires rule-based routing. If the site works only in global mode, return to rule mode and investigate the matched rule or missing policy route.
5. Test DNS only when the evidence points there. Look for a resolution error in the core log. If present, make one reversible DNS change using the client’s supported settings, reload the core if necessary, and repeat the same request. Restore the original setting if the result does not improve.
6. Test TUN separately. If browser traffic does not appear in the connection view and the browser is not using the system proxy, check whether TUN is enabled and permitted. Enable it only if the client and core support it and your system grants the required network permissions. Then repeat the test and confirm the connection is captured.
7. Restore and document. Return to your normal mode and settings after testing. Keep only the change that has a repeatable effect, and save the working configuration before making further edits.

A result is most useful when it is repeatable. For example, if the same node consistently works in global mode but fails in rule mode, the evidence favors a rule or policy issue. If both modes fail on one node but work on another, the node or its route is a stronger suspect. If neither mode creates a connection entry until TUN is enabled, traffic capture is the likely gap.

Use TUN for a capture problem, not as a universal fix

The system proxy usually affects applications that honor the operating system’s proxy settings. Some applications, command-line tools, and browser configurations may ignore those settings or use their own proxy. TUN creates a virtual network interface so a supported core can capture and route more system traffic. It can help when a program bypasses the system proxy, but it does not automatically fix a bad node, incorrect rule, blocked upstream DNS server, or invalid profile.

Before enabling TUN, check that the client’s core supports it, the required service or permission is active, and no other VPN or network filter is conflicting. On Windows, a client may require administrator approval or a helper service; on macOS, it may require approval for a network extension; on Linux, it may need suitable privileges and routing setup. The exact steps depend on the client and operating system. After enabling TUN, verify that the new ChatGPT connection appears in the client’s connection list and matches the expected rule. If it does not, inspect the TUN startup log rather than repeatedly toggling the feature.

If Clash logs show the expected proxy route but the browser still fails, test a clean browser profile or private window, temporarily disable proxy-changing extensions, and check whether secure DNS or a separate VPN is active. Clear site data only if you can sign in again safely; clearing cookies may sign you out. Do not disable system security software permanently to test a connection. If another network works while the original network does not, check router filtering, captive portals, or network-level restrictions before changing the Clash profile.

Keep the fix narrow and reversible

When a test identifies a cause, make the smallest change that addresses it. If a rule sends the request DIRECT, correct the relevant rule or policy rather than replacing the entire profile. If one node is unreliable, use another node or report the test details to the provider. If DNS is demonstrably failing, change the active resolver through the client’s supported configuration and preserve the previous values. If the browser bypasses the system proxy, decide whether TUN is appropriate for that device instead of enabling unrelated features.

After applying a change, restart or reload the core only when the client requires it, then repeat the original test under the same conditions. Check both the browser result and the connection record. A page that opens once is not enough to establish that streaming replies and sign-in work consistently; repeat a normal page load and one short prompt test, then observe whether the connection completes without a timeout.

If the problem remains, prepare a concise diagnostic report: client and core versions, operating system, mode, whether TUN is active, the matched rule and policy, node identifier with sensitive details removed, timestamp, and the sanitized error line. Redact subscription URLs, credentials, UUIDs, tokens, and personal information before sharing logs. These details make it easier to distinguish a routing problem from a DNS failure or an unstable node without exposing account data.