HTTPS Certificate Errors When Using a Proxy: Common Causes and How to Troubleshoot

1. First, identify the error: website certificate or node TLS handshake

The word “certificate” can appear in errors from different parts of the connection, and each points to a different issue. Your browser checks the destination website’s certificate. The core may also check a proxy server’s certificate when you use a TLS-based proxy protocol. Don’t treat these as the same error.

A TLS error in the logs may come from a subscription download, a speed-test URL, or an encrypted DNS service—not a proxy node. Record the full destination hostname, time, and action; don’t copy just the x509 line. If the browser shows ERR_PROXY_CONNECTION_FAILED, check the local listening port and whether the client is running before changing anything about certificates.

2. Check the system clock and certificate validity first

An incorrect clock can make many otherwise valid websites fail at once. Check it first if the computer has been off for a long time, a VM has resumed from a snapshot, or the motherboard battery may be failing. The time shown in the taskbar isn’t enough—check the year, date, and time zone too.

1. Windows 11: Go to Settings → Time & language → Date & time. Turn on Set time automatically, check the time zone, then select Sync now.
2. macOS: Go to System Settings → General → Date & Time. Check Set time and date automatically and the automatic time zone option.
3. Android: On stock Android, go to Settings → System → Date & time. Other manufacturers may put these options under Additional settings. Check automatic date and time and automatic time zone.
4. In the browser’s error page, open Advanced or the certificate viewer and check the validity period. The exact labels vary by browser version; note the “valid from” and “expires on” dates.

If only one website reports an expired certificate while your clock is correct and other sites work, the site owner likely needs to renew it. Switching nodes won’t make an expired certificate valid again. If many websites start failing at the same time, check the system clock or software that intercepts traffic before repeatedly updating your subscription.

3. Compare direct and proxied connections under the same conditions

Test the same full HTTPS URL, changing only one condition at a time. Don’t switch nodes, change DNS, and enable TUN all at once, or you won’t know which change made a difference. First note the current rule mode, selected node, system proxy status, and TUN status.

Compare these four setups

1. Turn off the Clash client’s system proxy and TUN. Make sure no other VPN or browser proxy extension is handling traffic, then visit the site.
2. Turn on only the system proxy, leaving TUN off, and retry with the same node. On the client’s Connections page, check whether the destination domain is routed through a node or DIRECT.
3. Leave everything else unchanged, switch to another known-working node, and visit the same URL.
4. Try again over a mobile hotspot with the same client settings. This helps distinguish a local network issue from a device-specific one.

If the site isn’t reachable directly, a failed direct connection doesn’t tell you anything about its certificate. Don’t confuse a timeout with a certificate error. Incognito mode isn’t a clean certificate environment: it may still use system root certificates and won’t rule out enterprise security software.

Inspect the TLS handshake from the command line

The following examples are for Windows PowerShell. 7890 is only a sample port—replace it with the client’s current HTTP or mixed port. Don’t use a SOCKS-only port. The second test requires the client to be listening on that port; make sure the NO_PROXY environment variable isn’t bypassing the proxy for the test domain.

curl.exe -I -v --noproxy "*" https://example.com/
curl.exe -I -v --proxy http://127.0.0.1:7890 https://example.com/

Neither command skips certificate validation. The first bypasses the application-level proxy only; if TUN is still running, it may continue to handle traffic, so turn TUN off before comparing direct connections. Different curl builds use different trust stores. Compare the results with the browser’s certificate details; one successful command doesn’t rule out a browser trust-store issue.

4. Check Fake-IP and DNS: is the domain resolving to the wrong server?

Fake-IP doesn’t replace a website’s certificate. In mihomo’s Fake-IP mode, DNS returns a synthetic address and the core keeps a domain-to-address mapping for routing connections. If your configuration uses 198.18.0.1/16, an address in that range may be expected. It isn’t the server’s real public IP, and it doesn’t by itself indicate DNS poisoning.

DNS tampering, routing to the wrong service, or stale connection and mapping state can cause the browser to receive a certificate that doesn’t belong to the domain. On the other hand, many incorrect mappings cause only timeouts, not certificate warnings. Compare the certificate name with the actual connection records before drawing conclusions.

Check the evidence before changing DNS settings

• In Windows PowerShell, run Resolve-DnsName example.com and inspect the returned addresses. Replace the example domain with the one showing the error.
• Open the client’s Connections or logs view and check the domain, matched rule, and outbound node. A system DNS lookup doesn’t necessarily show which DNS server the browser used.
• In Chrome, check Use secure DNS under Settings → Privacy and security → Security. Change it temporarily for comparison only, and note the original setting. DoH traffic may still pass through TUN.
• If you’ve just changed DNS modes, close the affected pages and browser connections, and restart the client if needed. On Windows, run ipconfig /flushdns to clear the system DNS cache. This won’t automatically clear every browser cache or core mapping.

The following is a mihomo DNS configuration snippet to help identify the fields, not a complete fix for certificate errors. Configure upstream DNS, routing, and client overrides for your existing setup.

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16

If a specific app is incompatible with Fake-IP, investigate the cause before considering fake-ip-filter; don’t exclude every domain. For subscription-managed configurations, use the override mechanism supported by your client to avoid losing changes on the next update. See Advanced Configuration for more options.

5. HTTPS interception certificates, enterprise inspection, and public Wi-Fi

If several unrelated websites show the same local organization or security product as the issuer, check for HTTPS inspection. Debugging tools such as Fiddler, Charles, and mitmproxy can decrypt HTTPS after their root certificate is installed and trusted. Some enterprise gateways and endpoint security products work similarly. This is different from ordinary HTTPS forwarding by the Clash client.

How to check where a certificate came from

1. On the error page or in the certificate viewer, note the Subject Alternative Names (SAN), issuer, validity period, and certificate chain. The SAN should cover the domain in the address bar.
2. Quit any traffic-inspection tool and check whether the system proxy still points to its listening port. Closing the tool’s window doesn’t necessarily restore the system proxy settings.
3. On Windows, use certmgr.msc to view certificates for the current user. Viewing local computer certificates with certlm.msc usually requires the appropriate permissions. On macOS, view certificates and trust settings in Keychain Access.
4. On a personal device, remove only debugging certificates whose source you’ve confirmed. If the device is managed by your employer, contact the administrator instead of deleting enterprise root certificates in bulk.

Browsers and command-line tools may use different certificate trust stores, so the browser may work while curl fails, or vice versa. Before installing a root certificate, confirm that HTTPS inspection is part of your device’s management policy and that the certificate is from a trusted source.

6. If only one node triggers the error, check SNI and the certificate chain

If the error appears only on a particular node—with the same device, website, and DNS settings—stop using that node for now. Then distinguish between two cases: the client can’t connect to the node, or the node connects but the browser receives an unexpected website certificate.

The client log reports a node TLS error

For TLS-based nodes, the connection address may differ from the name used to verify the certificate. Fields also vary by protocol in mihomo: servername is common for VMess and VLESS, while Trojan commonly uses sni. Check the documentation for the specific protocol and the parameters provided by your service provider; don’t assume one field name applies to every node.

• If the connection address is an IP, the certificate may not include that IP in its SAN. Ask the service provider for the correct server name and connection parameters.
• If the logs show an expired certificate or an incomplete chain, the node operator needs to renew the certificate or provide the missing intermediate certificates. Changing client rules can’t repair a server certificate.
• skip-cert-verify affects certificate validation only for the corresponding node connection. It won’t fix the browser’s validation of the destination website. Don’t set it to true to hide the error.

The browser receives an unexpected website certificate

An ordinary forwarding node doesn’t have the destination website’s private key and can’t create a website certificate trusted by your browser. An unexpected certificate may point to incorrect DNS, network authentication or interception, a remote configuration issue, or malicious interference. One error alone doesn’t prove hijacking, but it’s enough reason to pause sensitive activity on that route.

Save the certificate details for that node, then compare using another trusted network or node. Different CDN edges may legitimately serve different certificates or issuers. A different issuer alone doesn’t prove hijacking; check domain coverage, validity dates, chain of trust, and whether repeated tests show the same result.

7. Wrap up: fix the issue, retest, and record details for support

After making one fix, revisit the exact URL that first showed the error, then test a second unrelated site. Getting the page to load is only the first step: make sure the rule mode, system proxy, and TUN are back to their intended settings, with no test-only global routing or temporary DNS changes left behind.

Include this information when asking for help

• Operating system version, Clash client name and version, and mihomo core version. Don’t just say “latest.”
• The full error code, when it occurred, and whether it came from the browser or the client logs.
• The destination domain, certificate SAN, issuer, and validity period. Remove personal information from URL query parameters.
• System proxy and TUN status, actual listening port, rule mode, and comparison results for direct, node A, and node B.
• A small amount of relevant log output, with subscription URLs, access tokens, node passwords, and external controller keys removed first.

Use this troubleshooting order: where the error occurs → system clock → connection path comparison → DNS and certificate source → node settings. Each step gives you evidence, so there’s no need to reinstall the client or make sweeping YAML changes right away. For basic importing and proxy setup, see the user guide. For common connection issues, visit the Help Center.