Proxy Certificate Error Troubleshooting

First, identify where the certificate error occurs

A certificate warning after enabling a proxy does not mean Clash needs a root certificate installed. Standard HTTP CONNECT, SOCKS, and TUN forwarding typically change only the traffic route; your browser should still complete a TLS handshake with the destination site and verify its certificate. Check the error code, the domain on the certificate, and its issuer first. Then check your system clock and actual exit route—this is more useful than reinstalling the client.

There are two separate encrypted connections to consider: HTTPS between your browser and the destination site, and possibly TLS between the proxy core and the proxy server. A browser error such as NET::ERR_CERT_AUTHORITY_INVALID is not the same issue as x509: certificate signed by unknown authority in the core logs.

Record the full NET::ERR_CERT error code

“Your connection is not private” is just the warning heading; the error code that follows is what helps pinpoint the cause. Chrome and Edge use similar codes, while Firefox uses different names, but the troubleshooting approach is much the same. Browser versions, system trust stores, and enterprise policies can also affect the exact message.

• NET::ERR_CERT_DATE_INVALID: Your device's clock may be wrong, or the certificate may be expired or not yet valid. Compare the system date with the certificate's validity period—not just the time shown in the taskbar.
• NET::ERR_CERT_AUTHORITY_INVALID: The browser can't build a trusted certificate chain. Possible causes include a self-signed certificate, a missing intermediate certificate, a problem with the local trust store, or HTTPS inspection software.
• NET::ERR_CERT_COMMON_NAME_INVALID: The certificate's Subject Alternative Name (SAN) doesn't cover the domain you're visiting. Despite the legacy error name, modern browsers don't check only the Common Name (CN) field.
• NET::ERR_CERT_REVOKED: The certificate has been identified as revoked. The site owner or administrator should replace it; weakening browser certificate checks is not an appropriate workaround.

Check at least four certificate details

Use the certificate link on the warning page or the site information panel in the browser's address bar to check the domain, SAN, issuer, and validity period. The exact steps vary by browser version. If you can't open the details, note the error code and time instead. If several unrelated sites suddenly show certificates issued by the same unfamiliar organization, suspect HTTPS interception before assuming those sites all misconfigured their certificates at once.

On the other hand, a matching issuer alone is not proof of interception: many sites use the same public CA. Consider the certificate chain, domain, network environment, and whether HTTPS inspection software is installed.

Step 1: Sync the system clock and compare results

Sync your system clock first

On Windows 11, open Settings → Time & language → Date & time, check Set time automatically, then select Sync now. On macOS, open System Settings → General → Date & Time and check automatic time settings. Verify the year, month, day, time zone, and whether synchronization succeeded. Changing the displayed time zone alone won't fix an inaccurate system clock.

Waking from sleep, switching between operating systems, or clock drift in a virtual machine can make a certificate appear “not yet valid.” Correct the clock, reconnect, and test again. If only one site still reports an expired certificate while other HTTPS sites work, check that site's certificate instead of changing system-wide settings.

Run four tests with the same URL

1. Record the full URL, the time of the error, and whether the client is in Rule or Global mode.
2. Keep the URL unchanged, turn off the system proxy, and explicitly disable TUN too if it's enabled. Then test again.
3. Re-enable the original proxy route, change only the node, and see whether the certificate error follows the node.
4. If possible, test the same URL on a mobile hotspot or another device to distinguish a local issue from a network issue.

Change one variable at a time. Browser extensions can still route traffic through a proxy when the system proxy is off; the system proxy can remain active when TUN is off. Check the client's connection records rather than relying on a single toggle to confirm a direct connection. If direct access doesn't work, that test is inconclusive—it doesn't prove the proxy route is safe or faulty.

Step 2: Check for HTTPS interception and captive networks

Antivirus “HTTPS scanning,” packet-capture tools, corporate gateways, and some debugging proxies can terminate the browser's TLS connection, then issue a local certificate for the destination domain. The browser will warn if it doesn't trust the corresponding root certificate. Even if it does, confirm that this interception is part of a policy you expect.

• Personal devices: Think back to whether you recently enabled a packet-capture tool, installed network security software, or imported a certificate. Restore the intended HTTPS inspection settings through the relevant software. Don't bulk-delete system root certificates.
• Work or school devices: Compare the issuer name with your organization's guidance, and ask your administrator to confirm the root certificate deployment and proxy policy. Don't remove managed certificates or bypass organizational access controls.
• Hotel, airport, and guest Wi-Fi: Complete sign-in through the network login page opened by your device. If the captive portal intercepts HTTPS incorrectly, it may return a certificate for the wrong domain. Never enter credentials on an HTTPS warning page that may have been intercepted.

Step 3: Check the node, DNS, and routing rules

Check connection records before changing rules

In Rule mode, traffic is routed according to rule order, and a policy group name doesn't tell you which node was ultimately selected. Find the destination domain in the client's connection records or logs, then check the matched rule, policy chain, and final exit node. Menu names vary by client but are often “Connections” or “Logs.” If you see only a policy group, check which option is currently selected within it.

A DNS error can send a request to the wrong server, which may return a certificate for another domain; DNS problems more often cause resolution failures or timeouts, though. With fake-ip, seeing a mapped address in the 198.18.0.0/16 range doesn't by itself mean DNS is being poisoned. mihomo can map the address back to the domain and continue forwarding the request.

If the error occurs with only one node and another works, compare the certificates actually received over each route. Interference on the exit network, CDN edge configuration, and regional differences in the destination service can all play a part. “It works after switching nodes” is a useful clue, not proof that the node is stealing traffic. Avoid changing DNS, switching to Global mode, enabling TUN, and rewriting rules all at once—you'll make the issue harder to reproduce.

For x509 errors in core logs, check the node configuration

If a webpage simply won't connect but the client logs an x509 error for the node server, investigate the node's TLS layer. The certificate domain, connection address, and SNI don't always match. For example, a node may connect by IP while using a provider-supplied domain for server name verification. Check the provider's valid configuration; don't guess a popular domain and enter it.

mihomo node TLS options may include skip-cert-verify. Setting it to true skips certificate verification for the node; it won't fix the destination site's certificate in your browser and reduces assurance that you're connecting to the right node. The proper fix is usually to correct the certificate chain, server name, or server certificate—not to use this option as a universal switch.

Step 4: Use curl to distinguish tunnel issues from certificate errors

Command-line tests can add context to a browser warning, but first confirm the actual listening port. The example below uses a local HTTP or mixed port, 7890; this is an example, not a default for every client. The target is https://example.com/. To reproduce your issue, replace it with the affected URL, without any tokens.

# Don't use an explicit proxy; traffic may still be captured if TUN is enabled
curl -Iv --noproxy "*" https://example.com/

# Explicitly establish a CONNECT tunnel through the local HTTP proxy
curl -Iv --noproxy "" --proxy http://127.0.0.1:7890 https://example.com/

In Windows PowerShell, use curl.exe instead of curl to avoid having it interpreted as a different command in some environments. -I requests response headers, while -v prints connection diagnostics. If a site doesn't support HEAD, remove -I and redirect the response body to the local null device.

Don't add -k or --insecure and claim the “problem is fixed.” These options skip certificate verification and change the test conditions. curl and browsers may also use different TLS backends, trust stores, or DNS routes. If one succeeds and the other fails, investigate those differences instead of trusting just one result.

Finally, check browser state and the site's certificate chain

Cached data is rarely the first explanation for a certificate error. Clearing all browsing history usually won't fix an expired certificate, a domain mismatch, or an untrusted issuer. A safer sequence is to close the affected tabs, fully quit the browser, and retry; then compare with a temporary new profile or another browser.

• Only one browser fails: Check for browser updates, proxy extensions, enterprise policies, and certificate trust settings. Incognito mode may still be affected by the system proxy, organizational policies, or permitted extensions, so it isn't a fully isolated environment.
• Only an older device fails: Check whether the operating system is still supported and whether its trust store is up to date. Don't download root certificate patches from forums; use update channels provided by the operating system and browser.
• The same site fails on multiple devices and networks: The site's certificate may have expired, an intermediate certificate may be missing, or a CDN edge may have a misconfigured certificate. Record the domain, time, and certificate details and send them to the site operator.
• It works briefly after clearing state, then fails again: Continue checking connection reuse, DNS results, and whether the actual node changed. Don't assume that a change in timing means clearing the cache fixed it.

Sites that use HSTS require HTTPS, and the browser may not offer a way to continue. That's the security policy working as intended; don't delete HSTS state to bypass the error. The real fix is a successful connection with normal certificate verification enabled, using a certificate that covers the destination domain and has a valid chain and validity period.

What to do based on your findings

1. All sites work again after correcting the clock: Check time synchronization, sleep recovery, or dual-boot clock issues. Leave certificate verification enabled.
2. The same issuer appears only on a managed network: Ask your administrator to confirm HTTPS inspection deployment. Don't import a root certificate from an unknown source.
3. The error follows a single node: Keep the node identifier and redacted logs, switch to a route that verifies correctly, and report the issue to your provider.
4. Only subscription updates fail: Check the subscription domain and its certificate, and confirm whether update requests use the proxy. Never post a private subscription URL on a public testing site.
5. The same site fails on every route: Send the site operator its certificate validity period, SAN, and the time you reproduced the issue, then wait for the certificate deployment to be fixed.

Useful details to send the site operator include your operating system and browser versions, client and core versions, the full error code, time of the error, affected domain, and results after switching nodes or networks. Record client and core versions separately; similar-looking interfaces don't guarantee identical certificate handling. See the user guide for more help, or check the FAQ for general connection issues.

Bottom line: First determine whether the error is in the browser, node TLS, or subscription request. Then check the system clock, certificate issuer, actual exit route, and local device state in that order. The fix is a successful connection with certificate verification enabled—not ignoring warnings or disabling checks.