如何判断究竟是什么在封锁你的连接

连接失败的方式本身就有诊断价值。在动手做任何事之前，先把你看到的现象与这张表对照一下。

DNS 操纵是最廉价的封锁方式，因而也最常见，同时也是最容易确认或排除的。方法是向两个不同的解析器问同一个问题，然后比较答案。

1. 1

   问你所在网络的解析器

   不带其他参数地运行 `nslookup example.com`（Windows）或 `dig example.com`（macOS 和 Linux），让它使用网络分配给你的那个解析器。

2. 2

   直接问一个公共解析器

   运行 `nslookup example.com 1.1.1.1` 或 `dig @1.1.1.1 example.com`。这会绕过网络自己的解析器——前提是出站 DNS 根本被允许。

3. 3

   比较两个答案

   地址不同、返回 0.0.0.0 或 127.0.0.1、或者一边返回 NXDOMAIN 而另一边给出有效答案，都表明存在拦截。答案一致则可以排除 DNS。

4. 4

   如果第二个查询也失败或返回同样错误的答案

   那么网络很可能把所有 53 端口的流量都重定向到了它自己的解析器，这很常见。对策是加密 DNS（DNS-over-HTTPS 或 DNS-over-TLS），如今多数操作系统都已原生支持。

要清楚修好 DNS 能带来什么。它给你一个正确的地址。至于你是否被允许到达那个地址，它毫无作用；而且紧接着的 TLS 握手中，主机名还会再一次以明文被发送出去。DNS 问题和连接问题是两码事，两者同时存在也很常见。

如果域名解析正确但什么都连不上，下一个问题就是：是地址不可达，还是你想对它做的那件事被拦住了。这两者在应用层面看起来一模一样，在命令行里却很容易区分。

1. 1

   用一个纯 TCP 连接测试端口

   在 macOS 或 Linux 上：`nc -vz <地址> 443`。在 Windows 上：`Test-NetConnection <地址> -Port 443`。这只打开一个裸 TCP 连接，别的什么都不做。

2. 2

   解读结果

   如果 TCP 连接成功，说明地址和端口是可达的，问题出在你在其之上所说的协议——过滤器把流量分类了。如果 TCP 本身就失败，说明地址或端口被整个封掉了。

3. 3

   在同一地址上测试第二个端口

   如果 443 失败而另一个端口成功，说明封锁是针对端口的。如果所有端口都失败，说明被封的是地址。

4. 4

   测试另一个端点

   如果用同样的设置和同样的协议，另一个地址能用，那么第一个地址已被列入封锁名单，再怎么调协议也救不回来。

这个区分是本指南中最有价值的东西。地址被封，需要换一个端点。协议被封，需要换一个协议或传输方式。用错药方，会让问题看起来无解。

能建立、过了一点流量、然后骤然死掉的连接，和压根建立不起来的连接是不同的特征。这通常意味着过滤器需要先看到一些字节才能分类这条流，随后通过伪造一个看似来自对端的 TCP 重置把它杀掉。

• 它可复现且迅速——通常在一两秒内，而且每次都在同一个点上。真正的故障则杂乱无章。
• 对端对此一无所知。从服务器的角度看，客户端就是消失了。
• 它的时机取决于握手而非流量大小：传更多数据并不会让它提前发生。

如果你手边有抓包工具，那么同一条流中某个重置包的 TTL 值与其他包明显不同，就是注入的有力证据，因为它是在比真实端点更靠近你的地方生成的。这是佐证，而不是你采取行动所必需的。

解法在协议层面：分类器认出了某样东西，因此答案是换一种不呈现那样东西的传输方式。换端点没有用，因为对新端点同样会发生同样的分类。

最难确认的情形，是连接能用但慢到无法使用——因为没有对照测量的话，它与普通拥塞无从区分。

1. 1

   测量隧道

   通过隧道跑一次吞吐量测试并记录数值，最好在几分钟内多测几次。

2. 2

   在同一时刻测量不走隧道的情况

   直接跑同样的测试。反复测试都持续存在的明显差距，就是第一条证据。

3. 3

   看形态，而不只是看数字

   被限速的流有一个典型特征：开头一两秒很快——那是分类器还没作出判断的时候——随后稳定在一个低而异常平稳的速率上。真正的拥塞是波动的。低速率下的平稳，就是那个破绽。

4. 4

   试另一个端口和另一个端点

   如果这个上限不管换哪个端点都跟着协议走，那就是基于分类的整形。如果它跟着端点走，那更可能是那个端点的容量问题。

信息量最大的测试不花一分钱：把完全相同的配置放到另一个网络上试——用移动数据代替 Wi-Fi，或者换一个完全不同的 Wi-Fi 网络。

• 在一个网络能用、另一个不能：策略属于那个网络，而不属于你的设备、配置或端点。你这边没有什么需要修的。
• 在所有网络都失败：问题出在端点、配置或凭据上，该往那里查。
• 两边都能用但其中一边很慢：那个网络在做整形，而不是封锁。

过滤策略会随时间变化，同样的症状三个月后可能有不同的成因。用几行字记下日期、网络、症状、你改了什么以及结果，就能把每一次事件变成可以据以推理的材料，而不必每次都从头再查一遍同样的东西。