Why Clash Triggers Browser HTTPS Certificate Errors (and How to Fix Each Case)
Certificate errors aren't always the proxy software's fault: clock drift, captive portals, MITM decryption toggles, and broken certificate chains can all trigger them. This piece explains how proxying relates to TLS certificate validation and gives a fix for each scenario.
Why proxying even touches certificate validation
Certificate validation for an HTTPS connection happens during the TLS handshake, performed by the client (browser or OS), and has no direct causal link to whether a proxy is in use — a proxy's job is simply to relay packets to the destination server; the certificate itself is returned by the server and checked by the client. In most cases, the Clash or Mihomo core operates in pure forwarding mode: it routes TCP/UDP traffic to the matching node according to rules, and the payload passes through the transport layer untouched — no certificate is unpacked or re-issued. The browser still sees the website's own certificate chain. When enabling a proxy triggers a certificate error under this mode, it's almost always "the proxy changed the connection path and exposed some other pre-existing issue," not the proxy forging a certificate.
There is one exception: some clients offer an "HTTP capture / MITM decryption" feature for inspecting request details or debugging rules. This feature enables a locally generated root certificate, and the proxy process uses it to re-sign decrypted connections before forwarding the content. If this toggle is on and the root certificate hasn't been trusted by the OS or browser, the certificate chain will fail validation outright, and the error typically reads something like "untrusted issuer" or "certificate signed by an unknown authority." This is the only scenario where the proxy software's own certificate mechanism directly causes the error, and telling it apart from the rest is the first step of diagnosis.
Three things to check before diving in
Before working through specific scenarios, checking the following three points in order will quickly narrow down the problem.
- Is the system clock and time zone correct?
TLS validation compares the current system time against the certificate's validity window. If the system clock is earlier than the certificate's start date or later than its expiry, the certificate is judged invalid outright, regardless of any proxy. Turning on automatic network time sync, or manually checking the time and time zone, is one of the most overlooked yet most common causes.
- Is the proxy system-wide or browser-only?
In system-wide mode, every app's traffic is evaluated against proxy rules; with a browser-extension-only proxy, other apps are unaffected. If the certificate error only shows up in the browser while other apps reach the same site fine, the issue is likely scoped to the browser extension or the browser's own proxy settings, not the Clash client.
- Did you just switch nodes or subscriptions?
If a certificate error appears right after importing a new subscription or switching to a new node, consider whether that particular server-side node is hijacking, tampering with certificates, or forcing redirects. This kind of issue usually shows up only on specific nodes — switching to another node and testing the same site will confirm it.
Common scenarios, one by one
Scenario 1: Captive portal hijacking on public networks
Public Wi-Fi at airports, hotels, and campuses often uses a "log in before browsing" captive portal. Until you authenticate, the network layer intercepts every HTTPS request and returns its own login-page certificate, which doesn't match the target site's real certificate at all — the browser flags it as untrusted. In this case, disconnect the proxy first, complete the portal's login flow, confirm you can reach arbitrary sites normally, then re-enable the proxy; the error should disappear. If the login page won't even appear with the proxy on, temporarily turn the proxy off to authenticate, then turn it back on for normal use.
Scenario 2: MITM decryption accidentally left on
As mentioned above, if a client's traffic capture / rewrite feature is enabled but the matching root certificate hasn't been added to the OS or browser trust store, nearly every HTTPS site will error out — the pattern is "everything at once," not one or two specific sites. The fix is to find the capture/rewrite option in the client's settings and turn it off, or install and trust the matching root certificate per the client's instructions. For everyday use where you only need traffic splitting and don't need to inspect request content, leaving this feature off is the simpler choice.
Scenario 3: An incomplete certificate chain
Some self-hosted proxy nodes or services using self-signed certificates are missing intermediate certificates in their setup — the browser can validate the leaf certificate but can't complete the chain up to the root, producing an error like "unknown issuer" or "incomplete certificate chain." This is a server-side configuration issue, unrelated to the local Clash client's settings. The way to check is to visit the same site through a different node for comparison; if only one specific node triggers it, that node's certificate setup is at fault — switch lines or contact the subscription provider.
Scenario 4: DNS poisoning or hijacking pointing you to the wrong server
If domain resolution has been hijacked to point to a spoofed address, the certificate returned by that address naturally won't match the real target site's certificate. To test this, enable the proxy, set the rule to "remote resolution" (where the proxy server performs the DNS lookup instead of the local machine), and revisit the site. If the error disappears, the issue is almost certainly with the local network's DNS environment; if it persists, go back and work through Scenarios 1–3.
Step-by-step fixes by platform
Once you've identified the type of issue, work through the steps for your platform below.
Windows / macOS
- Check the system clock
Open the date and time settings, confirm "Set time automatically" is on, and make sure the time zone matches your actual location.
- Turn off the client's decryption feature
In the Clash or Mihomo client's connection or script settings, find the capture, rewrite, or MITM toggle and confirm it's off, unless you genuinely need to inspect request content.
- Switch nodes for a comparison test
In the same browser tab, switch to another working node and revisit the failing site to see whether the problem is node-specific.
Android / iOS
- Check for conflicts between the system proxy and VPN mode
Mobile clients often take over traffic through a local VPN interface. If another proxy-type app is installed at the same time, the two can interfere with each other and cause connection problems — during troubleshooting, keep only one proxy app running.
- Confirm automatic time sync is on
Mobile OS settings also have a "Set date and time automatically" option; turning it off makes clock drift much more likely.
- Restart the app or re-import the subscription
If switching nodes doesn't help, try restarting the client app, or delete and re-import the subscription link to rule out a corrupted local cache.
Certificate errors in TUN mode deserve a separate look
TUN mode creates a virtual network adapter at the system network layer and takes over global traffic (including apps that bypass application-layer proxy settings). This takeover mechanism itself has nothing to do with re-signing certificates and shouldn't introduce new certificate issues on its own. But because traffic routing changes more thoroughly under TUN mode, apps that the system-proxy rules previously ignored — certain background services or system components' network requests, for example — now get pulled into the proxy path. If these requests happen to hit a routing rule that's misconfigured for that node, they can surface the same certificate-chain or DNS-resolution problems described above. The diagnostic approach is the same: temporarily disable TUN mode, fall back to system-proxy mode, and test the same site to see whether the error is tied to the expanded scope of traffic being taken over.
When the issue is really a routing rule, not the certificate itself
One phenomenon that's easy to misdiagnose as a certificate error: a site gets routed by a rule to a node that isn't a good fit for reaching it, and that server returns an unexpected response (an ISP's block page, for instance). The browser, trying to parse this unexpected response, will also show a "connection not secure" warning — but the root cause is the routing rule, not certificate validation itself. In this case, check which policy group the domain is matched to in your subscription or local config, and confirm whether that node is reachable and its latency test results look normal — that's usually a faster path to the fix than dwelling on certificate details. For the rule syntax and field reference, see the rules section of the full documentation.
| Symptom | Likely cause | What to do |
|---|---|---|
| Nearly every site errors at once | Clock drift / MITM decryption enabled | Sync the system clock, turn off traffic capture |
| Only happens on public Wi-Fi | Captive portal hijacking | Complete portal login before enabling the proxy |
| Only on a specific site or node | Missing certificate chain on that node | Switch nodes and compare |
| Disappears after switching to remote resolution | Local DNS poisoning or hijacking | Enable DNS resolution on the proxy side |
| Disappears after turning off TUN | A rule mismatch within the expanded traffic scope | Check the routing rule matching that domain |
Overall, diagnosing HTTPS certificate errors works best by elimination: turn off the proxy to see if the error disappears, turn off MITM-related features to check for a decryption link, switch nodes to check for a line-specific cause, and switch the DNS resolution mode to check for local network poisoning. Each step rules out one category of cause, and you'll usually land on the answer within four steps rather than guessing item by item.