HTTPS Certificate Errors After Enabling a Proxy: Causes and Fixes

Identify the error before bypassing certificate checks

If your browser shows “Your connection is not private” after you enable Clash, that doesn’t mean the proxy app needs a certificate installed. Stay on the warning page and note the full domain, error code, and time it occurred. Don’t sign in, make payments, or download anything described as a certificate repair tool from the error page.

Standard HTTP CONNECT and SOCKS5 proxies primarily forward connections. TLS is still negotiated between your browser and the destination site, and the browser verifies the certificate’s domain, validity period, and chain of trust. Standard proxy forwarding in Clash or Clash Meta (mihomo) does not require your browser to trust a new local root certificate.

“Ignore certificate errors” is not a general-purpose way to restore a connection. First find out why the certificate isn’t trusted, then check your time, network, or proxy route. Don’t leave certificate verification disabled as a routine setting.

Error messages vary by browser. Firefox may show codes such as SEC_ERROR_UNKNOWN_ISSUER. A protocol error or connection timeout may occur before any certificate is received, so don’t assume every error means the certificate has expired.

Step 1: Correct your system time and note the certificate details

Sync the clock, then reopen the page

1. Windows 11: Go to Settings → Time & language → Date & time, turn on Set time automatically, check your time zone, then select Sync now.
2. macOS: Go to System Settings → General → Date & Time, turn on Set time and date automatically, and check your time zone.
3. Android: Go to Settings → System → Date & time and turn on automatic time settings. Menu names vary by manufacturer; the option may be under Additional settings.
4. iPhone: Go to Settings → General → Date & Time and turn on Set Automatically.

A clock that’s off by months can cause errors on many otherwise healthy websites. A different displayed time zone alone doesn’t necessarily break TLS validation—the key is whether your device’s actual time is correct. After syncing, close the tab with the error and visit the same domain again instead of repeatedly refreshing the old warning.

Note these three certificate fields

Use your browser’s View certificate option to note the validity period, issuer, and Subject Alternative Name (SAN). In newer browsers, this option may be under the site information control beside the address bar or in the warning page’s advanced details. Don’t choose to continue to the site just to view its certificate.

• Validity period: Is today’s date between the certificate’s start and expiration dates?
• SAN: Does it cover the hostname in the address bar? A certificate for *.example.com usually won’t cover the root domain example.com or a deeper subdomain such as a.b.example.com.
• Issuer: Does the issuer name identify a hotel, corporate gateway, or security product? The name alone doesn’t establish whether it’s trustworthy; verify it against your network environment.

If the time is correct and only one site has an expired certificate, the site operator needs to renew it. Switching nodes might happen to reach another working endpoint, but it doesn’t fix the site—and weakening verification is not a safe workaround.

Step 2: Rule out captive Wi-Fi portals and local HTTPS inspection

Airport, hotel, and campus guest Wi-Fi often require you to sign in through a web page first. Before sign-in, the gateway may redirect ordinary HTTP requests. If it also intercepts HTTPS, the certificate you receive may belong to the sign-in gateway, not the site you intended to visit. Switching proxy nodes at random usually won’t help.

1. Temporarily turn off the system proxy and TUN while staying connected to the current Wi-Fi. Turning off only one may leave the other routing your traffic.
2. Use the system’s “Sign in to network” prompt if it appears. If not, visit http://example.com/ to trigger the captive portal redirect. Use this address only to bring up the sign-in page—never to submit sensitive information.
3. Check that the sign-in page belongs to the venue’s network operator, then complete any required authentication. If the sign-in page itself shows a certificate warning, ask venue staff to verify it first.
4. Confirm that ordinary HTTPS sites work over a direct connection, then restore your proxy settings and test again.

If the issue disappears on a phone hotspot, suspect the original Wi-Fi’s sign-in portal, gateway, or network policy. This is a useful clue, not conclusive proof. Corporate networks may inspect HTTPS under an approved policy; ask your administrator how to obtain the required certificates rather than bypassing organizational controls.

If only one computer is affected, check for local HTTPS interception

Security software’s encrypted-connection scanning, packet capture tools, and debugging proxies may decrypt HTTPS traffic. Check whether any of these features were recently enabled, and whether the certificate issuer matches the product. On a personal device, follow the vendor’s instructions to pause the feature briefly for comparison, then restore it. For a managed device, contact your administrator.

Don’t bulk-delete system root certificates or install an unfamiliar root certificate sent by a proxy provider. A standard proxy subscription typically provides nodes, policy groups, and rules; it doesn’t need a website-trust certificate to work.

Step 3: Compare direct and proxied connections to the same domain

Keep the URL exactly the same and change only one condition at a time. Here, “direct” means the system proxy, TUN, and any browser-specific proxy are all off. “Proxied” means you’ve confirmed the request is actually going through the current client. If the site can’t be reached directly, record a timeout; it doesn’t mean the certificate is valid.

Use curl to distinguish certificate errors from connection failures

The examples below assume your client’s mixed proxy port is actually 7890. Check the port in the client settings first; it isn’t a universal default. In Windows PowerShell, use curl.exe; on macOS or Linux, use curl.

# Bypass explicit proxy environment variables and test a direct connection
curl --noproxy "*" -Iv --connect-timeout 10 https://example.com/

# Connect explicitly to the local HTTP mixed proxy port
curl --noproxy "" -x http://127.0.0.1:7890 -Iv --connect-timeout 10 https://example.com/

Here, http://127.0.0.1:7890 connects to a local HTTP proxy; it doesn’t change the destination website to HTTP. HTTPS destinations are usually accessed through a CONNECT tunnel. Don’t change it to https://127.0.0.1:7890 unless the local proxy endpoint itself supports TLS.

Turn off TUN as well when testing a direct connection, because --noproxy can’t bypass transparent routing at the system level. curl exit code 60 usually indicates certificate verification failed, 7 indicates a connection failure, and 28 indicates a timeout. These are general reference values, not test results from this article. curl and your browser may use different trust stores; if their results differ, investigate further rather than assuming one is definitive.

Step 4: Check rules, DNS, and the actual exit route

Misconfigured rules don’t usually change a website’s certificate, but they can route a connection through the wrong exit or resolve a domain to a server that doesn’t suit the current route. In the client’s Connections view, filter for the failing domain, visit it again, and note the matched rule, policy group, and final node. Then check the logs for DNS resolution or handshake failures.

Use Global mode only for a brief comparison

If Rule mode fails but Global mode works with the same node, check whether the domain is being matched to DIRECT too early or routed to a different policy group. Switch back to Rule mode after testing. Rules are matched from top to bottom; don’t send all traffic through one exit long-term just to fix a single domain.

This is only an example of rule order, not a complete configuration. Before adding it, confirm that a group named Proxy exists and replace the example domain with the one that’s actually failing. If a subscription manages your configuration, use the client’s supported override or merge feature so your changes aren’t lost on the next update.

mode: rule
rules:
  - DOMAIN,example.com,Proxy
  - DOMAIN-SUFFIX,example.org,DIRECT
  - MATCH,Proxy

A fake IP doesn’t mean a certificate is being forged

mihomo’s fake-IP mode assigns virtual addresses to domains, commonly from 198.18.0.0/16, depending on the configuration. The core uses its mapping to continue handling the original domain; seeing one of these addresses doesn’t prove HTTPS is being decrypted. The browser should still start TLS using the domain and verify its certificate.

• Don’t replace the domain in the address bar with its resolved IP to test the certificate. That changes the certificate matching conditions and may also change the SNI and virtual host selection.
• Check your local hosts file and the configuration’s hosts section to make sure the failing domain isn’t pinned to an old server.
• If Secure DNS is enabled in your browser, note which resolver it uses; it may follow a different path from the client’s DNS. Compare one setting at a time only if you understand the implications, then restore it after testing.
• Reconnect after changing DNS. On Windows, run ipconfig /flushdns to clear the system cache, but your browser and client may maintain separate caches.

Don’t change DNS, nodes, rule mode, and TUN settings all at once. Change one thing, retest the same URL, and record whether the error code and issuer changed so you can tell what made a difference.

Distinguish browser certificates from proxy-node transport certificates

Another common point of confusion: the browser shows no website certificate warning, but the client log reports x509: certificate signed by unknown authority. This can happen when the core connects to a proxy node over TLS. It’s a certificate issue between the client and the node—not necessarily between the browser and the website.

Check the node address, server certificate validity period and chain, and the server name specified by the node provider. For a self-hosted service, fix the certificate chain or configure trust through a controlled process. For a subscription node, ask the provider to investigate. Don’t guess at the SNI or enter the domain of an unrelated website.

The node setting skip-cert-verify: true skips certificate verification for that node’s TLS connection; it doesn’t fix a destination website’s certificate. A browser option to ignore certificate errors is just as unsuitable as a permanent fix.

If the same node repeatedly triggers the error, disable it and switch to a confirmed working exit, then send the provider the time, node ID, and redacted logs. Don’t share your subscription URL, access tokens, node passwords, or full configuration file.

Verify the fix and document the issue

Getting the page to load isn’t enough—you should also make sure you didn’t “fix” the warning by temporarily weakening verification. Follow these steps to reduce the chance of the problem returning when you switch networks.

1. Restore your usual rule mode and confirm that system proxy and TUN are enabled or disabled as you normally use them.
2. Reopen the domain that showed the error. Confirm there’s no certificate warning, the SAN matches the hostname, and the current date is within the validity period.
3. Check two other HTTPS sites you use regularly to rule out a single page loading from cache.
4. Undo temporary DNS, rule, or debugging changes. If a change must remain, save it in a supported override configuration and back it up.
5. Record the actual cause, such as “system year was incorrect,” “Wi-Fi sign-in was incomplete,” or “one node had an abnormal exit.” Don’t just note “restarting fixed it.”

If you need further help, provide the browser name and version, OS version, client and core versions, affected domain, error code, direct-versus-proxy results, and certificate issuer. Hide accounts, private domains, and subscription credentials before sharing screenshots. Useful evidence is more helpful than repeatedly importing the subscription.

Use a consistent troubleshooting order: check the time and error type, rule out Wi-Fi sign-in and local inspection, compare exit routes, then check rules and DNS. If the issuer is unfamiliar or a sensitive site is affected, stop before submitting information—don’t force the page open.