HTTPS Certificate Errors When Using a Proxy: Causes and Fixes

First, tell certificate errors apart from proxy connection failures

If you see an HTTPS certificate warning, stop entering passwords or payment details. Check your system clock, the certificate issuer, and the connection path first. Don’t treat “Continue to site” as a fix. Standard proxy forwarding does not require your browser to trust a new root certificate. Importing a subscription should not require installing a certificate provided by a website.

ClashX and clients using the mihomo core typically forward traffic. When your browser accesses an HTTPS site through an HTTP CONNECT tunnel, SOCKS, or TUN, the browser still verifies the site's certificate. TUN routing does not decrypt HTTPS, and mihomo traffic sniffing does not reissue website certificates.

Browser error names can vary. Record the error code, domain, time, and certificate issuer first, then change only one condition at a time. Record the domain only; don’t share full URLs containing login tokens.

Step 1: Check your system clock and certificate validity

An incorrect system clock can make multiple legitimate sites appear to have expired or not-yet-valid certificates. Check it first after restoring a virtual machine snapshot, leaving a device powered off for a long time, or switching between operating systems. A displayed time zone mismatch may not affect validation by itself; what matters is whether the system’s actual time is correct.

1. Windows 11: Open Settings → Time & language → Date & time, turn on Set time automatically, then select Sync now under Additional settings.
2. macOS: Open System Settings → General → Date & Time and turn on Set time and date automatically. The setting may have a different name in older versions.
3. Reopen your browser and check the certificate details on the error page. Compare the “Valid from” and “Expires” dates. If your system clock is correct and only one site’s certificate has expired, the site operator needs to renew it.

Use this command in a terminal to read the time in UTC and compare it with a trusted device. It only reads the time; it does not change system settings.

# macOS / Linux
date -u

# Windows PowerShell
(Get-Date).ToUniversalTime().ToString("o")

Step 2: Compare direct and explicit proxy connections

Turning off the system proxy does not always mean you’re connecting directly. TUN may still route connections, a browser extension may have its own proxy settings, or a corporate network may inspect traffic outside your device. Note the current mode, selected node, and configuration file first, then create a repeatable comparison.

Run three comparisons against the same domain

1. Direct connection: Turn off the client’s system proxy and TUN, and temporarily disable browser proxy extensions. Visit the same HTTPS domain on a network where direct access is allowed and the site is reachable.
2. Node A: Restore the original configuration, select the original node, and record the certificate issuer and error code.
3. Node B: Change only the node. Keep the browser, target domain, and all other settings the same, then test again.

If direct access is unavailable, a timeout does not mean the certificate is valid. For another comparison, try a different trusted network, such as a mobile hotspot. Don’t change DNS, the node, browser, and rules all at once, or you won’t know which change affected the result.

Use curl to test the HTTP CONNECT path

The examples use 7890 as the client’s active mixed port. Check mixed-port in the configuration currently in use, and update the commands if your port differs. On Windows, use curl.exe to avoid the same-name alias in some PowerShell environments.

# macOS / Linux: clear HTTP/SOCKS proxy environment variables
# Use as a direct-connection comparison only when TUN is off and no other transparent proxy is active
curl -Iv --connect-timeout 10 --max-time 20 --noproxy '*' https://example.com/

# Use the local HTTP proxy explicitly; clear the no_proxy bypass list
curl -Iv --connect-timeout 10 --max-time 20 --noproxy "" \
  --proxy http://127.0.0.1:7890 https://example.com/

# Windows PowerShell: use the local HTTP proxy explicitly
curl.exe -Iv --connect-timeout 10 --max-time 20 --noproxy "" --proxy http://127.0.0.1:7890 https://example.com/

200 Connection established only means the proxy accepted the CONNECT request; it does not confirm that subsequent TLS validation succeeded. Check the certificate verification result and final response too. The example domain is for demonstration; use the domain that actually triggered the error when troubleshooting. There’s no need to include private URL paths.

curl and browsers may use different TLS backends and trust stores, so “curl works, but the browser fails” is a clue, not a final diagnosis. Don’t add -k or --insecure to the command; those options skip the very verification you’re trying to check.

Step 3: Check for MITM interception tools and leftover root certificates

MITM means man-in-the-middle interception. In an authorized debugging or corporate environment, an interception tool may terminate the original TLS connection and issue a site certificate using a local root certificate. Certificate errors can result if proxy settings remain enabled, the root certificate has been removed, or an app does not trust that certificate store.

Check the issuer first, then trace the setting to its source

• Open the certificate details from the browser’s error page or site information panel. Check the issuer, validity period, and Subject Alternative Name (SAN). The SAN should include the domain you’re visiting.
• If multiple unrelated sites show the same unfamiliar organization or local tool as the issuer, check packet capture tools, HTTPS scanning features, browser extensions, and device management policies.
• On Windows, check manual proxy settings and setup scripts under Settings → Network & Internet → Proxy. On macOS, check for leftover settings under System Settings → Network → your current network → Details → Proxies.
• Also check the HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, and NO_PROXY environment variables. Your browser and terminal may not use the same proxy settings.

Confirm what a certificate is used for before removing it

On macOS, check both the “login” and “System” keychains in Keychain Access. On Windows, use certmgr.msc to view certificates for the current user and certlm.msc to view local computer certificates; changes to the latter usually require administrator privileges. Before checking “Trusted Root Certification Authorities,” verify the certificate’s name, purpose, and source.

On a personal device, if you confirm that a certificate was installed by an old packet capture tool, first turn off the tool’s HTTPS interception and restore your proxy settings. Then remove the certificate according to the tool’s uninstall instructions. Don’t bulk-delete system root certificates. Have your administrator handle managed devices to avoid disrupting internal services or violating network policies.

Step 4: Check suspicious nodes, DNS, and incorrect destinations

If a certificate name mismatch occurs only with one node and disappears as soon as you switch away, isolate that node and check the DNS resolution path. But a single error does not prove that the node is hijacking traffic: a captive portal near the exit, upstream DNS, or a misconfigured reverse proxy could also send the request to a different server.

Why DNS hijacking can trigger certificate warnings

When a domain resolves to the wrong server, the browser still checks the certificate against the domain in the address bar. If the wrong server presents a certificate for another domain, the names won’t match. An attacker generally can’t obtain a valid certificate for the target domain just by changing DNS, so the certificate warning is an important security boundary.

First, check the spelling of the domain in the address bar. Then check your local hosts file, browser Secure DNS, router DNS, and client DNS settings. mihomo’s fake-ip mode may return a mapped address in the 198.18.0.0/16 range; that range alone is not evidence of DNS hijacking. A regular nslookup may not use the browser’s Secure DNS or the resolution path actually used by the client.

• On the client’s “Connections” or “Logs” page, filter by the target domain and check the matched rule, policy group, and final node. The exact location depends on the client interface.
• Check whether an earlier DOMAIN, DOMAIN-SUFFIX, or rule set sends the target to DIRECT. Rules are usually matched in order, so changing the policy group may not affect a request already matched by a direct-connection rule.
• Don’t use global mode as a permanent workaround. You can use it briefly for comparison, but restore the original mode and fix the rules after testing.
• On public Wi-Fi, first complete the network sign-in process provided by the system. If the captive portal substitutes its own certificate for an HTTPS page, switch to a trusted network to verify the site. Don’t bypass the target site’s certificate warning for the portal.

Consider clearing the cache only after fixing the DNS settings. On Windows, run ipconfig /flushdns; on macOS, run the command below. Browsers and clients may also keep their own caches, so fully quit and restart them if needed.

# macOS: flush the system DNS cache (administrator privileges required)
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

If the same node continues to present a mismatched certificate while another trusted node and a direct connection work, stop using that node and report the issue to the service provider with redacted evidence. Include the domain, time, issuer, and error code; never share your subscription URL, node password, or full configuration file.

Step 5: Distinguish website certificate chain issues from client trust store issues

Once the system clock is correct and the connection path is stable, common remaining causes include an incomplete certificate chain or differences between trust stores. If a website server omits an intermediate certificate, some browsers may fill it in from cache while other devices or command-line tools fail. A site opening on one computer does not prove the server is configured correctly.

Use OpenSSL to inspect the certificate chain and verify the domain

In an OpenSSL environment that supports these options, run the command below. -servername sets SNI so a server at a shared IP address selects the right site; -verify_hostname explicitly enables hostname checking. Seeing a successful connection from a plain s_client command does not mean the certificate passed full verification.

# Direct connection: make sure TUN and other transparent routing are disabled for the test
openssl s_client -connect example.com:443 \
  -servername example.com -showcerts \
  -verify_hostname example.com -verify_return_error < /dev/null

# Through a local HTTP CONNECT proxy; requires OpenSSL with -proxy support
openssl s_client -proxy 127.0.0.1:7890 \
  -connect example.com:443 -servername example.com \
  -showcerts -verify_hostname example.com \
  -verify_return_error < /dev/null

Check the verification errors, certificate chain, and Verify return code in the output. OpenSSL may use a different trust store from macOS Keychain, the Windows certificate store, or your browser. If you see “unable to get local issuer certificate,” consider both local CA configuration and a missing intermediate certificate on the server; don’t immediately blame the node.

• Only one website fails across multiple devices and networks: Contact the site operator first and ask them to check for an expired certificate, an incorrect SAN, or an incomplete certificate chain.
• Only one older device fails: Update to a supported operating system and browser, then check the root certificate update status. Don’t download certificate bundles from untrusted forum posts.
• Only one app fails: Check whether it uses a separate CA file or certificate pinning. Don’t disable verification to work around a certificate pinning failure.
• You see a certificate revocation error: Record the specific error and network conditions, check whether revocation services are reachable, and ask an administrator or site operator to investigate. Don’t permanently disable revocation checks.

Verify the fix and preserve security checks

After making changes, retest the domain that originally triggered the error—not just a different website. Check the browser, the app you actually need, and the client logs for the matched rule and node. Restore the original rule mode and confirm the issue stays resolved after restarting the client before considering the configuration stable.

1. The system date and time are correct, and the certificate is currently within its validity period.
2. The certificate SAN matches the target domain, and the certificate chain leads to a root certificate trusted by the device.
3. The purpose of the system proxy, TUN, browser extensions, and environment variables is clear, with no leftover debugging proxy.
4. No browser startup option is being used to ignore certificate errors, and TLS verification has not been skipped on the command line.
5. Retest the original node or an alternative and confirm that the scope of the failure matches the fix.

If you continued past a warning and entered sensitive information, change the relevant passwords over a trusted network, revoke suspicious sessions, and review account sign-in history. A certificate warning does not automatically mean your information was exposed, but don’t use a questionable connection for sensitive tasks.