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

Identify the Error First: Certificate Validation Failure vs. Connection Failure

Seeing “Your connection is not private” after enabling Clash does not mean the client is modifying website certificates. Standard HTTP CONNECT, SOCKS, and TUN forwarding do not issue certificates for destination websites; your browser still validates the site's certificate chain, validity period, and hostname. A proxy changes the connection route, and DNS, an exit node, an authentication gateway, or traffic inspection along that route may cause the browser to receive a different certificate.

Note the full hostname in the address bar and the error code, then open the certificate details from the warning page. The steps vary by browser; focus on the certificate’s issuer, validity period, and Subject Alternative Names (SANs). Don’t rely on the certificate’s display name alone: SANs are the primary way to verify whether the hostname matches.

System Time and Trust Store: Check Local Validation First

Check the date, time, and time zone

Certificates have defined start and expiration dates. After a computer wakes from sleep, a motherboard battery failure, or a manual clock change, the system time may be wrong. If several unrelated sites show date errors, check the device first instead of repeatedly switching nodes.

1. In Windows 11, go to Settings → Time & language → Date & time. Check “Set time automatically” and the time zone, then select “Sync now.”
2. On macOS, go to System Settings → General → Date & Time and check that automatic date and time are enabled. Managed devices may require administrator privileges.
3. Reopen the browser and visit the original hostname. If only one site still reports an error, check whether its certificate has actually expired.

On Windows, use the commands below to check the current time and Windows Time service status. If the second command reports that the service is not running, its time-sync status cannot be confirmed; that does not mean HTTPS itself is broken.

Get-Date
w32tm /query /status

Distinguish a missing certificate chain from an outdated trust store

Older operating systems, browsers that haven’t been updated in a long time, and websites that omit intermediate certificates can all cause trust-chain errors. Install regular system and browser updates, then compare with another browser on the same device. Browsers may use different root-certificate mechanisms, so “it works in another browser” is a clue, not proof that the server certificate is correct.

If the same site fails on multiple devices and networks while other sites work, the website administrator may need to fix the certificate deployment. Don’t download a certificate from search results or an error page and add an unknown certificate to “Trusted Root Certification Authorities.”

HTTPS Interception: Check the Certificate Issuer

When tools such as Fiddler, Charles, or mitmproxy enable HTTPS decryption, they use a locally trusted root certificate to issue certificates for websites on the fly. Corporate security gateways and some security software’s “HTTPS scanning” features may work similarly. A certificate warning can appear if the tool’s root certificate is not installed correctly, has expired, or is not trusted by the browser.

Cross-check proxy settings and traffic inspection processes

• Check whether any traffic inspection tools are still running, whether HTTPS decryption is enabled, and whether a system proxy is configured.
• In Windows, go to Settings → Network & Internet → Proxy. Note the address and port under “Use a proxy server,” then compare them with the current listening address in the Clash client.
• Check whether the certificate issuer has changed to the name of a traffic inspection tool or organization. An unfamiliar name warrants further investigation, but the name alone does not prove an attack.
• Quit personal traffic inspection tools, re-enable the system proxy in the client, and test again. On a managed corporate device, contact your administrator rather than removing organization certificates or security policies yourself.

127.0.0.1:7890 is a common example of a local proxy address, not a fixed port used by every client. If a traffic inspection tool and Clash both change the system proxy settings, the last one to write them may overwrite the other. If another process is using the port, you may also connect to a different local service than intended.

Standard Clash/mihomo forwarding does not require installing a root certificate in your browser. If a supposed “proxy fix” guide asks you to install an unknown root certificate, stop and investigate first. A root certificate grants trust; it is not a performance setting.

Fake-IP and DNS Cache: Check That the Core Still Handles the Mapping

In Fake-IP mode, mihomo returns mapped addresses for domain names. A commonly used address range is 198.18.0.1/16. The core uses the mapping to recover the hostname before applying rules and connecting. This address is not the website’s public IP, and you should not turn it into an HTTPS URL for testing.

Fake-IP does not issue certificates or change the browser’s trust store. A more common problem is that the browser or system still has an old Fake-IP address cached after TUN, DNS interception, or the client has stopped, so the connection no longer reaches the core that manages the mapping. This usually causes a connection failure. A hostname mismatch or other certificate error is possible only if the traffic reaches the wrong TLS service.

Restore DNS and connection state in order

1. Record the current “System Proxy” and “TUN Mode” states, along with dns.enhanced-mode, fake-ip-range, and fake-ip-filter in the active configuration. Don’t change everything at once.
2. Close the page showing the error, confirm the client core is running, and reload the active configuration. If the client provides an option to clear DNS or Fake-IP caches, use it only after checking what it does.
3. On Windows, run ipconfig /flushdns in Command Prompt, then fully quit and reopen the browser. Clearing the system cache does not automatically clear every browser or router cache.
4. Visit the original hostname again and check the client’s “Connections” or “Logs” view for that domain, the matched rule, and the proxy chain.

A browser’s Secure DNS feature may change the DNS resolution path. In Chrome, go to Settings → Privacy and security → Security → “Use secure DNS.” Options vary by version and organization policy. For troubleshooting, note the current setting, turn it off temporarily, and test again; restore it afterward. Disabling Secure DNS is not a universal fix for certificate errors.

Proxy Nodes, Exit Routes, and Authentication Gateways: Isolate the Cause One Variable at a Time

If the device time is correct and no HTTPS decryption tools are running, compare connection routes next. A faulty node, DNS problems at the exit, a public Wi-Fi login gateway, or a misrouted rule can send the connection to the wrong server. A proxy node generally cannot forge a certificate for the destination website that the browser accepts. A certificate warning is a safety boundary—don’t bypass it just to load the page.

Change one variable at a time

1. Use the same device, browser, and URL, and record the current mode, matched rule, and selected node. If the policy group uses automatic selection, check whether it switched nodes during testing.
2. Switch to another trusted node without changing anything else, then check whether the error code or issuer changes.
3. If permitted by your network’s usage policy, test a direct connection. If TUN is still enabled, turning off “System Proxy” alone does not mean traffic is going direct. Disable the relevant traffic interception explicitly, or confirm that the test connection matches DIRECT.
4. If possible, switch to a mobile hotspot. If the problem occurs only on one Wi-Fi network, check whether you need to complete a captive portal login. Use the operating system’s network sign-in prompt; don’t enter credentials on a certificate warning page.

If only one node is affected, stop using it for sensitive activity and report the hostname, time, error code, and certificate issuer to your service provider. A single hostname mismatch does not prove “node hijacking,” but if several unrelated sites suddenly present the same unfamiliar certificate, stop using that route immediately and investigate.

Rules determine the actual route; the mode name is not proof

In Rule mode, check the logs to see whether DOMAIN-SUFFIX, GEOIP, or the final MATCH rule matched, and confirm the resulting policy. A proxy group named “Auto Select” or “Proxy” does not guarantee the expected exit route; it may have selected DIRECT. TUN captures traffic but does not fix invalid certificates. Switching to Global mode is no substitute for checking the rules.

Retest from the Command Line: Confirm the Port and Keep Validation Enabled

Use the Windows built-in curl.exe below to compare results for a public example domain. The example assumes the client’s HTTP or mixed listening port is 7890; replace it with the actual port before running. A SOCKS-only port cannot be used as an HTTP proxy. -I requests response headers, while -v prints connection and TLS diagnostic details.

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

The second command only avoids curl’s explicit proxy; it does not bypass TUN, a transparent gateway, or corporate network equipment that is still active. To compare routes accurately, first verify what is intercepting traffic. Different curl builds may also use different TLS backends and certificate stores, so if curl succeeds but the browser fails, check the browser’s certificate policies, extensions, and cache.

• If you see a connection error for 127.0.0.1, check that the core is running and listening on the expected port before changing DNS.
• If the proxy tunnel connects successfully but a certificate error appears afterward, focus on TLS validation. A successful tunnel does not mean the certificate is trusted.
• If certificate validation succeeds but the server returns 403 or 429, that is an HTTP access or rate-limit response, not a certificate error.
• If certificate validation fails, record the full error and continue checking the time, hostname, trust chain, and connection route. Don’t use -k or --insecure to hide the problem.

Restore Settings and Report the Issue

When you finish troubleshooting, restore any temporarily disabled Secure DNS settings, proxy modes, and test nodes to the intended configuration. If you changed a configuration file, keep a copy of the original and note your changes so a later subscription update does not overwrite them and bring back the same problem. Never post your subscription URL in a support ticket or public discussion.

When reporting the issue to a client maintainer, website administrator, or network administrator, include the details below. They’re more useful than simply saying “it breaks when I turn on Clash.” Clash Release Hub provides client downloads and usage guides; it is not the official development team for any client. Report specific bugs to the relevant project or service provider.

• Full version numbers for your operating system, browser, client, and mihomo core. Find them in each product’s About section or version information page.
• The hostname showing the error, the time and time zone, the browser error code, and the certificate issuer and validity period.
• System Proxy and TUN status, the actual listening port, the matched rule type, and the resulting policy. You can anonymize the node name.
• Results for the same URL after switching nodes, confirming a direct connection, and changing networks. Clearly state what changed at each step.

Recommended order: record the error → check the time → inspect the certificate chain and HTTPS decryption tools → clear mismatched DNS state → compare proxy nodes and network routes. To review traffic interception, see system proxy settings, rule configuration, and Troubleshooting. Wait until certificate validation works normally before signing in or performing other sensitive actions.