HTTPS Certificate Errors When Using a Proxy: Causes and Fixes

Note the error code first—never bypass certificate verification

If “Your connection is not private” appears after you enable Clash, it means the browser could not verify the server’s identity along the current connection path. It does not, by itself, mean the proxy node has failed. HTTPS verification depends on the hostname, certificate validity dates, certificate chain, and the device’s trust store. Changing the route with a proxy can expose a problem with any of these.

Record the full hostname in the address bar, the browser’s error code, your system time, and the certificate viewer’s Issuer, validity period, and Subject Alternative Name (SAN). The hostname is usually enough to identify the issue. If you share a screenshot, hide login tokens, email addresses, and other personal information in the URL.

Do not disable certificate checks, install an unverified root certificate, or treat “Proceed” as a fix. If you see a certificate warning on a banking, payment, email, or account sign-in page, stop and don’t enter your password. Verify the connection on a trusted network first.

How Clash, mihomo, and HTTPS certificates interact

A standard Clash or mihomo configuration forwards connections. When a browser connects to a website through an HTTP proxy’s CONNECT tunnel, SOCKS5, or TUN routing, the website’s HTTPS TLS handshake usually still takes place between the browser and the website. Enabling the system proxy does not, on its own, require installing a root certificate to decrypt web traffic.

Keep the two TLS connections distinct: tls, servername, and skip-cert-verify in a node configuration may control the connection from the core to the proxy node. A browser certificate warning usually concerns the connection from the browser to the website. Changing a node’s skip-cert-verify will not fix a website certificate and can make node identity checks less reliable.

Different symptoms call for different checks

• Browser shows a certificate warning: Check the website certificate’s hostname, issuer, and validity period.
• Client log shows x509 and the browser reports a proxy connection failure: Check the node hostname and certificate, along with the core runtime’s clock and trust store.
• Problem starts only after enabling TUN: Check the rules, DNS route, and other VPNs used by the connection. TUN itself does not issue new certificates for websites.

Secure DNS in the browser, proxy extensions, the system proxy, and TUN can all be active at once. For diagnosis, use one connection method at a time. Otherwise, turning off the system proxy may not help if TUN still captures the traffic, leading you to wrongly conclude that direct connections are affected too.

System clock errors and certificate validity

Certificates have a start date and an expiration date. Verification fails if the device’s clock is before the start date or after the expiration date. Switching between operating systems, restoring a virtual machine snapshot, a failing motherboard battery, or a time-sync service issue can make multiple otherwise healthy websites show errors at once.

Check the actual time first, then the time zone

• Windows 11: Go to Settings → Time & language → Date & time. Check that Set time automatically is enabled, then select Sync now. On managed devices, an organization policy may control the time source.
• macOS: Go to System Settings → General → Date & Time. Check automatic date and time settings, as well as the time zone.
• Ubuntu: Run the following command to check the current time, time zone, and synchronization status.

date -Is
timedatectl status

Pay particular attention to System clock synchronized. On a systemd-managed host that isn’t controlled by another time service or organization policy, you can enable network time synchronization with the command below, then check the status again:

sudo timedatectl set-ntp true
timedatectl status

A different time zone does not mean the system’s actual time is wrong. There’s no need to change your time zone to match a website’s location. If the time is correct and only one hostname has an expired certificate, the website operator will usually need to renew it. Changing your device’s date only hides the problem and can affect other sites.

HTTPS inspection tools and the system trust store

When Fiddler, Charles, mitmproxy, or similar tools enable HTTPS decryption, they dynamically issue certificates for the websites you visit. Some security software and corporate gateways can perform similar inspection. As a result, the certificate issuer shown in your browser may be the tool or organization, rather than the public certificate authority used by the website.

Investigate the issuer before installing any certificate

1. Check the issuer and certificate chain in the certificate details provided by the error page. The exact steps vary by browser version.
2. Check whether a traffic inspection tool is running, HTTPS decryption is enabled, or the system proxy still points to that tool.
3. When you finish personal testing, turn off the tool’s HTTPS decryption and restore proxy settings as instructed by its documentation. Remove only test root certificates you have confirmed belong to that tool and no longer need.
4. If the issuer belongs to your company or school, ask an administrator about device management and certificate deployment. Don’t remove organizational certificates or bypass policy on your own.

Don’t assume every application uses the same certificate trust settings. Firefox, system browsers, the curl command-line tool, and programs in containers may use different certificate stores, versions, and organization policies. If a site works in a browser but not with curl, compare their trust sources instead of repeatedly switching proxy nodes.

If Ubuntu’s public CA bundle is simply out of date, update ca-certificates from a trusted software repository. This updates the system trust store; it won’t fix a hostname mismatch or make an unknown private certificate trustworthy:

sudo apt update
sudo apt install --only-upgrade ca-certificates
sudo update-ca-certificates

Compare direct connections, a fixed node, and certificate details

Use the same device and URL at roughly the same time, changing only one variable per test. First disable traffic inspection tools and other VPNs temporarily, then check whether TUN, the system proxy, and browser extensions are actually active. In rule mode, the destination may match DIRECT, so an enabled client doesn’t guarantee that the request goes through a proxy node.

Compare requests through the local mixed-port

This example assumes the local mixed-port is 7890 and uses the public example domain example.com. To test the affected site, replace it with a URL that contains no tokens, and use the port shown in your client. On Windows, call curl.exe explicitly to avoid a same-named alias in some PowerShell environments.

# Do not use curl's explicit proxy; TUN may still capture this connection
curl -Iv --noproxy '*' https://example.com/

# Use the HTTP proxy on the mixed-port
curl -Iv --noproxy "" --proxy http://127.0.0.1:7890 https://example.com/

--noproxy '*' bypasses curl’s proxy settings only; it does not bypass TUN, a transparent gateway, or system routing. For a true direct-connection baseline, also disable any relevant traffic interception where permitted. These commands do not disable certificate verification. Output may include request details, so redact it before sharing.

• Only one node has the issue: Keep other conditions the same, switch nodes, and compare the certificate SAN, issuer, and error code. Also check the client’s connection log to confirm the matched rule and actual egress route.
• Only one website fails through every egress route: Suspect the site’s certificate, certificate chain, or CDN edge configuration before blaming the local proxy port.
• Multiple websites fail on one device: Check the system time, trust store, traffic inspection tools, and managed network.
• Multiple devices fail on the same network: Check captive portal sign-in, router DNS, the gateway, and the network operator. If needed, compare results on a trusted network.

Different egress routes showing different certificates does not automatically mean traffic is being intercepted. CDNs may use different valid certificates and intermediate chains by region. Check whether the hostname matches, the chain is trusted, the dates are valid, and any unexpected issuer has a plausible explanation.

Distinguishing DNS issues, node problems, and captive portals

DNS tampering or incorrect resolution can point a hostname to an unrelated server, causing a certificate hostname mismatch. It cannot give that server a valid certificate for the requested hostname. Merely changing DNS resolution generally cannot silently decrypt an HTTPS connection whose certificate verifies correctly. The browser warning is an important security boundary—keep it in place.

A fake IP does not mean DNS resolution is wrong

In mihomo’s fake-IP mode, applications receive synthetic IPs used for mapping. A common configuration uses 198.18.0.0/16, but the actual range is set by fake-ip-range. A result in this range alone is not evidence of DNS tampering. Check whether the core retains the hostname mapping and which rule and egress route the connection ultimately uses.

• First check dns.enhanced-mode, nameserver, any configured nameserver-policy, and TUN’s dns-hijack.
• Check whether secure DNS is enabled in the browser. A browser-selected resolver may use a different DNS route than you expect.
• Don’t compare only whether two resolvers return the same IP. CDNs, location, and load balancing can produce normal differences.
• After changing DNS settings, reload the configuration and create a fresh test connection. Existing connections, DNS caches, and fake-IP mappings can temporarily produce mixed results.

If the issue follows a particular egress route and the certificate hostname doesn’t match or the issuer can’t be explained, stop using that route and keep a redacted record. This links the issue to that path, but does not by itself prove that the node is deliberately intercepting traffic; the egress network’s DNS or intermediary devices could also be at fault.

Networks at hotels, airports, and other venues may require captive portal sign-in. An HTTPS request redirected to the login gateway can trigger a certificate error. Use the system’s sign-in prompt to connect to the network. Don’t enter account details on the original site while its certificate warning is active, and don’t install an unknown root certificate for the portal.

Verify the fix and avoid common pitfalls

Why is there no “Proceed” option on an HSTS site?

HSTS (HTTP Strict Transport Security) tells the browser to enforce HTTPS for a site. Not offering a way to bypass a certificate error may be expected behavior. Clearing HSTS state does not fix the certificate; address the system time, certificate chain, hostname, or network path instead.

Will switching to Global mode or enabling TUN fix it?

These settings can change the egress route or the traffic they capture, so they can help with controlled comparisons—but they cannot fix an expired certificate or an unknown issuer. Global mode changes routing; TUN captures traffic at the network layer. Neither should change how the browser verifies a website’s identity. If a test makes the warning disappear, find out why the original rule or route caused the issue.

After troubleshooting: checklist

1. Restore the required rule mode and proxy method, remove temporary test settings, and leave certificate verification enabled.
2. Close old tabs and revisit the site. Confirm the hostname is correct, the certificate is valid, and the error is gone.
3. Check the client’s connection log to confirm the actual rule and route. Don’t judge the result from a cached page or a request that didn’t use the expected egress.
4. If you need to report the issue, include the operating system, browser version, client and core versions, error code, time of occurrence, and redacted certificate details. Don’t share subscription URLs, node passwords, or your full configuration.

Use a consistent troubleshooting order: error code → system time → certificate details → local HTTPS inspection → direct and fixed-egress comparisons → DNS and network path. Preserve verification safeguards and narrow down the cause one step at a time instead of changing several settings at once.