HTTPS Certificate Errors After Enabling a Proxy: Common Causes and Step-by-Step Troubleshooting

HTTPS certificate errors usually occur during the TLS handshake. Before sending the actual web request, the browser checks whether the server certificate was issued by a trusted authority, whether its domain matches the address being visited, whether the current time falls within its validity period, and whether the certificate chain reaches a system-trusted root certificate. If the error appears after enabling Clash or mihomo, that only means the connection path changed; it does not identify a particular node as the cause.

Standard HTTP CONNECT, SOCKS5, or TUN forwarding does not issue certificates for websites. The mihomo core normally only forwards connections, matches rules, and selects an egress route; it does not decrypt TLS content inside web traffic. If the browser suddenly shows a local security product, corporate gateway, or unfamiliar organization as the issuer, check HTTPS scanning, upstream proxies, public-network login pages, and the system certificate store instead of repeatedly changing proxy rules.

Narrow the scope using the error code

Different certificate errors point to different checks. Chrome, Edge, and Chromium-based clients typically show codes beginning with NET::ERR_CERT_; common Firefox codes include SEC_ERROR_UNKNOWN_ISSUER and SSL_ERROR_BAD_CERT_DOMAIN. Expand “Advanced” or “View Certificate” in the browser first, then use the table below.

Four key details to check on the certificate page

1. Issued to: It should include the domain you are visiting. A wildcard certificate such as *.example.com can cover www.example.com, but usually cannot cover the deeper a.b.example.com.
2. Issued by: If a direct connection shows a public certificate authority but the proxy connection shows a local software name or an internal corporate CA, TLS inspection is present somewhere in the path.
3. Validity: When comparing the “Valid from” and “Expires on” times, also confirm the system time zone. Even a correct date with a time-zone offset of several hours can trigger an error just after a certificate renewal.
4. Subject Alternative Name: Modern browsers primarily check SAN rather than relying only on the legacy Common Name. If the current domain is missing from the certificate, a domain mismatch error occurs.

Step 1: Sync the system clock and inspect the certificate environment

Time errors affect the widest range of sites and are usually the quickest to rule out. If every HTTPS site fails, or the computer has just resumed from sleep, had its motherboard battery replaced, or runs dual-boot systems, sync the clock first. In Windows 11, go to “Settings” → “Time & language” → “Date & time”, enable “Set time automatically” and “Set time zone automatically”, then click “Sync now”.

Windows can also use the following command in a terminal to check the time-service status. The Source result should show an available time source, and Last Successful Sync Time should be close to the current time.

w32tm /query /status
powershell -NoProfile -Command "Get-Date"

On macOS, go to “System Settings” → “General” → “Date & Time” and enable automatic time setting. On Linux, use timedatectl status to check System clock synchronized and the time zone. On Android, the usual path is “Settings” → “System” → “Date & time”; some manufacturers place it under “Additional settings”.

Remove outdated local certificate interception

If the device has ever had a packet-capture tool, debugging proxy, corporate endpoint-management app, or HTTPS-scanning component installed, check whether it is still running. Simply closing the browser is often not enough: filter drivers, system services, and local proxy processes may continue to intercept connections. First disable HTTPS scanning or TLS decryption in the software itself, then fully exit it and restart the browser.

• On Windows, press Win + R, enter certmgr.msc, and review the current user’s certificates. Computer-level certificates can be checked through the “Certificates” snap-in in MMC.
• On macOS, open “Keychain Access” and inspect the “System” and “Login” keychains, focusing on recently added entries whose purpose is certificate signing.
• In Firefox, open “Settings” → “Privacy & Security” → “Certificates” → “View Certificates”, then review the “Authorities” list.
• On Android, open “Settings” → “Security” → “Encryption & credentials” to review user-installed credentials. The exact menu name varies by system version.

Step 2: Compare direct, system-proxy, and TUN paths

The most effective way to troubleshoot certificate problems is a controlled comparison. Change only one variable at a time; do not switch nodes, change DNS, edit rules, and reinstall certificates simultaneously. Start with a stable HTTPS site, then test the site that originally failed to distinguish an all-sites failure from a single-site failure.

1. Keep Clash or mihomo running, but disable the system proxy and TUN, then test a direct connection.
2. Enable only the system proxy, using the same node and browser, and test again.
3. Disable the system proxy, enable only TUN, and test once more.
4. Keep the mode unchanged and switch the current node to one on a different route.
5. Only then switch between rule, global, and direct modes to see whether the issue is related to rule matching.

Use curl to test the local mixed port

Clash GUI clients often use 7890 as the local mixed port, but the actual value should come from mixed-port in the configuration or the client’s “Settings” → “Port settings”. The two commands below test a direct connection and a connection through the local HTTP proxy. -I requests headers only, while -v displays the connection and TLS process.

curl -Iv https://www.cloudflare.com/
curl -Iv --proxy http://127.0.0.1:7890 https://www.cloudflare.com/

If the direct connection works but the proxy fails, switch nodes and inspect the mihomo logs. If every node fails but the connection recovers after disabling a local security component, prioritize the local TLS inspection. If only one node fails, the cause may be the node’s egress network, upstream DNS, public-network authentication, or an abnormal route from the server to the target site.

You can also use OpenSSL to inspect the certificate chain sent by the server. Recent OpenSSL versions support connecting through an HTTP proxy:

openssl s_client -proxy 127.0.0.1:7890 -connect www.cloudflare.com:443 -servername www.cloudflare.com -showcerts

-servername sends SNI. Without SNI, a multi-domain server may return its default site certificate, causing a domain mismatch. When comparing direct and proxied results, focus on the certificate subject, issuer, validity period, and verification code—not merely on whether the command ultimately established a TCP connection.

Step 3: Check nodes, DNS, and proxy rules

What switching nodes can tell you

When HTTPS uses a proxy, the client usually establishes an encrypted tunnel to the node first, and the node then connects to the target website. With an HTTP proxy, the browser creates the tunnel using CONNECT example.com:443; with SOCKS5, the domain or destination address is sent in the SOCKS request. In a normal tunnel, TLS is still negotiated between the browser and the target website.

If switching to another node immediately fixes the issue, check whether the failed node’s network resolves the target domain to the wrong address, redirects you to an ISP authentication page, or cannot retrieve the certificate chain currently used by the target site. A node can make the browser accept replacement content without warnings only when it can replace certificates and the device trusts its issuing certificate. Without that trust, a certificate error usually appears immediately.

Why a DNS error can become a certificate domain error

When DNS resolves a domain to the wrong server, the browser still sends the original domain as SNI. If the wrong server has no matching virtual host, it may return another website’s certificate, resulting in NET::ERR_CERT_COMMON_NAME_INVALID. The certificate itself may still be valid, but its covered domain does not match the address bar.

mihomo’s fake-ip mode first returns a mapped address from a reserved pool, then restores the original domain in the core and connects according to the rules. Fake-IP does not generate website certificates. If the problem occurs only with Fake-IP, check whether the domain was incorrectly added to fake-ip-filter, whether the application bypasses TUN, and whether LAN DNS requests actually reach mihomo.

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"

Use fake-ip-filter only for LAN services that genuinely require real addresses, device-discovery domains, or specific compatibility cases. Avoid excluding broad ranges of domains. Excluded domains use real DNS resolution, which also changes their resolution source and rule path.

Check which rule actually matched

In a Clash client that supports a connection list, open the “Connections” or “Logs” page, visit the failing site, and filter by domain. Record the matched rule, policy group, and final node. If the target should go direct but enters the proxy, check earlier DOMAIN, DOMAIN-SUFFIX, GEOSITE, and rule-set entries. If it should use the proxy but goes direct, check LAN rules, private-address rules, and the final MATCH.

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - GEOSITE,private,DIRECT
  - GEOIP,private,DIRECT,no-resolve
  - MATCH,PROXY

Rules are matched in order; once an earlier rule matches, processing does not continue downward. After editing YAML, verify the indentation before reloading the configuration. If the client also uses subscription overrides, scripts, or global extension settings, confirm the final active configuration rather than checking only the original subscription text.

Step 4: Identify MITM, HTTPS scanning, and firewall interception

Here, MITM means that an intermediary terminates the original TLS connection, issues a replacement certificate to the browser, and establishes a second TLS connection to the target website. Corporate inspection gateways, packet-capture tools, parental-control software, and some endpoint-security products may inspect HTTPS traffic this way.

The standard mihomo configuration fields proxies, proxy-groups, rules, tun, and dns do not issue certificates for websites. Therefore, it is normal not to find a “website certificate” switch in a Clash client. If the certificate issuer is a local software product, return to that product’s network-protection or HTTPS-scanning settings.

Disable components one at a time instead of uninstalling everything

1. Disable proxy switching, packet capture, or debugging features in browser extensions, then fully quit and reopen the browser.
2. Pause the local packet-capture program’s system proxy and HTTPS decryption, leaving only Clash’s system proxy enabled.
3. Temporarily disable “HTTPS scanning”, “encrypted-connection inspection”, or similar features in security software, perform one comparison test, then turn the feature back on.
4. Disconnect the corporate VPN, zero-trust client, or remote-work gateway, then compare the result on a home network and a mobile hotspot.
5. If a public Wi-Fi network has not been authenticated, disable the proxy and open the login page provided by the network. Complete authentication before enabling the proxy again.

Some public networks redirect the first HTTP request to an authentication page. HTTPS cannot accept this redirect directly because the gateway returns a certificate for the gateway rather than the original website, so the browser reports a domain mismatch. Immediate recovery after switching to a phone hotspot is a strong signal of this problem.

Step 5: Handle errors limited to a browser or application

Chrome and Edge work, but Firefox reports an error

Chrome and Edge generally follow the operating system’s certificate environment, while Firefox may handle certificates differently. In Firefox, open “Settings” → “Privacy & Security” → “Certificates” → “View Certificates” and confirm that the required authority is present. On managed devices, administrators should deploy certificate policies centrally; do not download a certificate temporarily from a webpage prompt.

The browser works, but a desktop or mobile application fails

Some applications use their own certificate store, and some also perform certificate pinning, accepting only certificates or public-key relationships specified in advance by the developer. The browser may open the site normally while the application rejects the connection. The usual solution is to bypass TLS-decryption components for that application’s traffic rather than importing more certificates into the system.

If the problem occurs only in TUN mode, check whether application traffic also passes through another VPN, security filter, or private DNS service. Android and iOS generally allow only one primary VPN tunnel at a time, but local DNS, content-filtering profiles, and device-management policies can still change the path. Disable other network extensions and start the Clash client alone to reduce variables.

Private browsing works, but the regular window fails

This usually points to a browser extension, cached HSTS state, separate proxy extension, or differences in user settings. Disable network-related extensions on the extensions page, then clear the target site’s cookies and site data. Do not use an “ignore certificate errors” launch flag as a long-term solution; it weakens certificate validation for the entire browser session.

A reusable ten-minute troubleshooting sequence

1. Minute 1: Write down the error code and inspect the certificate’s domain, issuer, and validity period.
2. Minute 2: Sync the system clock and confirm the date, time zone, and time-service status.
3. Minute 3: Disable the system proxy and TUN, then perform a direct-connection comparison.
4. Minute 4: Enable only the system proxy and test the same site in the same browser.
5. Minute 5: Switch to a node on a different route without changing anything else.
6. Minute 6: Check the connection logs to confirm the domain’s matched rule, policy group, and egress.
7. Minute 7: Use curl -Iv to compare the direct result with the 127.0.0.1:7890 proxy result.
8. Minute 8: Pause HTTPS scanning, packet capture, and corporate network components, testing each one separately.
9. Minute 9: Switch to a phone hotspot to rule out public-network authentication and the current router path.
10. Minute 10: Gather the reproduction details: client version, mihomo core version, operating system version, node, mode, and error code.

Base the final diagnosis on comparison results: if every network and device reports an error for the same website, suspect the site’s certificate deployment; if only one device fails, check the clock, certificate stores, and security software first; if only the proxy path fails, investigate the node, DNS, rules, and upstream network; if only one application fails, focus on its separate certificate store, certificate pinning, and traffic interception scope.

After troubleshooting, restore each temporarily disabled security feature and test the browser and commonly used applications again. Return the Clash or mihomo configuration to its normal daily-use mode; do not leave global proxying, overly broad Fake-IP exclusions, or test-only rules enabled indefinitely.