Why HTTPS Certificate Errors Appear After Enabling Clash (And How to Fix Them)
How browser certificate warnings relate to proxies: which errors come from node hijacking, clock drift, or local security software, and how to fix each.
Certificate warnings don't come from the proxy client itself
When a browser first shows "Your connection is not private" or "Invalid certificate," many people's instinct is to shut down the proxy client. That's an understandable response, but it's usually pointing at the wrong layer. HTTPS certificate validation happens between the browser and the target website: it checks whether the certificate chain was issued by a trusted certificate authority (CA), whether the domain matches, and whether the current time falls within the validity window. Clash and the Clash Meta (mihomo) core operate as a proxy layer that decides which node and route a request takes — they don't and can't alter the certificate exchanged during the TLS handshake, unless something in the middle is actively tampering with the traffic.
In other words, a certificate error essentially means "the browser doesn't trust this certificate," and the broken trust chain usually comes from one of three scenarios: a man-in-the-middle behavior at the proxy node or exit network itself, a mismatch between local system time and the network environment that throws off validity checks, or security software/network policies on the local machine that inject their own self-signed root certificate for traffic inspection. Understanding the difference between these three cases is the first step in figuring out which layer the problem is in — and who should actually fix it.
Three common scenarios and how to tell them apart
Classifying the issue first is far more efficient than blindly reinstalling the client or hopping between nodes.
This is the case that deserves the most caution. If the browser warns that the certificate "was issued by an untrusted authority" or "doesn't match the domain," and inspecting the certificate details shows an unfamiliar issuer that isn't the CA the site normally uses (banks and major platforms typically stick to a handful of well-known CAs), it suggests traffic may have been intercepted before reaching the target site and re-signed with a forged certificate — a textbook TLS man-in-the-middle attack. This can happen at the network operator level where the exit server is hosted, or because the node itself is configured to actively inspect traffic.
How to check: try the same website again after switching to a different node or subscription source. If the certificate is fine on a different node, the problem was with the original node or its exit route, not the client or your local settings. In that case, stop using that node — especially for anything involving logins or payments.
Every certificate has a defined validity window, and the browser checks whether the local system time falls inside it. If the computer's clock has drifted noticeably — from long periods offline, virtual machine clock drift, or a manually changed date (even a few hours off can trigger a warning if the certificate is close to its issue or expiry boundary) — you'll see "certificate not yet valid" or "certificate expired" errors that have nothing to do with the proxy at all. Switching nodes won't fix this.
How to check: verify whether the system time syncs automatically and whether the time zone is correct. On Windows, go to Settings → Time & language → Date & time, turn on automatic time setting, and click "Sync now" manually. If the error disappears once the clock is corrected, the issue was the local clock all along — no need to suspect the client or subscription.
Some antivirus tools, parental control software, and corporate network policies install their own root certificate into the system or browser's certificate store to inspect HTTPS content. This is technically a "legitimate" man-in-the-middle operation, just one happening on the local machine rather than a remote node. If the certificate details show an issuer name belonging to a security software vendor, or an internal corporate CA, the error has nothing to do with the proxy node or the Clash client — it's caused by that software's certificate injection mechanism.
How to check: temporarily quit the relevant security software or disconnect from the corporate network, then retry the same website. If the error goes away, the problem is on the local software layer — you can disable "HTTPS traffic scanning" in that software's settings, or choose to trust its certificate (only after evaluating how trustworthy that software is).
How certificate behavior differs under TUN mode
Once TUN mode takes over global traffic, the troubleshooting approach needs a slight adjustment.
TUN mode, supported by the Clash Meta (mihomo core), creates a virtual network adapter at the system network layer and routes nearly all outbound traffic through the proxy — not just the browser or apps with proxy settings configured manually. This means that if a node is engaging in man-in-the-middle behavior, the impact spreads from "websites visited in the browser" to "every TLS connection going out through that virtual adapter," including system updates and API requests from various client apps. These cases don't always surface an obvious certificate warning the way browsers do — many programs simply fail to connect or retry silently instead.
If certain apps start showing connection errors, handshake failures, or mysteriously invalidated login sessions after enabling TUN mode — while those same apps work fine under system proxy mode (HTTP/SOCKS only) — try turning TUN mode off temporarily and testing again under system proxy mode. This step helps confirm whether the issue is tied to the scope of traffic the virtual adapter takes over, rather than a certificate problem with the node itself. For everyday use, it's best to enable TUN mode only when truly needed — for instance, with client software that doesn't support system proxy settings — to keep the troubleshooting surface smaller.
A practical step-by-step troubleshooting order
When a certificate error shows up, work through the steps below one at a time rather than changing several settings at once.
- Check the issuer name and validity period in the certificate details first, to decide whether it's an "unfamiliar CA" or an "abnormal validity window" — this quickly splits the problem into a node issue or a time issue.
- If you suspect a node issue, retry the same site on a different route; if it works fine on another node, stop using the original one and there's no need to dig further into client settings.
- Check whether the system time syncs automatically — especially on computers or virtual machines that have been offline for a while — and retry after manually syncing the time.
- Check whether you have security software with HTTPS scanning installed; temporarily disable that feature and retry to see if local certificate injection is the cause.
- If TUN mode is enabled, switch back to system proxy mode temporarily to narrow down where the problem occurs.
- If none of the above resolves it, consider the browser's own certificate cache — clear the browser's HSTS cache and certificate cache, then try again.
Core: mihomo
Applies to: TUN mode and system proxy mode
Which warnings are safe to ignore, and which aren't
Not every certificate prompt means real risk, but it's not worth pushing through one on anything sensitive.
If you're on a login page, a payment page, or any site asking for an account password, and you see a warning about an unfamiliar issuer or a domain mismatch, stop what you're doing. Switch to a different node or test with the proxy disabled entirely, and confirm the site's certificate is normal before continuing — this avoids sending account details through a hijacked intermediate node.
If you're just browsing an ordinary informational site and the certificate warning disappeared after switching nodes or syncing the system clock, the problem has already been found and resolved — no need to worry further. This kind of occasional man-in-the-middle interception is usually tied to the network environment of a particular exit route, and switching nodes restores normal access.
Common questions
Why does only one website show a certificate error while everything else is fine?
This more often points to a certificate configuration issue on that specific website — such as a certificate nearing expiry, an incomplete certificate chain, or a misconfigured CDN node — and has little to do with the proxy software. Try connecting directly to the same site (with the proxy temporarily off); if the error still shows up, the problem is entirely on the website's side and unrelated to Clash.
The certificate error is still there after clearing the browser cache — what else can I check?
Try the same website in a different browser. If the new browser shows the same error, the issue isn't in the browser cache layer — it's more likely at the node or the system certificate store, so go back through the scenario-by-scenario checks above.
The certificate issue goes away after turning off TUN mode — does that mean TUN mode itself is flawed?
It's not a flaw — it's a difference in how much traffic each mode takes over. TUN mode covers more connection types, so if a node route has a problem, more connections are affected and it becomes more noticeable. The root cause is still the node, not the TUN mode feature itself.
Get the Clash client
Picking a stable node route and pairing it with the right local settings is what actually cuts down on unnecessary certificate warnings and connection glitches.