Why Browsers Show HTTPS Certificate Errors After Enabling a Proxy

A sudden certificate warning right after you turn on a proxy is one of the more alarming errors you'll see while using a Clash or Clash Meta (mihomo) core client. The message is usually something like "Your connection is not private," "certificate invalid," or NET::ERR_CERT_AUTHORITY_INVALID — but the causes behind these messages vary widely. Sometimes it's just a clock that's a few minutes slow; other times the node itself is broken. This article groups the four most common causes by their error signature and gives you concrete steps to follow for each.

How certificate validation relates to your proxy

To understand why a proxy would affect an HTTPS certificate at all, it helps to know how browsers validate certificates in the first place. Every time you visit an HTTPS site, the browser checks three things: whether the certificate chains back to a root certificate the system trusts, whether the domain on the certificate matches the domain you're visiting, and whether the certificate is currently within its validity period. Only when all three checks pass does the address bar show the padlock icon.

In the vast majority of setups, Clash-family clients operate at the transport layer — they simply forward TCP/UDP traffic to a remote node without decrypting or re-signing any HTTPS certificate. What your browser sees is still the target site's original, untouched certificate. That means, under normal conditions, turning on a proxy shouldn't cause any certificate change at all. Once a certificate warning does show up, it almost always traces back to one of four causes: an inaccurate system clock, a decryption feature enabled on the client, page hijacking somewhere along the path, or a genuinely broken node. Let's go through each one.

Clock drift: the most overlooked cause

Certificate validity checks rely on your device's local clock. If system time is significantly off from real time — common on VMs that haven't been online for a while, test machines with a manually altered clock, or aging hardware whose motherboard clock resets after the battery dies — the browser will wrongly conclude the certificate is "not yet valid" or "expired," and the error message typically includes ERR_CERT_DATE_INVALID. The telltale sign here is that every single site throws the same error, regardless of node or whether the proxy is on, while the same site loads fine from a different device.

The fix is simple: open your system's date and time settings and check whether "Set time automatically" is turned on, and verify the time zone is correct.

On Windows, go to Settings → Date & Time and click "Sync now." On macOS, check under System Settings → General → Date & Time. On Linux, you can quickly compare system time against network time with:

If System clock synchronized shows as no in the output, sync isn't actually working — check network connectivity or switch to a different time server.

MITM decryption and rule-hijacking certificate errors

The second category has nothing to do with the clock — it's a feature setting on the client itself. Some Clash Meta (mihomo)-based clients support MITM (man-in-the-middle) decryption for rewriting scripts or filtering ads on specific domains. This requires the client to generate a self-signed root certificate and install it into the system's trust store. If that root certificate isn't properly trusted by the system or browser, visiting any domain covered by the MITM rules will trigger NET::ERR_CERT_AUTHORITY_INVALID, telling you the certificate issuer isn't trusted.

You can identify this case by two signs: only the small set of domains listed under the mitm section in the config throw the error, while most sites load normally; and the certificate details on the warning page show the issuer as the client's own name instead of the site's actual certificate authority.

1. Check whether MITM is enabled

   Look in the client's settings or rules page for an MITM / script / rewrite toggle. If you don't need this feature, simply turning it off is the easiest fix.

2. Reinstall the root certificate

   If you do need to keep the feature, go to the client's certificate export option, re-download the root certificate, and manually trust it per your OS's instructions (on macOS, set the trust level to "Always Trust" in Keychain Access; on Windows, install it into "Trusted Root Certification Authorities").

3. Narrow the MITM scope

   Restrict the mitm rule to only the domains that actually need it, and exclude banking, payment, and other certificate-sensitive sites to reduce risk.

There's a more concerning scenario worth flagging separately: if you haven't enabled any decryption or rewriting feature, yet you get a certificate warning on an unfamiliar page and the content looks nothing like what you expected (for example, a shopping site redirecting to an unrelated promo page), this usually means something along the path is hijacking your traffic — tampering with or redirecting it before it reaches the real server. If this happens, stop any login or payment activity on that node immediately and switch to a different subscription or node source.

Connection and certificate errors caused by a broken node

The fourth cause relates to the health of the node itself. When a proxy node has stopped working, been blocked by the target server, or has a misconfigured server side (common with self-hosted nodes that have an expired, unrenewed certificate or bad TLS settings), the browser might show a connection timeout — or it might show an incomplete-chain certificate error. The exact message varies by browser, but common ones include ERR_CERT_COMMON_NAME_INVALID (certificate domain doesn't match the visited domain) and ERR_SSL_PROTOCOL_ERROR.

The giveaway here is that switching to a different node makes the problem disappear immediately, or the same node produces similar connection errors across every site, not just one domain. To diagnose:

• First switch to another node with normal latency and retry. If the problem goes away, the original node is almost certainly broken — mark it to skip in your subscription group, or wait for the subscription to refresh.
• If the same error shows up no matter which node you use, it's probably not a node issue — go back and check the first two causes (clock, MITM).
• If you run your own server, check the server's certificate status directly from the command line to confirm whether it's expired or mismatched:

If the Verify return code in the output isn't 0, the server-side certificate itself has a problem — you'll need to contact the node provider or reissue the certificate; it's not something a client setting can fix.

Special troubleshooting notes for TUN mode

With TUN mode enabled (a virtual network adapter taking over all system traffic), the general troubleshooting logic is the same as regular proxy mode, but because traffic now passes through a virtual interface in the OS network stack, check two extra things: first, whether the virtual adapter's DNS points to a reliable resolver — DNS poisoning or hijacking can send the browser to the wrong IP, producing a certificate mismatch for the domain you meant to visit; second, whether a firewall or security software is intercepting or redirecting traffic on the virtual adapter. Try temporarily disabling TUN mode and revisiting the same site under regular system-proxy mode. If the warning disappears, you've narrowed the problem down to TUN-related DNS or routing configuration.

Quick self-check list

Putting the four causes together, here's a fast checklist to run through when you see a certificate warning — most of the time you can narrow down the cause within a few minutes:

1. Verify system time and time zone

   Confirm automatic sync is genuinely working and check whether the time is off by more than a few minutes.

2. Check whether MITM or script rewriting is enabled

   Temporarily disable it and retry to see if the error goes away.

3. Check whether the error is limited to specific domains

   Site-wide errors usually point to time or system-level issues; a single-domain error is more likely tied to MITM rules or hijacking.

4. Switch nodes and retest

   Try another node with normal latency to see whether the problem follows the node.

5. Confirm your subscription and node source are trustworthy

   If hijacking is suspected, stop any sensitive activity and switch to a different subscription source.

Most certificate warnings can be traced to a clear cause within these five steps. If it turns out to be a configuration problem, importing a clean subscription config — or resetting the client to its default settings — is usually faster than editing existing rules one by one.