A customer says the panel won't open. It opens for you, it opens for everyone else, and your monitor shows 200. What makes this awkward is the urge to fix something when there's usually nothing to fix: the problem is almost never on the panel's side. Here's a diagnostic order that answers "where exactly is the break" in ten minutes, plus an honest look at when a proxy helps and when it does nothing.
First separate "everyone" from "one person"
Before changing anything, establish the scale. Three quick checks do it:
- External uptime checks. Services like check-host probe your domain from dozens of nodes in different countries. If every node returns 200, including nodes in the customer's country, the panel works and the question is their connection.
- DNS. The domain must resolve to the right address. A fresh CNAME may simply not have propagated, and an old A record may linger from a previous host.
- Server logs. The most underrated check. If the access log holds no request from the customer's IP at the relevant time, their browser never reached the server — and no server-side change can help.
This isn't theory: in a real case on one panel, monitoring returned 200 from every node including those in the customer's country, while the morning's logs contained no request from that country at all beyond the monitoring nodes and a search bot. The diagnosis was filtering at the customer's ISP, not a panel outage.
What to ask the customer
"It doesn't work" is useless. Ask for four things and you'll cut the back-and-forth dramatically.
- The exact error.
ERR_CONNECTION_CLOSED, a timeout, a certificate warning and an ISP block page are four different causes. - A different network. Home Wi-Fi versus mobile data. If mobile works, the home ISP is filtering, and vice versa.
- A different device and a private window. That rules out browser extensions and local cache.
- Antivirus with HTTPS inspection. Those modules substitute the certificate and quite often cut the connection themselves.
Common causes, sorted by likelihood
- Filtering at the customer's ISP. Filtering gear on home and mobile lines is stricter than in data centres — which is why monitoring from a data centre sees the site and a person doesn't.
- Local protection. Antivirus, a corporate gateway, a blocking extension.
- The customer's DNS. Their resolver's cache serves an old address; switching to a public resolver settles it.
- The certificate. Not issued or not renewed — but then everyone sees the error, not one person.
- The panel itself. Genuinely last on the list, which is exactly why it should be checked first by automation rather than by hand.
When a proxy helps and when it doesn't
The first reflex is to switch on Cloudflare proxying and hope it hides things. It's worth knowing what actually changes: the customer connects to the proxy's address instead of your server. So it helps when the block targets your server's IP address. When the block targets the domain name, proxying buys nothing: the name still travels with the connection handshake and stays visible.
Hence the order: work out the nature of the block first, then decide. And if you do enable proxying, the encryption mode between proxy and server must be the strict one, with certificate validation. Loose modes create a redirect loop, because the server upgrades requests to HTTPS itself, and they clash with automatic certificate issuance badly enough that the panel stops opening for everyone.
The other working option is a mirror domain: the same panel on a second domain, with the link kept in your emails and support replies. It requires no infrastructure change and resolves more cases than proxying, because a fresh name hasn't reached any filter yet.
What to set up in advance
- External monitoring from the countries you sell to. So you hear about a problem before your customer does.
- Access to server logs. Without them every investigation turns into guesswork.
- A backup contact channel. Telegram or email: if the panel won't open, the customer must know where to write.
- A domain with no history. A cheap domain with a filtered past costs more than a new one.
Wrap-up
The rule is simple: measure before you change. Monitoring from several countries, DNS and access logs for the right time window tell you where the break is — and most often the answer is "in the customer's connection", not "in the panel". The infrastructure side of renting stays with us: certificates, availability, logs and diagnostics on request, mirror-domain help included. It still costs zero while third-party orders stay under a hundred a month, and at any volume on our own catalog.
