HTTPS Certificate Errors After Enabling a Proxy: Common Causes, Diagnosis, and Fixes

After enabling Clash, Clash Meta (mihomo), or another proxy client, your browser may show “Your connection is not private,” “Invalid certificate,” “Certificate expired,” or NET::ERR_CERT_AUTHORITY_INVALID. These warnings all appear to involve HTTPS, but they can originate in very different places: the computer’s clock may be wrong, making a valid certificate appear not yet valid; the destination site may have an incomplete certificate chain; the current network may be inspecting TLS connections; or proxy rules may be sending the request through an unsuitable exit node.

When troubleshooting, do not click through a certificate warning as soon as it appears. HTTPS certificates verify the domain you are visiting, the encrypted identity of the connection, and the certificate issuer chain. Ignoring the warning can hide genuine network interception, an incorrect exit node, or domain hijacking. A more reliable approach is to record the exact error and affected domain, compare the results with the proxy off and on, and only then inspect certificate-related client settings.

First, determine what the certificate error actually means

When you visit an HTTPS website, the browser checks whether the certificate covers the current domain, is within its validity period, and can be linked to a trusted root certificate through a valid chain. It also verifies that the hostname used during the connection matches the certificate. A proxy client generally handles connection forwarding and policy selection; it is not automatically an HTTPS decryption tool. An ordinary HTTP or SOCKS proxy can forward the connection. When the browser establishes a TLS connection to the destination through a proxy, it still sees the certificate presented by that destination.

Therefore, “a certificate error appeared after opening Clash” does not necessarily mean “Clash changed the certificate.” Distinguish between two connection patterns. In the first, the proxy only forwards TCP traffic or carries HTTPS through a tunnel, so the destination site normally provides the certificate directly. In the second, a network device, enterprise security product, or debugging tool actively inspects HTTPS content. It may install a trusted root certificate locally and generate a substitute certificate for each domain. If that root certificate is not trusted by the current browser, the browser will report that the issuer is untrusted.

Clash Meta’s TUN mode does not automatically change every HTTPS certificate either. TUN primarily captures system traffic through a virtual network adapter, then processes connections according to the configured routing, DNS, and proxy rules. It changes how traffic enters the proxy core. The key checks remain the final exit node, DNS resolution, rule matches, and any additional TLS inspection component.

Step 1: Check the system time and time zone

Certificate validity depends on the device’s current time. If the system clock is hours or days ahead or behind, the browser may treat a valid certificate as “not yet valid” or “expired.” An incorrect time zone can produce the same symptoms, especially after dual-booting, resuming a virtual machine, waking from sleep, or experiencing a motherboard clock issue. This problem is unrelated to proxy rules, but because it is often noticed after switching network environments, it can easily be blamed on Clash.

1. Open the system date and time settings, enable automatic time synchronization, and confirm that the time zone matches your location.
2. Manually synchronize the clock once. After the system reports a successful sync, fully close and reopen the browser.
3. Compare two websites that use certificates from different certificate providers. If multiple sites simultaneously report that certificates are not yet valid or have expired, prioritize fixing the system clock.

If only one site reports an error while other HTTPS websites work normally, the system clock is less likely to be the cause. Inspect the certificate details next instead of repeatedly switching proxy modes. A mobile hotspot, home broadband connection, or corporate network can provide a comparison environment, but keep the device time and browser settings as consistent as possible.

Step 2: Inspect the certificate domain, validity period, and issuer

Open the certificate details from the browser’s security information and focus on three fields. First, check the subject or common name to confirm that the certificate covers the domain you are visiting. A wildcard certificate only covers subdomains that match its pattern; it cannot cover a completely different parent domain. Second, check the validity period and confirm that the current time falls between the start and expiration dates. Third, inspect the issuer and certificate chain to see whether intermediate certificates are complete and whether the root certificate is trusted by the operating system or browser.

If the domain shown on the certificate is completely different from the domain in the address bar, possible causes include DNS resolving to the wrong server, an abnormal page returned by the proxy exit node, or interception somewhere along the network path. If the domain matches but the issuer has changed to the name of a corporate gateway, antivirus product, or local debugging tool, check whether HTTPS scanning is enabled and whether its root certificate has been deployed correctly. Do not install an unfamiliar root certificate just to remove the warning. Root certificates carry significant trust, so their source and purpose must be clear.

Step 3: Compare proxied and direct connections with minimal variables

The fewer variables you change, the easier it is to diagnose a proxy problem. First disable the system proxy or pause the client, then visit the same URL in the same browser and record whether the error remains. Re-enable the proxy while keeping the same node, DNS settings, and browser window. If the error appears only with the proxy enabled, switch to a known-working node. Change only one condition at a time; avoid modifying the rule mode, TUN, DNS, and browser extensions simultaneously.

In the client’s connection or log view, check whether the destination domain matched the expected rule and which policy group and node were actually used. In rule mode, a domain may match a specific rule before being sent through a proxy, direct connection, or reject policy. Global mode sends more requests to the selected proxy group and can be useful for a brief comparison. Direct mode helps confirm whether the site itself works, but it should not be treated as a long-term way to bypass network policies.

Also pay attention to where DNS resolution occurs. The browser, operating system, Clash core, and remote proxy may use different resolution paths. Different results can send you to different CDN nodes or an incorrect address. If only one domain is affected, clear the browser’s DNS cache first, then check whether the configured DNS mode, nameserver, fallback, and fake-ip settings fit the current network. After editing the configuration, verify that the active file is the one you changed rather than an unused copy.

Step 4: Check TLS, certificate stores, and HTTPS scanning

When the issuer points to local software or an organizational gateway, inspect HTTPS scanning in security software, enterprise proxies, parental-control programs, and debugging proxies. Some products create two TLS connections—one between the browser and the product, and another between the product and the destination—and use their own root certificate to sign a local substitute certificate. On a managed device, contact the administrator to confirm root-certificate deployment and rotation. On a personal device, you can disable HTTPS scanning and test again after understanding the security implications.

Browsers do not always use the system certificate store exclusively. Some maintain their own certificate management, encrypted DNS, or security policies, so a certificate trusted at the system level may still be rejected by the browser. For comparison, use a clean browser profile, but do not assume that “it works in another browser” means the problem is solved. It only shows that the two browsers differ in certificate storage, extensions, or network settings.

If the error mentions a TLS version, handshake failure, or connection reset rather than an untrusted issuer, focus on the exit node, destination-site compatibility, and intermediary network devices. Repeatedly importing root certificates will usually not help. For sites that require client certificates, corporate intranets, or mutual TLS, also confirm that the proxy chain supports the site’s required authentication method.

TUN mode checks

TUN mode routes system traffic through a virtual network interface. As a result, the browser can be affected by core rules even without a traditional HTTP proxy configured. When a certificate error occurs, temporarily disable TUN and keep only the system proxy enabled for comparison. Alternatively, leave TUN enabled and test once with a direct policy. The goal is to identify the traffic path, not to recommend permanently using one particular mode.

• Confirm that the TUN virtual adapter was created correctly and does not conflict with another VPN, virtual machine adapter, or network-acceleration tool.
• Check whether DNS is being handled by the active core and whether fake-ip mappings are being mishandled by the browser, system security software, or a device on the local network.
• Review the rule-match record for the destination domain and confirm that an expired rule set did not send the request to the wrong policy group.
• If the connection works normally after TUN is disabled, compare DNS, routing, and adapter priority instead of immediately resetting the entire configuration.

Recommended fix order and security boundaries

The full process can be reduced to a dependable sequence: record the error, correct the clock, inspect the certificate domain, validity period, and issuer, compare direct and proxied access to the same site, check the node, rules, DNS, and TUN path, and finally review certificate stores in the browser, operating system, or security software. Reload the page and record the result after each step so you can identify which change actually affected the connection.

Do not treat “ignore certificate errors” as a routine fix, and do not import an unfamiliar root certificate merely to make a page load. On corporate devices, certificates and proxy policies may be centrally managed, so personal changes can create compliance or access issues. On public networks, verify an unusual issuer over a trusted network first. If one site remains abnormal over time, contact its maintainer to confirm the server certificate chain and domain configuration.

Record the error code
  → Correct the system time and time zone
  → Check the certificate domain / validity period / issuer
  → Compare the same site with a direct and proxied connection
  → Check the node, rule matches, and DNS
  → Compare the TUN toggle and browser certificate settings
  → Handle HTTPS inspection certificates only when their source is known

After troubleshooting, restore the original proxy mode and security settings, and remove certificates, browser extensions, or rules added temporarily for testing. If the problem occurs on only one node, switch nodes temporarily and report it to the service provider. If every node and multiple networks show the same error, focus on the device clock, browser environment, or the destination site’s certificate. This layered approach turns a vague “the proxy does not work” report into a specific issue involving the certificate, DNS resolution, rules, or network path.