HTTPS Certificate Errors When Using a Proxy: Causes and Fixes for Clash Users

HTTPS Certificate Errors: Identify Where the Problem Occurs

Seeing “Your connection is not private” after starting the Clash client only means the browser can’t verify the identity of the current connection. It doesn’t prove that a proxy node has altered the website. An incorrect system clock, an expired site certificate, a public Wi-Fi sign-in page, HTTPS inspection on a corporate network, or DNS resolving the domain to the wrong server can all trigger similar warnings.

HTTPS usually connects to the destination server on port 443. During the TLS handshake, the browser checks the certificate’s validity period, certificate chain, and whether it matches the requested domain. A proxy changes the route traffic takes; the browser still needs to verify the server’s identity. Don’t start by disabling validation. First, note the full error code, the domain in the address bar, and the certificate’s issuer and validity dates.

How the Clash Client Forwards HTTPS Traffic

Standard Proxy Forwarding Does Not Replace Website Certificates

When a browser uses a local HTTP proxy to access an HTTPS site, it typically sends CONNECT destination-domain:443, then performs a TLS handshake with the site through the established tunnel. SOCKS proxies and TUN mode can also forward encrypted connections. With standard proxy forwarding, the browser should see the destination website’s certificate—not a “Clash certificate.”

Clash client rules determine whether a connection goes direct or through a proxy, and which proxy group it uses. Even when domain sniffing is enabled, reading visible handshake information is not the same as decrypting HTTPS traffic. Enabling TUN, Fake-IP, or sniffing alone does not mean the browser’s certificate has been replaced.

Keep the Website Certificate Separate from the Proxy Node Certificate

Some proxy protocols also use TLS. In that case, two separate checks take place: the core verifies the proxy node’s TLS certificate, while the browser verifies the destination website’s HTTPS certificate. If the core log reports x509: certificate has expired or is not yet valid while connecting to the proxy server, the issue may be with the node. If the browser shows the destination website’s certificate and reports a domain mismatch, investigate the website connection instead.

In mihomo configuration, some TLS nodes support skip-cert-verify. This setting applies to certificate verification for that node; it does not disable the browser’s checks for the destination website. Setting it to true won’t reliably fix a browser certificate error and weakens node identity verification. Ask the configuration provider to fix the node’s certificate, server name, or connection address.

First Checks: Time, Domain, and Certificate Details

1. Save the error details. Record the full URL and error code. Open the site information panel or certificate viewer in your browser and check the issuer, validity dates, and Subject Alternative Name (SAN). The menu location may vary between browser versions; use the certificate details window as your reference.
2. Correct the device clock. In Windows 11, open Settings → Time & language → Date & time, turn on Set time automatically, then select Sync now. On macOS, open System Settings → General → Date & Time and check that Set time and date automatically is enabled.
3. Check the exact domain. Look for typos or a redirect from an old bookmark to a new subdomain. A SAN entry for *.example.com generally covers www.example.com, but not a.b.example.com or the root domain example.com.
4. Compare the certificate’s validity dates. For example, if the device shows 2025 but the certificate becomes valid in 2026, the certificate may appear not yet valid. If the device clock is set to 2030, a certificate that is still valid may appear expired. These are examples, not current certificate details for this site.

The time zone mainly affects how local time is displayed. A different time zone alone usually won’t cause certificate validation to fail if the device’s actual timestamp is accurate. Correct the date and time itself, not just the time zone setting.

The Error Affects Only One Website

If other HTTPS sites work on the same network and both direct and proxied connections show the same expired certificate, first suspect an expired site certificate or an incorrectly deployed certificate chain. Switching between proxy nodes won’t make an expired certificate valid again. Record the error for the site administrator and wait for the server-side fix.

Second Checks: Compare Routes to Isolate Proxy Issues

Change only one variable at a time, keeping the same URL and browser and testing at roughly the same time. First note the current rule mode, proxy group, and node, then run the comparisons below. Different routes may reach different CDN edge servers, so a different certificate alone is not proof of interception. Also check whether the certificate covers the domain and whether its chain is trusted.

Turning off the system proxy does not always mean traffic goes direct

If TUN mode is still running, traffic may continue to be routed through the virtual network adapter. Browser extensions can also configure their own proxy. Before testing a direct connection, turn off the Clash client’s system proxy and TUN mode, and make sure the browser isn’t using a separate proxy. Restore your settings after the test. On a managed device, follow your organization’s network requirements; don’t bypass mandatory policies.

In the Clash client’s connection list, find the connection for the target domain and check its matching rule and final policy. A selected node in the interface does not mean every request goes through it: a rule may route the target to DIRECT or another proxy group. For more on rule matching, see Advanced Configuration.

Compare Connections with curl and the Local Proxy

The commands below use example.com to illustrate the syntax and assume the local HTTP or mixed port is 7890. Use the port configured in your Clash client. On Windows, use curl.exe; on macOS or Linux, use curl.

# Bypass proxy environment variables explicitly to test a direct connection
curl --noproxy "*" -Iv https://example.com/

# Use the local HTTP proxy explicitly
curl --proxy http://127.0.0.1:7890 -Iv https://example.com/

If TUN is still running, it may also capture traffic from the first command, so complete the steps above first. -I requests response headers, while -v prints connection and handshake details. Don’t add -k or --insecure, which would skip the certificate check you’re trying to diagnose. curl may use a different TLS implementation and trust store than your browser, so treat its output as a comparison—not a substitute for browser validation.

How DNS, Fake-IP, and Captive Portals Can Affect Certificates

A Wrong Destination Can Return a Different Certificate

If DNS resolves a domain to the wrong server, the browser still checks the certificate against the original domain. For example, you might visit www.example.com but receive a certificate that covers only a network sign-in portal, triggering a domain mismatch. If several unrelated websites show the same unfamiliar issuer or portal domain, first check public Wi-Fi authentication, router settings, and local HTTPS inspection software.

Fake-IP maps domains to connections; it is not a way to forge HTTPS certificates. A common mihomo example uses 198.18.0.1/16 as the Fake-IP range, but check your actual configuration. An address in this range does not by itself indicate DNS poisoning. Check the DNS enhancement mode, whether TUN is active, and whether the domain mapping is valid.

• After changing the DNS enhancement mode or turning off TUN, old DNS cache entries may temporarily keep the mapped address. First make sure the new configuration is active, then clear the cache and restart the browser.
• On Windows, run ipconfig /flushdns to clear the system DNS cache. Your browser may have a separate cache, and clearing the cache won’t fix an expired certificate.
• Your browser’s Secure DNS setting may change the route used for DNS lookups. Note the current setting, then test consistently with your client’s DNS setup. Avoid changing both the proxy node and DNS resolver at the same time.

Complete Public Wi-Fi Sign-In First

Hotel, airport, and campus networks may require you to sign in through a portal first. Use the network sign-in window opened by your device, or the authentication page provided by the network operator. If an HTTPS page redirects and triggers a certificate warning, don’t enter your username or password on the warning page. Sign in through a trusted portal, then restore your proxy and revisit the site.

Corporate Root Certificates, Website Certificate Chains, and Security

Corporate gateways, security software, or debugging tools may actively inspect HTTPS traffic: they establish one TLS connection between your device and the gateway, then connect from the gateway to the website. Your browser may then see a website certificate issued by your organization’s root certificate. On a managed device, this may be an explicitly configured network policy. On a personal device, verify any unexpected issuer carefully.

1. Verify who manages it. Ask your organization’s administrator whether HTTPS inspection is deployed, and confirm the root certificate’s source and device management records. Don’t obtain certificates from forum attachments or unfamiliar messages.
2. Compare networks. If permitted, switch to a trusted personal network. If the unfamiliar issuer appears only on one network, investigate that network’s gateway. If it appears on every network, check local software and trust settings.
3. Check the website’s certificate chain. If a site is missing an intermediate certificate, some browsers may work because of a cached certificate while other devices fail. The website administrator should install the complete certificate chain on the server; visitors should not be asked to trust the leaf certificate.
4. Use a supported environment. Update your operating system and browser to get the relevant security fixes and trust store updates. On managed devices, administrators should handle updates and certificate changes according to policy.

Checklist Before Restoring the Connection

• Correct time: The system clock is synchronized, and the certificate is currently within its validity period.
• Matching domain: The certificate SAN covers the domain in the address bar; you don’t need to bypass the warning to continue.
• Known route: You’ve confirmed the actual status of the system proxy, TUN, any browser-specific proxy, and the rule that matched.
• Trusted issuer: You’ve identified the source of any unfamiliar certificate, and any organizational certificate has been verified through official management channels.
• Reversible changes: You’ve kept the original configuration and haven’t hidden the issue by skipping certificate verification.

When asking for help, include the error code, operating system and browser versions, Clash client and core versions, whether TUN is enabled, and the results of direct-versus-proxy tests. Certificate screenshots can show the domain, issuer, and validity dates. Redact subscription links, node passwords, access tokens, and personal URLs from logs. For basic connection troubleshooting, see Troubleshooting.

A useful troubleshooting order is: identify which layer reported the error, check the device clock and certificate identity, compare connection routes, then investigate DNS, gateways, or the website’s deployment. The goal is to restore a trusted HTTPS connection—not merely make the warning disappear.