How to work out what is blocking your connection

How a connection fails is diagnostic in itself. Match what you are seeing against this table before doing anything else.

DNS manipulation is the cheapest form of blocking and therefore the most common, and it is the easiest to rule in or out. The test is to ask two different resolvers the same question and compare.

1. 1

   Ask your network's resolver

   Run `nslookup example.com` (Windows) or `dig example.com` (macOS and Linux) with no other arguments, so it uses whatever resolver the network handed you.

2. 2

   Ask a public resolver directly

   Run `nslookup example.com 1.1.1.1` or `dig @1.1.1.1 example.com`. This bypasses the network's own resolver, assuming outbound DNS is permitted at all.

3. 3

   Compare the answers

   Different addresses, an answer of 0.0.0.0 or 127.0.0.1, or an NXDOMAIN from one and a valid answer from the other, all indicate interception. Identical answers rule DNS out.

4. 4

   If the second query also fails or returns the same wrong answer

   The network is likely redirecting all port 53 traffic to its own resolver, which is common. Encrypted DNS (DNS-over-HTTPS or DNS-over-TLS) is the countermeasure, and most operating systems now support it natively.

Be clear about what fixing DNS achieves. It gets you a correct address. It does nothing about whether you are allowed to reach that address, and the hostname will be sent again in the clear in the TLS handshake that follows. DNS problems and connection problems are separate, and it is common to have both.

If the name resolves correctly but nothing connects, the next question is whether the address is unreachable or whether the particular thing you are trying to do to it is being stopped. These look identical from the application and are easy to tell apart at the command line.

1. 1

   Test the port with a plain TCP connection

   On macOS or Linux: `nc -vz <address> 443`. On Windows: `Test-NetConnection <address> -Port 443`. This opens a bare TCP connection and nothing more.

2. 2

   Interpret the result

   If the TCP connection succeeds, the address and port are reachable and the problem is with the protocol you are speaking on top of them — the filter classified the traffic. If TCP itself fails, the address or port is blocked outright.

3. 3

   Test a second port on the same address

   If 443 fails but another port succeeds, the block is port-specific. If every port fails, the address is blocked.

4. 4

   Test a different endpoint

   If a different address works with the same settings and the same protocol, the first address is blocklisted and no amount of protocol tuning will recover it.

This distinction is the most valuable thing in this guide. Address blocking calls for a different endpoint. Protocol blocking calls for a different protocol or transport. Applying the wrong remedy will look like the problem being unfixable.

A connection that establishes, passes a little traffic and then dies abruptly is a different signature from one that never establishes. It usually means the filter needed to see some bytes before classifying the flow, and then killed it by forging a TCP reset that appears to come from the far end.

• It is reproducible and quick — typically within a second or two, and at the same point every time. Genuine faults are erratic.
• The far end is unaware of it. From the server's perspective, the client vanished.
• It is timed to the handshake rather than to volume: transferring more data does not bring it on sooner.

If you have a packet capture tool available, a reset arriving with a time-to-live noticeably different from the other packets in the same flow is a strong indicator of injection, since it was generated closer to you than the real endpoint is. This is confirmation rather than something you need in order to act.

The remedy is at the protocol level: the classifier recognised something, so the answer is a transport that does not present what it recognised. Changing endpoint will not help, because the same classification will happen to the new one.

The hardest case to confirm is the connection that works but is too slow to use, because it is indistinguishable from ordinary congestion without a control measurement.

1. 1

   Measure the tunnel

   Run a throughput test through the tunnel and record the number, ideally several times over a few minutes.

2. 2

   Measure without it, at the same moment

   Run the same test directly. A large gap that persists across repeated tests is the first piece of evidence.

3. 3

   Look at the shape, not just the number

   Throttled flows characteristically start fast for a second or two — before the classifier has decided — and then settle to a low and unusually stable rate. Real congestion fluctuates. Stability at a low rate is the tell.

4. 4

   Try a different port and a different endpoint

   If the ceiling follows the protocol regardless of endpoint, it is classification-based shaping. If it follows the endpoint, it is more likely a capacity problem at that endpoint.

The single most informative test costs nothing: try the identical configuration on a different network — mobile data instead of Wi-Fi, or a different Wi-Fi network entirely.

• Works on one network and not another: the policy belongs to the network, not to your device, your configuration or the endpoint. Nothing on your side needs fixing.
• Fails on every network: the endpoint, the configuration or the credentials are the problem, and that is where to look.
• Works on both but is slow on one: that network is shaping, rather than blocking.

Filtering policy changes over time, and the same symptom can have a different cause three months later. A few lines noting the date, the network, the symptom, what you changed and the result turns each incident into something you can reason from, rather than starting the same investigation again from scratch.