Browser Certificate Errors When Using a Proxy: Causes and Fixes for HTTPS Warnings

Note the error code first, then narrow down the scope

If you see “Your connection is not private” after enabling FlClash, the browser has encountered a problem verifying the site's HTTPS identity. Start by noting the error code, domain, and certificate details—not by repeatedly reloading the page. If the page is for a login, payment, or email service, stop before entering passwords or verification codes, and keep a record of the error page.

Expand the “Advanced” details on the browser’s error page and note the full error code. If there’s an option to view the certificate, also record its issuer, validity dates, and Subject Alternative Names. The option’s location varies by browser, so use the certificate details provided on the error page whenever possible.

Common error	What the verification failure may indicate	Check first
`NET::ERR_CERT_DATE_INVALID`	The current time falls outside the certificate’s validity period	Device date, time synchronization, and the site certificate’s expiration date
`NET::ERR_CERT_COMMON_NAME_INVALID`	The certificate does not cover the domain you’re visiting	Address bar spelling, certificate SANs, DNS, and redirects
`NET::ERR_CERT_AUTHORITY_INVALID`	The certificate chain does not lead to a trusted root	Issuer, site certificate chain, and HTTPS inspection software
`SSL_ERROR_BAD_CERT_DOMAIN`	Firefox detected a domain mismatch	Target host and certificate coverage

Next, determine the scope: is just one site affected, or are several unrelated HTTPS sites failing at the same time? Does the problem occur with just one node, or even with the proxy turned off? These clues are more useful for pinpointing the cause than simply checking whether the network is online. Connection timeouts, connection resets, and certificate errors occur at different stages and require different troubleshooting steps.

HTTPS handshakes and proxies: distinguish the two certificate layers

When you visit an HTTPS site, the browser checks the site's domain name, certificate validity, and chain of trust. With a standard HTTP proxy, the browser typically establishes a tunnel using CONNECT, then performs the TLS handshake with the site. SOCKS proxies and TUN routing can also forward this encrypted traffic. Standard proxy forwarding does not require installing a dedicated root certificate in the browser.

If the node’s protocol uses TLS, there’s an additional verification step between your client and the proxy node. In this case, messages in the mihomo log such as x509: certificate has expired or is not yet valid or certificate signed by unknown authority may point to the node’s certificate. The certificate shown on the browser’s error page usually belongs to the site you’re visiting. Troubleshoot these two layers separately.

Certificate warning shown directly in the browser: Check the target domain, certificate issuer, system clock, and local trust store first.
Client log reports a node TLS failure: Check the node’s server name, subscription settings, and certificate status, then contact your provider.
The page reports a proxy connection failure or keeps timing out: Check the local listening port, node connectivity, and routing first; don’t assume the site’s certificate is at fault.

Incorrect system time: fix the date and enable automatic synchronization

Certificates have specific start and expiration dates. If your device’s date falls outside that validity period, verification will fail even when the site is configured correctly. Switching between operating systems, leaving a device powered off for a long time, or a faulty motherboard battery can cause the clock to drift. Compare it with a trusted time source, check the year, date, and minutes, then confirm the time zone.

Windows 11: Open Settings → Time & language → Date & time, turn on “Set time automatically,” then select “Sync now” under “Additional settings.”
macOS: Open System Settings → General → Date & Time and check that automatic date and time are enabled. You may need administrator authorization to make changes.
Android: Search Settings for “Date & time” and turn on automatic time and automatic time zone. Menu names and locations vary by manufacturer.
Once synchronization is complete, close the tab that showed the error, revisit the same domain, and check the certificate’s validity dates.

The time zone affects how time is displayed, but certificate validity is determined by the actual point in time. Correcting the time zone alone won’t help if the system clock is still wrong. If the clock is correct and only one site reports an expired certificate, the site’s administrator needs to renew it. Switching proxy nodes cannot make an expired certificate valid again.

Intercepting certificates: check the issuer and local HTTPS inspection

Corporate gateways, some security software, and debugging proxies may inspect HTTPS traffic by decrypting it. They present a newly issued certificate to the browser, then connect to the destination site on its behalf. If the corresponding root certificate is untrusted or expired, or if an old software configuration remains, the browser may report that the issuing authority is not trusted.

Run three checks using the same domain

Compare the certificate issuer on the affected device with one on another device that works. Certificates can differ because of a CDN or recent updates, but an issuer name matching a corporate gateway, security product, or debugging tool deserves closer investigation.
Compare two browsers on the same device. Browsers may use trust stores differently. If only one browser reports an error, check its certificate settings, extensions, and management policies first.
If permitted, test using a mobile hotspot. If the problem only occurs on a corporate network, ask the network administrator to check its inspection policies and certificate deployment.

On Windows, run certmgr.msc to view certificates for the current user, or certlm.msc to view certificates for the local computer. Check “Trusted Root Certification Authorities” carefully; don’t bulk-delete certificates based on unfamiliar names. On macOS, review relevant certificates and trust settings in Keychain Access. Follow your organization’s process for certificates on managed devices.

If you’ve used packet-capture or debugging software, quit it and check whether the system proxy still points to it. Browser proxy extensions and the system proxy can send traffic through different routes. Change one setting at a time and record the result after each test. Avoid deleting certificates, resetting the browser, and changing configuration all at once—you could lose track of what fixed the issue.

Domain mismatch: check DNS, captive portals, and routing rules

A DNS issue can send a domain to the wrong server, but a bad DNS result won’t always trigger a certificate warning; it may simply cause a timeout. For a domain mismatch, first check the address bar for typos, then see whether the certificate’s Subject Alternative Names (SANs) cover the hostname you’re visiting. A certificate for example.com does not necessarily cover all of its subdomains.

Complete public Wi-Fi sign-in first

Hotel, airport, and campus networks may require sign-in through a captive portal. Open the portal using your device’s “Sign in to network” notification, make sure it’s the correct network, and complete sign-in before testing HTTPS. Don’t enter public Wi-Fi credentials on a certificate error page for a bank or email service. Identify the captive portal separately from the site you intended to visit.

Check system DNS and proxy DNS separately

On Windows, use the command below to check the system’s DNS lookup result. It only shows the result for that resolution path; it may differ from the browser’s Secure DNS or mihomo’s DNS result.

nslookup example.com
ipconfig /flushdns

The second command clears the Windows system DNS cache. It does not automatically clear the browser cache, upstream resolver caches, or mihomo’s internal cache. If your configuration uses Fake-IP, seeing a mapped address does not mean DNS has been poisoned. mihomo commonly uses 198.18.0.0/16 as its Fake-IP address pool, but check your current configuration.

In FlClash’s connection log, search for the affected domain and check which rule matched and which outbound route was used. Rule mode selects direct or proxy routing based on your configuration; Global mode changes the outbound route but does not fix the system clock or trust store. If the browser uses Secure DNS, note its status too. Changing system DNS alone doesn’t prove that every DNS lookup path has changed.

Troubleshoot nodes and TUN: change one variable at a time

If switching nodes fixes the problem, that only shows the issue is related to that route. Check whether the original node had a bad DNS result, an exit-side redirect, or a connection problem. In a normal end-to-end HTTPS connection, the browser should still verify the site’s identity. If you see an unfamiliar certificate, save its details and stop using the affected route until you’ve investigated it.

Record the current outbound mode, selected node, system proxy and TUN settings, affected domain, and error code.
Keep the node unchanged, turn off TUN, and test the browser using only the confirmed system proxy. Verify that the request is still going through the client.
Restore the original settings, change just one node, then revisit the same domain and compare the error code and certificate issuer.
If direct connections are allowed on your network and permitted by your usage requirements, turn off the system proxy and TUN for a comparison test. Check browser extensions and command-line environment variables too, as they may still specify a proxy.
Compare the failure time with the client log to determine whether the problem occurred during the node’s TLS connection or while accessing the site.

Test an HTTP proxy using an explicit port

The example below uses 7890 as a local HTTP or mixed port. Check your current client configuration for the actual port and replace the example in the command; this is only an example, not a default for every FlClash setup. On Windows, use curl.exe to avoid differences with older PowerShell command aliases. On macOS or Linux, use curl.

curl.exe --noproxy "*" -Iv --connect-timeout 10 https://example.com/
curl.exe --noproxy "" -x http://127.0.0.1:7890 -Iv --connect-timeout 10 https://example.com/

The first command bypasses explicit proxy settings in curl; the second explicitly specifies the local HTTP proxy. Both retain certificate verification and set a 10-second connection timeout. With TUN enabled, traffic from the first command may still be intercepted, so --noproxy alone does not prove that the connection is truly direct. A SOCKS-only port cannot be used as an HTTP proxy address.

curl and browsers may use different certificate backends and trust stores, so a successful command is just one point of comparison—it doesn’t mean the browser issue is fixed. Before sharing verbose output, remove proxy credentials, cookies, subscription URLs, and other sensitive information.

Confirm the fix: verify certificates, then restore your usual settings

After making changes, revisit the domain that first failed, then test two unrelated HTTPS sites you use regularly. Check that pages load normally, the error code is gone, and the certificates have valid dates and match the domains. Restore your usual rule mode, system proxy, or TUN settings, then repeat the tests.

Only one site continues to fail: Contact the site administrator with the domain, error code, certificate validity dates, and test time.
Only one node continues to fail: Contact your subscription provider with the node name, time of failure, and redacted logs. Don’t share your subscription URL.
Only a corporate network or managed device is affected: Ask your administrator to check root certificate deployment, gateway time, and HTTPS inspection policies.
All networks are affected: Continue checking the device clock, system updates, browser trust store, and local security software.

The goal of fixing a certificate error is to restore a verifiable connection, not hide the warning. To review how the client handles network traffic, see the Getting Started guide. For basic subscription and connection questions, see Troubleshooting.