← 学习库2026.09.21 · 关系先行

代理网络：跟着一条请求，把关系看明白

图解 · Pages 原生结构图 一条“生成文字”的请求：谁发起，谁转送，谁办理？

沿箭头看一种选用代理的路径；它画的是各处职责，不是术语目录。

① 你用的工具

发起要求：“请生成一句介绍。”先确定它在你的电脑，还是远程机器上运行。

② 本机代理

接住交给它的请求，再按选择或规则决定怎么转送。它没收到的请求，不受站内规则安排。

③ 远处中转机

接力搬运通信。租来的服务器只是能运行程序的电脑，不会买来就自动完成转送。

④ 最后出面的出口

从这里向目标建立最后一段连接。判断出口地址，要站在目标这一端看来源。

⑤ 对方的业务窗口

收到要求后办理：可能返回文字，也可能回复“凭证无效”。收到回复不等于取得结果。

结论：中间几处负责送达，最后的业务窗口决定怎么办。请求送到了，不等于事情办成了。

边界：中间三个位置不是必需；直接访问可不经过它们，多个角色也可在同一台机器。图示只讨论转送，不表示中间处都能解密正文。

先看谁发起、谁转送、谁办理。再把 Socket、DNS、TUN、路由和 API 放回各自的位置。

Socket 和五元组代理开关为何不管用HTTP 与 API 的关系直接开始排障

这页只沿着“工具发出一条请求，最后拿到结果”这件事展开。正文先让你能在脑中走通，再给必要名称；内部实现留到需要时。所有地址、时间、价格和合同都是教学设定，不是个人记录、实测或商家报价。

U01 · A代理开在电脑上，为什么服务器里的任务没变化？

你坐在笔记本前，让远处的电脑下载一个文件。鼠标和键盘在你手边，但真正去下载的是远处那台电脑。像你打电话请朋友去买东西：改变你自己的出门路线，不会自动改变朋友的路线。先找“谁真的出发”，再谈改哪个设置。

名字与本质

客户端：这次主动办事的程序
谁发出这次请求，谁就是这段通信的客户端。它不一定在你的电脑上。运行该程序的设备。 例如：本机浏览器；远程服务器上的下载工具。
代理：请中间程序代转
程序先把通信交给它，再由它转给目标。是否使用它，要看这次请求的实际路径。可以在本机，也可以在远处。 例如：浏览器 → 本机代理 → 目标网站。

让它实际走一遍

浏览器在笔记本上运行，并且会读取笔记本的代理设置。你想让它通过代理访问一个测试网页。

  1. 在笔记本上设置代理，浏览器读取这个设置。
  2. 浏览器发出一条新请求，查看代理里是否出现对应记录。

谁实际发请求，就先检查谁读取的设置。

操作位置 ≠ 执行位置

换个场景，照样能用

网页前端在浏览器运行，后台任务在服务器运行。两者访问同一个服务，也可能需要分别设置。

知识怎么接起来：位置找对后，U02 再解决：同一台机器同时发很多请求，怎样分清各条通信？

在自己的环境中验证

在实际执行任务的那台机器上看程序设置，再发一次无敏感内容的测试请求。

只改一个条件，你来判断

改变：把下载任务放到远程服务器执行。

其余保持：下载目标不变；只改过笔记本设置；远程程序没有同步这些设置。

问题：远程下载会仅仅因为你开了本机代理就改道吗？为什么？

另选一个问题

依据：curl

U02 · ASocket、连接、五元组：接听口、通话，还是通话标签？

先想一个能同时接待多位来电者的客服系统。它需要一个持续等新来电的接听口，也需要为每一通已接通的电话分别收发声音。接听口不能因为接了第一通电话就消失，否则第二个人就打不进来了。这里借“通话”解释关系，不是在说网络里真的有电话机。

名字与本质

Socket：程序收发数据用的通信对象
先把它想成程序手里的通信口。等待新连接的口叫监听 Socket；接通后收发这一次通信的口叫已连接 Socket。由本机操作系统管理，程序使用它。 例如：一个等来电的口，旁边可以有多个各管一通的口。
IP 与端口：地址与编号
IP 是网络地址；端口是设备上区分通信入口的数字。这里的“门牌”必须连着地址看。记录在通信两端。 例如：192.0.2.20:7890 表示这个地址上的 7890 号入口。
五元组：这段通信的五项标签
来源地址、来源端口、目标地址、目标端口、使用的传输协议。协议就是双方约定的传送办法，本例用 TCP。标签描述通信，不替程序收发数据。看同一时刻、同一网络位置的一段通信。 例如：192.0.2.10、52000、192.0.2.20、7890、TCP。
等新来电

监听 Socket
只确定本地接待口，未固定某一个来电者。

接通 A / 接通 B

两个已连接 Socket
分别收发；各有自己的双方地址与端口。

给每段通信贴标签

五元组
是描述信息，不是第三种“通话设备”。

让它实际走一遍

教学地址：代理在 192.0.2.20 的 7890 号入口等待。程序 A 从 192.0.2.10 的 52000 号端口连来；本例不考虑中途改写地址。

  1. 等待口继续等新连接，同时创建一个已连接 Socket，专门与 A 收发数据。
  2. 从 A 到代理这一方向，五项标签是：192.0.2.10 / 52000 / 192.0.2.20 / 7890 / TCP。
  3. 五项标签能描述这段通信，但不包含待发送的数据等内容。像通话记录上的双方号码，并不是实际处理通话的设备。

Socket 是做事的通信对象；连接是两端之间的一次关联；五元组是描述这段关联的标签。

通信对象 ≠ 通信标签；一个等待口 → 多个已连接通信口

换个场景，照样能用

一千人访问同一个网站的 443 端口，不需要网站给每人另开一个公开端口。网站会分别管理连接。

知识怎么接起来：U17 会接着用这五项标签解释：多台设备共用一个公网地址，回复为什么不会混在一起？

在自己的环境中验证

在自己设备上查看连接列表，找两条目标端口相同、来源端口不同的记录；无须先学程序内部句柄。

只改一个条件，你来判断

改变：再来一个程序 B：192.0.2.11:53000。

其余保持：同一个代理、同一个 7890 入口；A 仍连接着。

问题：代理需要换一个接待端口，才能区分 A 和 B 吗？请指出标签里可区分它们的部分。

另选一个问题

依据：tcpsocket

U03 · A知道网站地址，为什么还要报网站名字？

你要找一家店。名字方便记，地址方便送达，但几家店可以共用一个接待地址。到了那里仍要说“我找哪一家”。因此，“找地址”和“报名字”不是重复劳动。这比“前台拿配置”更具体：我们要解释的是为什么地址不能唯一确定网站。

名字与本质

域名、IP、DNS：名字与找地址
域名是网站名字；IP 是网络地址。DNS 提供名字对应的地址等记录，像查地址簿，不负责替你运送正文。查询可发生在本机或代理一侧。 例如：api.example.com 是教学域名。
SNI：安全连接开始时先报网站名
同一接待地址承载多个网站时，客户端可提前说明要找哪个，接待方据此选择网站的身份证明。在建立 TLS 安全通信时；TLS 负责加密与身份检查。 例如：“我要找 api.example.com”，不是“我的登录账号是……”。
证书：网站出示的身份证明
客户端用它检查对方是不是自己要访问的网站。不是你交给网站的账号密码。网站向客户端提供，客户端检查。 例如：网站证书与 API 访问凭证是两个方向的证明。

让它实际走一遍

教学设定：book.example.com 和 shoe.example.com 共用 192.0.2.20，接待方分别持有相应证书。你访问卖书的网站。

  1. 先得到 192.0.2.20 这个地址。
  2. 连接开始时说明要找 book.example.com，接待方选择相应证书。
  3. 随后 HTTP 请求还会说明访问哪个网站、办理什么事。不是把所有网站名都藏在 IP 里。

名字到地址可能是多对一；只知道地址，不足以反推出你要找哪个网站。

多个网站名 → 同一个地址；同一个地址 ↛ 唯一的网站名

换个场景，照样能用

换了 DNS 可能改变查到的地址，但不等于自动换了最终出口；这两件事在 U13、U19 分开检验。

知识怎么接起来：U25 会把“找到地址、接通、安全检查、业务回复”放回一次实际请求。

在自己的环境中验证

访问自己管理的测试域名时，同时核对域名、解析地址和证书中的网站名；不要靠关闭证书检查排障。

只改一个条件，你来判断

改变：改为访问卖鞋的网站。

其余保持：地址仍是 192.0.2.20；两个网站与证书配置不变。

问题：除了共用地址，还需要改变哪项目标信息？

另选一个问题

依据：dnssnihttp

U04 · A192.0.2.0/24 到底表示一个地址，还是一批地址？

配送员不会给每户都写一条“怎么走”；他可以写“这个小区都走东门”。网络也需要一次描述一批地址。192.0.2.0/24 就是一张划定范围的清单，不是一台特别的服务器。

名字与本质

地址前缀 / CIDR：用共同开头圈定地址集合
IPv4 地址有 32 位。/24 表示前 24 位固定，剩下 8 位可以变化；因此这个例子覆盖 192.0.2.0 到 192.0.2.255。用于路由、访问范围等配置。 例如：这里只判断是否属于集合，不讨论哪些地址适合分给设备。

让它实际走一遍

配送范围是 192.0.2.0/24，待查地址是 192.0.2.10。

  1. 该 /24 固定了 192.0.2 这三个数，最后一个数可变化。
  2. 192.0.2.10 落在范围里。/24 有 2 的 8 次方，即 256 个地址。

先把网段理解为地址集合，再做“在不在里面”的判断。

192.0.2.0/24 ⊂ 192.0.0.0/16；固定越多，范围越小

换个场景，照样能用

“只允许办公室网段访问”与“某一批地址走代理”，都先用这种集合表示范围。

知识怎么接起来：U05 用“大范围与小范围”的包含关系解释默认路由为什么不一定胜出。

在自己的环境中验证

使用本页的离线 Python 实验判断成员关系，不需要连接示例地址。

只改一个条件，你来判断

改变：待查地址换成 192.0.3.10。

其余保持：范围仍是 192.0.2.0/24。

问题：新地址还属于这批地址吗？

另选一个问题

依据：routingiana

U05 · A默认路线写着 Wi-Fi，为什么请求却走虚拟接口？

配送规则写着“其他地址走东门”，又单独写了“2 号楼走西门”。送往 2 号楼时，不能拿“默认东门”来否定那条专门安排。操作系统选路也常这样：先看有没有更具体的目的范围。

名字与本质

路由表：去哪些地址，该交给哪一站
像一张目的范围到下一站的安排表。默认路由是没有更具体安排时的兜底。由操作系统或路由器使用。 例如：0.0.0.0/0 代表全部 IPv4 地址。
网络接口：数据交出去的口
可以是真实网卡，也可以是交给软件处理的虚拟口。接口名是标签，不是直连或代理的保证。本例 en0 是 Wi-Fi 所用物理口，utun7 是虚拟口。 例如：下一跳是接下来接手的站，不一定是最终网站。

让它实际走一遍

只看这一张简化路由表：所有地址走 en0；其中 192.0.2.0/24 单独走 utun7。目标是 192.0.2.10。

  1. 目标同时属于“所有地址”和“192.0.2.0/24”。
  2. 选更具体的 /24，所以交给 utun7。默认项仍在，只是这次没有选它。

在本例的目的地址路由表里，匹配范围越具体，越优先。

先筛出包含目标的集合 → 选其中前缀最长的一项

换个场景，照样能用

代理退出后仍断网时，先检查到具体目标的路线是否还指向失效虚拟口，不要只看 Wi-Fi 是否连上。

知识怎么接起来：U09 会对比另一种选法：代理规则通常按列表先后执行，不能照搬本课算法。

在自己的环境中验证

macOS 只读查看 route -n get 192.0.2.10；看 interface 和 gateway，不需要删除任何路由。

只改一个条件，你来判断

改变：删除那条 /24 专门安排。

其余保持：目标不变；只剩原来的默认路线，没有其他选路规则。

问题：现在交给哪个接口？

另选一个问题

依据：routingtun

U06 · B关了“系统代理”，为什么流量还经过代理软件？

有两种改道办法：一是告诉司机“先去中转站”；二是在路口设置引导，把经过的车送往中转站。撤掉给司机的通知，不等于拆掉路口引导。系统代理和 TUN 就是在不同位置影响路径。

名字与本质

系统代理：给应用看的转送设置
愿意读取这个设置的应用，会按它把请求交给代理；不是每个应用都会读。系统设置提供，应用选择是否采用。 例如：浏览器可能采用，某个命令行工具可能只读自己的参数。
TUN：把匹配的数据交给软件处理的虚拟口
配合路由，把本来要发出去的数据引到代理程序。它不是靠每个应用主动读取系统代理设置。操作系统选路与代理程序之间。 例如：目标路线指向正在工作的 utun7。

让它实际走一遍

一个下载工具不读系统代理，但它发出的数据被当前路由交给工作的 TUN。

  1. 下载工具按自己的方式发起访问。
  2. 系统按路由交给 TUN，代理程序接手；起作用的是这一条路径。

“应用读不读设置”和“系统把数据交给谁”是两件事。

应用主动交给代理 ≠ 系统通过虚拟口接管

换个场景，照样能用

“浏览器能用、终端不能用”时，先比较两者怎么接入代理，比先买新节点更直接。

知识怎么接起来：U08 再看：请求交到代理以后，Global、Rule 和 Direct 才决定怎么送。

在自己的环境中验证

分别查看系统代理状态、目标路由和该次请求日志；一次只检查或改变一项。

只改一个条件，你来判断

改变：只关闭系统代理。

其余保持：TUN、路由、下载工具都不变。

问题：这能让本例的下载绕开 TUN 吗？

另选一个问题

依据：tunmodecurl

U07 · B经过 Wi-Fi 网卡，怎么还算用了代理？

快递在你家被交给中转员，中转员总得通过真实道路把它送走。你看到运输车开上公路，不能据此说“没经过中转”。虚拟接口负责接手，物理网卡负责真正出设备，它们不是二选一。

名字与本质

原始访问与搬运它的通信
前者是应用想访问网站；后者是代理程序为转送数据而建立的另一段通信。同一台电脑上，可以同时看到两种记录。 例如：应用目标是网站；代理外发的目标可能是远处中转机。

让它实际走一遍

应用的数据先进入 utun7。本机代理再通过 en0，连接远处的代理机器。

  1. 第一段回答“应用要访问谁、谁先接手”。
  2. 第二段回答“本机代理怎样联系远处机器”。它使用真实网卡很正常。

判断是否经过代理，要看接手者和目的地，不是只看网卡名。

应用 → 虚拟口 → 代理程序 → 物理网卡 → 远处机器

换个场景，照样能用

还要避免中转员把自己准备发出的包又交回自己：代理外发被重复接管，可能形成循环。

知识怎么接起来：U19 会沿着多段通信继续追问：最终网站看到的是哪一段的来源？

在自己的环境中验证

对照代理记录中的远端地址和系统连接列表；不凭 utun 编号猜具体软件。

只改一个条件，你来判断

改变：把观察位置从应用这一段换到代理外发那一段。

其余保持：同一次访问、同一套配置，没有改变路径。

问题：看到 en0，就能推翻“这次用了代理”吗？

另选一个问题

依据：tundialer

U08 · B都选了“全局代理”，为什么某个程序仍没走它？

转运站贴着“收到的所有包裹都交给 A 车”。这句话管的是进站包裹；一个压根没进站的包裹，不会因为站内告示就自动到 A 车上。代理软件里的“全局”，首先是在说它收到的通信怎么处理。

名字与本质

入站与出站：怎么进来、接着怎么走
入站是接收入口，出站是发送选择。两个名字对应两个先后不同的问题。代理程序内部。 例如：本地端口接进来，再选择远处节点或直接发送。
Global / Rule / Direct：进站后的三种安排
全局交给指定策略；规则模式逐条选；全局直连按直连策略送出。DIRECT 指当前代理不借所选远端节点来转送。对已经交给该代理处理的通信生效。 例如：在该代理之外，仍可能另有其他转送设置。

让它实际走一遍

某请求已进入本机代理；Global 选择节点 A。

  1. 先确认该请求有对应的入站记录。
  2. 代理按 Global 把它交给 A。先有“进来了”，才有“怎么发”。

接管范围与出站选择分开检查：先问有没有进站，再问坐哪辆车。

已接管的请求集合 ⊆ 设备发出的请求集合

换个场景，照样能用

服务器里开了代理面板，也不意味着该服务器上的每个程序都会自动使用它。

知识怎么接起来：U09 接着把“规则模式”展开成一条可以手算的选择过程。

在自己的环境中验证

找这一条请求的代理记录；看不到时先核对程序、时间和日志范围，不立即下结论。

只改一个条件，你来判断

改变：让这个程序绕过本机代理入口。

其余保持：代理仍是 Global，节点 A 仍可用。

问题：还能仅凭 Global 开关断定该程序经过 A 吗？

另选一个问题

依据：modetun

U09 · B域名规则更具体，为什么反而没有生效？

这里不是“选最精细的配送范围”，而是“从上到下问，第一条答是就停”。如果第一条已经写了“example.com 及其子网站都交给 A”，下面再写“api.example.com 直送”就来不及了。

名字与本质

代理规则：按顺序检查条件
本课以 mihomo 为例，从上往下选首先匹配的一条。代理核心，不是操作系统的目的地址路由表。 例如：DOMAIN 匹配完整域名；DOMAIN-SUFFIX 匹配该域名及其子域名。
MATCH：最后的其他情况
前面都没匹配时的兜底。PROXY 等组名是用户起的名字，不是固定的一台机器。规则列表最后。 例如：MATCH,PROXY 表示其余交给 PROXY 组。

让它实际走一遍

顺序是：① api.example.com 直连；② example.com 及子域名交给 A；③ 其余交给 A。访问 api.example.com。

  1. 第一条已经匹配，选择直连。
  2. 虽然第二条也能包含这个域名，但它不再决定本次选择。

先确认谁在选路：系统路由看前缀，代理规则看自己的匹配顺序。

列表顺序决定先后；“更具体”不自动插队

换个场景，照样能用

“绕过局域网”或“国内直连”最终也要看实际规则与兜底，不是看按钮名字。

知识怎么接起来：U10 再看：规则选中了一个节点组以后，组里怎样决定具体用哪个节点？

在自己的环境中验证

查看一次请求命中的具体规则名称。修改前保存原配置，不同时改节点和顺序。

只改一个条件，你来判断

改变：交换前两条的位置。

其余保持：域名、规则内容、节点 A 都不变。

问题：现在会选直连，还是 A？

另选一个问题

依据：rules

U10 · B自动测速第一名，为什么用起来不一定最快？

一辆车去便利店最快，不代表去机场也最快。测速总有一个终点；换了终点，原排名不能原封不动搬过去。把“延迟 40 毫秒”补成“谁到哪个测试地址，测了什么”，含义才完整。

名字与本质

节点组：几个可选转送方案
手选由你决定；URL-Test 依据指定网址的探测结果选；Fallback 在当前选择不可用时按顺序找可用方案。代理软件的节点组。 例如：自动选择不等于理解你所有业务的实际体验。

让它实际走一遍

教学测量：A 到测试网页 40 毫秒，B 为 70 毫秒。忽略容差等细节，自动组因此选 A。

  1. 这组数据比较的是同一个测试网页。
  2. 只对这个测量说 A 更快；尚未测你真正要调用的业务。

没有脱离测试对象的“最快节点”。

目标不同 → 要比较的数据也可能不同

换个场景，照样能用

AI 文本开始得慢，可能与排队有关。只测小网页，无法覆盖这段等待。

知识怎么接起来：U29 会把“收到回复”与“真正开始出字”分开计时。

在自己的环境中验证

先读自动组使用的测试网址，再用获授权的实际业务低频比较成功率和首内容时间。

只改一个条件，你来判断

改变：业务目标换成另一个服务。

其余保持：测试网页和 40、70 这两个数据不变。

问题：这些数字能证明 A 对新业务仍然更快吗？

另选一个问题

依据：urltestfallback

U11 · B198.18 开头的地址，是我的公网出口吗？

餐厅给你 8 号取餐牌，是为了稍后把餐交对人；它不是你家的地址。代理也可能给网站名分配一个内部代号，让后来的通信能对应回那个网站。看见一个地址样子的数字，先问它在这条记录里担任什么角色。

名字与本质

Fake-IP：给域名用的内部代号
代理保存“域名 ↔ 合成地址”的对应关系，后续看到合成地址就能找回相关域名。代理的解析与对应表。 例如：example.com ↔ 198.18.0.8。
198.18.0.0/15：特殊用途范围
登记用途是网络基准测试；一些代理借它做虚拟地址。它不是公网住宅地址证明，也不是常见三段私有地址之一。必须结合字段和配置理解。 例如：出现在 gateway 栏时，记录的是下一站，不是域名映射。

让它实际走一遍

教学日志明确写着：example.com 对应 198.18.0.8。

  1. 查域名时拿到这个内部代号。
  2. 后续通信交到代理后，可以借对应表找回 example.com；此时还没有观察最终出口。

内部代号、下一站地址、最终出口，长得相似但用途不同。

代号 ↔ 域名；代号 ≠ 目标看到的来源地址

换个场景，照样能用

检测网站回显的公网来源，与本机日志里的 198.18 代号不一样，并不自动构成故障。

知识怎么接起来：U13 会继续追问：查名字这一步究竟发生在你这边，还是代理那边？

在自己的环境中验证

分别查看域名解析记录和路由记录，不把虚拟网关拿去当公网出口检测。

只改一个条件，你来判断

改变：只留下“gateway: 198.18.0.1”这一条路由记录。

其余保持：没有域名查询日志，也没有对应表。

问题：能仅靠这条记录证明 example.com 被分配了 Fake-IP 吗？

另选一个问题

依据：ianamihomo-dns

U12 · B代理替我送 HTTPS，能读到里面的文字吗？

想象你把锁好的盒子交给搬运员。搬运员知道送到哪里，也能看到盒子多大，但不因此拥有开锁钥匙。关键不是“经过了谁”，而是“谁负责解开这层保护”。这个比方只用于理解加密关系，不代表所有流量都天然加密。

名字与本质

HTTPS / TLS：保护这次对话
HTTPS 是通过 TLS 安全通信传送 HTTP；TLS 提供加密和对方身份检查。要看安全通信的两端是谁。 例如：客户端与目标网站之间的保护。
CONNECT：请代理打通一条转送通道
HTTP 代理收到目标主机和端口后，建立连接并转送数据。普通 CONNECT 不等于代理解密网站正文。客户端与 HTTP 代理之间的约定。 例如：先告诉代理“连到 example.com 的 443”。

让它实际走一遍

普通 CONNECT 转送；客户端正确检查网站证书；没有受信任的中间解密设备。

  1. 代理替客户端建立到目标的转送通道。
  2. 客户端与网站建立自己的 TLS 安全通信，正文以加密形式经过代理。

转送数据的人，不一定是能解开数据的人。

能转送加密数据 ↛ 能读懂正文

换个场景，照样能用

网站前方的反向代理可能被网站授权解密，这与普通中转员只搬运加密数据不同，见 U18。

知识怎么接起来：U25 再把“安全通信已建立”与“业务愿意办理”区分开。

在自己的环境中验证

核对代理类型和浏览器证书；不要为了让测试通过而关闭证书校验或随意安装证书。

只改一个条件，你来判断

改变：再给“客户端到代理入口”这一段也加上 TLS。

其余保持：里面那层网站 TLS 的两端与证书检查方式不变。

问题：代理解开外层后，会因此读懂里面的网站正文吗？

另选一个问题

依据：httptls

U13 · B查网站地址，到底由我查还是代理查？

请朋友去一家店，有两种说法：“去这个具体地址”，或“帮我找到这家店再过去”。第一种是你先查地址，第二种把查找也交给朋友。代理转送时，这个分工同样重要。

名字与本质

SOCKS5：把连接目标交给代理的一种约定
可以交给代理一个 IP，也可以交给它一个域名，让它处理目标查找。使用它的客户端与代理之间。 例如：具体谁查地址，取决于客户端选项。
curl 的 socks5 与 socks5h
curl 是发起网络请求的命令行工具。在它的代理地址写法中，socks5 让本地查目标地址，socks5h 把目标域名交给代理。h 不是新的 SOCKS 版本。curl 的 --proxy 选项。 例如：代理入口先写 127.0.0.1:7890，避免把入口查找也混进来。

让它实际走一遍

curl 经 socks5://127.0.0.1:7890 访问 example.com；没有缓存，入口支持 SOCKS5。

  1. curl 这边先查 example.com 的地址。
  2. 然后把查到的目标地址交给代理连接。

“用了代理”和“由代理查目标地址”是两件事。

我查好地址再交给代理 / 我把名字交给代理查

换个场景，照样能用

加密 DNS 像把查地址的对话加锁；它本身不等于把查找地点搬到别处。

知识怎么接起来：U24 用同一个道理检查：网页、DNS、实时通信是否都被你测过。

在自己的环境中验证

在自己的可控测试环境里比较两种写法的日志，不把一次成功自动解释为所有 DNS 都经过同一路径。

只改一个条件，你来判断

改变：把代理地址写法改成 socks5h://127.0.0.1:7890。

其余保持：目标、代理、客户端不变；代理支持域名目标。

问题：现在“目标网站在哪里”这件事交给哪边处理？

另选一个问题

依据：curl-sockssocks

U14 · B网页能开，为什么实时通信还是不通？

一家运输公司能送普通包裹，不代表它也接冷链货。两种货都到同一仓库，服务能力仍要分别确认。TCP 和 UDP 是不同的传送办法；验证了一种，不能顺手替另一种打勾。

名字与本质

TCP 与 UDP：两种传送办法
TCP 提供按顺序可靠交付的字节流；UDP 发送独立的数据报，不自带同样的可靠顺序保证，应用可另行实现。客户端、代理与目标都要支持所需办法。 例如：TCP 的 443 与 UDP 的 443 不是同一个完整通信入口。
HTTP/3 与 UDP 转送
HTTP/3 使用 QUIC，QUIC 基于 UDP。SOCKS5 规范有 UDP 转送能力，不代表你买到的产品一定开放。整条路径每一段的能力。 例如：浏览器可能改用别的方式，所以打开网页不自动证明使用了 HTTP/3。

让它实际走一遍

教学代理只支持 TCP；普通 TCP 网页访问成功。

  1. 已确认的是该网页通过 TCP 完成了访问。
  2. 代理并未因为一次成功自动增加 UDP 支持。

整条链可用的能力，要同时被需要经过的各段满足。

整条链的共同能力 = 各必要段能力的交集

换个场景，照样能用

链式代理任一必要段不支持业务所需能力，其他段支持也不能补齐这一缺口。

知识怎么接起来：U24 会把地址版本和实时通信也放进检查范围。

在自己的环境中验证

查看应用实际采用的协议与产品支持范围；固定是否允许自动回退。

只改一个条件，你来判断

改变：测试改为只允许 UDP 的通信。

其余保持：仍用同一代理；不允许回退到 TCP，也没有额外封装方案。

问题：之前的网页成功，足以保证这个测试成功吗？

另选一个问题

依据：socksquic

U15 · C一长串代理账号，哪些部分是地址，哪些是凭证？

预约接送要知道“在哪儿上车”，也要有“自己的订单号”。上车地点没变，订单内容却可以安排不同车辆。代理字符串也在同时表达多个问题，不能把整串都当成一个 IP。

名字与本质

入口地址、账号、会话标记
入口告诉程序去哪儿联系代理；账号凭证证明有权使用；有些产品用会话标记选择或保持出口。客户端配置给代理网关，网关按产品规则解释。 例如：socks5h://user:REDACTED@proxy.example:1080 是占位示例，不可直接连接。

让它实际走一遍

教学产品约定：同一账号用相同会话标记，在有效期内保持同一出口。入口始终是 proxy.example:1080。

  1. 入口地址只负责找到代理网关。
  2. 网关检查账号，再依据产品规则处理会话标记，决定从哪个出口转送。

入口、使用凭证、出口分配是三个角色。

找到网关 ≠ 获得使用权 ≠ 确定最终出口

换个场景，照样能用

同一网关可服务许多出口；检测入口的国家标签，不能替代检测你这次真正用的出口。

知识怎么接起来：U22 接着解释：相同会话标记的保持承诺能持续多久。

在自己的环境中验证

按服务商公布的格式检查；不要把真实密码放在网页笔记、截图、公开仓库或命令历史里。

只改一个条件，你来判断

改变：只换成另一个有效的会话标记。

其余保持：入口、账号、密码和产品规则不变。

问题：入口没变，就能保证出口也没变吗？

另选一个问题

依据：sockscurl

U16 · C云平台已经放行端口，外面为什么还连不上？

小区门卫允许访客进来，不代表楼里真的开着营业窗口。能否到达，至少要同时有“路径允许”和“有人在对应入口接待”。只打开云安全组，并不会启动程序，也不会把只对本机开放的入口搬到外面。

名字与本质

VPS：租来的远程电脑
它能运行程序，但“租到电脑”不等于“已经运行好代理服务”。云平台上的虚拟服务器。 例如：公网地址只是访问它的条件之一。
监听与防火墙：有人接待、允许经过
监听表示程序正在某个本地地址和端口等待；防火墙、安全组决定哪些流量允许经过。前者在服务程序，后者在主机或云网络。 例如：127.0.0.1 只指本机；0.0.0.0 用作绑定时表示所有本地 IPv4 接口，不是访问目标地址。

让它实际走一遍

程序只在 127.0.0.1:7890 接待，本机测试成功；没有端口转发。

  1. 本机能连上，说明本机入口确实有人接。
  2. 外部访客不能直接用这条仅面向本机的监听来访问服务。

放行道路，不会改变程序在哪里接待。

可访问需要：服务在正确入口接待，并且路径允许到达

换个场景，照样能用

管理面板、数据库、代理端口不是同一种服务。为了排障把它们全部公开，既无助于定位也扩大风险。

知识怎么接起来：U17 继续解释：即使路由器有公网地址，内部电脑也未必能被外部直接访问。

在自己的环境中验证

Linux 用 ss -lnt，macOS 用 lsof -nP -iTCP -sTCP:LISTEN 查看监听；不先把端口开放给全网。

只改一个条件，你来判断

改变：只在云安全组允许测试来源访问 7890。

其余保持：程序仍只监听 127.0.0.1，没有新增转发。

问题：现在外部就一定能直接连上了吗？

另选一个问题

依据：socketmode

U17 · C多台设备共用一个公网 IP，回复怎么分给正确的人？

公司只有一个总机号码，却能给很多分机转接。关键是总机保留了“这次来往属于谁”的记录。家里多台设备共用公网地址时，也会用地址和端口的对应记录，把回复送回正确设备。

名字与本质

NAT / 地址端口转换：代换外部地址并保存对应
常见家庭网络把内部地址和端口换成公网一侧的地址和端口，并记录两边关系。路由器或运营商网络设备。 例如：设备 A、B 可以同用一个公网 IP，但使用不同的外部端口。
端口转发与运营商共享地址
主动访问形成的临时对应，不等于外界随时能主动找进来。端口转发可安排固定外部入口；上层还有运营商转换时，家用路由器未必能控制它。每一层负责转换的设备。 例如：CGNAT 指运营商这一层的共享地址转换。

让它实际走一遍

两台教学设备都访问同一网站。路由器给 A 分配外部端口 61001，给 B 分配 61002，公网地址相同。

  1. 发出去时，路由器记下每个外部端口对应哪个内部通信。
  2. 回到 61001 的回复按记录交给 A；61002 的交给 B。不是只看公网 IP。

同一个公网 IP，可以承载多个设备、多条连接。

外部地址与端口 ↔ 内部地址与端口（对应记录要有效）

换个场景，照样能用

看到两个用户同一个 IP，不足以认定他们是同一个人；看到一个 IP，也推不出准确并发人数。

知识怎么接起来：这正是 U02 的用途：比较完整通信标签，而不是只看一个 IP。

在自己的环境中验证

先确认自家路由器与上级网络各有哪些地址、哪些设置由你控制，不盲目增加端口转发。

只改一个条件，你来判断

改变：删除 A 的对应记录，且没有重建。

其余保持：B 的记录与其他条件不变，没有额外静态转发安排。

问题：迟到的 A 回复，能只凭公网 IP 保证找到 A 吗？

另选一个问题

依据：nattcp

U18 · C正向代理、反向代理：到底是谁请来的帮手？

你请跑腿去很多商店买东西，他代表你；商店请接待员统一接单，再交给内部柜台，他代表商店。两者都在中间转交，但服务对象不同。不要靠机器叫 VPS，或软件叫 Nginx，来判断是哪一种。

名字与本质

正向代理：替来访者办事
客户端选择它，借它访问目标。客户端与外部目标之间。 例如：你的工具 → 你选的代理 → 不同网站。
反向代理：替服务方接待
外部访问服务的统一入口，入口再交给内部程序。服务方安排的接入位置。 例如：你的工具 → 网站入口 → 网站内部业务程序。

让它实际走一遍

一台远程机器按你的工具给出的目标，替你连接多个网站。

  1. 先看是谁选择这位中间帮手：是客户端。
  2. 它代表客户端访问外部目标，因此是正向代理角色。

代理角色看“替谁服务”，不是看装了哪个软件。

正向：替我去访问；反向：替网站来接待

换个场景，照样能用

一台机器可以承担多个职责。你的 API 转发站接待用户，与它随后访问外部服务，是可以分开讨论的两段。

知识怎么接起来：U19 沿着这两种职责，区分网络来源地址与转交的来源信息。

在自己的环境中验证

读配置中谁在连接入口、入口再交给哪些目标；需要时同时确认加密在哪一层结束。

只改一个条件，你来判断

改变：让同一台机器改为只接待自有网站，再转交内部服务。

其余保持：机器位置不变；按新职责判断。

问题：这个新职责属于正向还是反向代理？

另选一个问题

依据：http

U19 · C经过两级代理，网站最后看到哪个 IP？

你让 A 跑腿，A 又请 B 把东西送到店里。店员眼前最后来送货的是 B，不是 A。讨论出口地址，也要把观察位置放在目标接待处，而不是盯着自己最先联系的机器。

名字与本质

出口 IP：这段访问最后向目标呈现的来源地址
在指定目标接入处，观察到连接从哪个地址来。它不等于代理入口地址，也不等于用户账号身份。目标接入这一侧。 例如：工具 → 中继 → 出口 X → 目标。
转发头：另外写在请求里的来源说明
能处理 HTTP 内容的中间层可能传递来源信息；内容是否可信取决于服务方的信任设置。HTTP 请求中，例如 Forwarded。 例如：普通加密 CONNECT 中转不能随意往加密正文里加可读来源头。

让它实际走一遍

教学路径为工具 → 中继 → X → 目标；X 使用自己的地址建立目标连接；没有其他地址改写。只问网络连接的来源。

  1. 工具先把通信交给中继，中继再交给 X。
  2. 最终由 X 连接目标，所以目标接入处看到 X 的来源地址。

从目标这一端往回看，才能判断这次连接的出口。

入口 ≠ 中继 ≠ 最终出口；出口地址 ≠ 完整用户身份

换个场景，照样能用

改出口 IP 只改变一类网络观察。账号、凭证、请求内容、浏览器语言并不会因此一起改变。

知识怎么接起来：U20 会把“看到哪个地址”与“数据库说这个地址在哪儿”再拆开。

在自己的环境中验证

让同一个程序通过同一配置访问获授权的来源回显端点，对照日志；不用浏览器结果替服务器程序作证。

只改一个条件，你来判断

改变：把最后的 X 换成 Y。

其余保持：工具、中继、目标及观察条件不变。

问题：目标这次看到的连接来源是谁？

另选一个问题

依据：httpnat

U20 · D数据库写“美国”，机器就一定在美国吗？

一辆车的登记地、现在停放的地点、导航软件显示的位置，是三份不同信息。网络地址也有类似区别：资源登记是谁的，谁对外发布到达路线，机器部署在哪里，定位数据库又怎么标注，不能压成一个“国家”。

名字与本质

ASN / BGP：哪个网络、怎样对外告知路线
ASN 是一个网络的编号；BGP 是网络之间交换到达路线信息的办法。它们不直接给出某台服务器的街道地址。运营不同网络的组织之间。 例如：运营商名称像家宽公司，不代表这台机器接在某个家庭。
地理定位标签：数据库对地址位置的判断
它可能来自多种数据并会更新，准确程度并非处处相同。不同定位服务自己的记录。 例如：定位国家、资源登记国家和机房位置可能不一致。

让它实际走一遍

教学资料只有一条：数据库 D 把地址 X 标为美国。没有机器部署资料或线路测量。

  1. 可以记录“D 当前这样标注 X”。
  2. 不能凭这一条就画出机器的物理位置或跨国路线。

登记、网络路由、物理部署、数据库定位，要分开提问。

数据库里的位置 ≠ 已证明的机器位置

换个场景，照样能用

“香港机器加美国标签地址”是否成立，需要看实际网络部署，不能从一张查询截图补出整套架构。

知识怎么接起来：U21 用这些独立维度解释“ISP、住宅、静态、独享”为什么不是同一条等级链。

在自己的环境中验证

对照多个定位来源、服务商部署说明和带时间的路径测试，不靠单一标签确认物理位置。

只改一个条件，你来判断

改变：数据库把同一个地址的标签改成香港。

其余保持：没有新增机器搬迁证据，其他资料不变。

问题：这一变化能证明机器刚刚从美国搬到了香港吗？

另选一个问题

依据：bgpmaxmind

U21 · D“ISP、住宅、静态、独享”四个词，分别回答什么？

租房时，“房子归谁”“房子在哪”“每晚是否换房”“是不是只有你住”，是四个问题。代理产品的标签也不能互相代替：地址长期不变，不代表只有你一个客户在用；属于运营商，不代表设备一定在居民家里。

名字与本质

ISP / Residential / Hosting：来源或用途描述
ISP 是互联网接入服务商；住宅通常强调居民接入场景；Hosting 强调托管用途。商家和数据库用词并不完全统一。产品说明、网络资源与数据库。 例如：运营商地址可以被用于数据中心部署。
Static / Dynamic 与 Dedicated / Shared
静态或动态说多久变化；独享或共享说约定范围内有谁共同使用。看合同的分配与共享范围。 例如：静态共享、动态独享在逻辑上都不是自相矛盾。

让它实际走一遍

教学资料说：地址来源与某运营商有关，被标为 ISP；没有接入方式或共享条款。

  1. 知道了资源或数据库分类的一部分。
  2. 仍不知道是否真实家宽、是否独享、是否稳定。

这些是不同维度，不是从“机房”一路升级到“绝对安全”的等级。

是否变化 × 是否共享，是两条独立坐标轴

换个场景，照样能用

独享地址也不能自动保证性能、账号权限或目标平台认可。这些需要分别验证。

知识怎么接起来：U22 看时间稳定性；U23 看评分；U32 看采购合同与总成本。

在自己的环境中验证

把服务商答复落实成书面条款：独享到什么范围、何时换地址、故障怎么办；不要只问“是不是纯净”。

只改一个条件，你来判断

改变：新增一条说明：服务部署在数据中心。

其余保持：运营商来源与 ISP 标签不变。

问题：新说明一定与 ISP 标签矛盾吗？

另选一个问题

依据：maxmind

U22 · D用了同一个会话名，为什么 IP 还是会换？

保留座位的约定写着“保留十分钟”。你拿着同一个预约号，十二分钟后回来，不能只凭号码没变就认为承诺仍有效。会话标记也是选择参数，效力来自产品约定，不来自字符串本身。

名字与本质

会话保持 / Sticky Session
在规定的有效期与出口可用条件内，产品尽量或按合同保持分配。具体保证强度必须看产品说明。代理网关的分配规则。 例如：本题采用明确的十分钟保持保证，不代表任何真实商家条款。

让它实际走一遍

纯教学合同：同一会话标记、出口在线、创建后十分钟内，重复请求用同一出口。现在是第三分钟。

  1. 相同标记满足“同一会话”。
  2. 在线与有效期也满足，所以本题合同支持保持出口。

要记住的是带条件的承诺，不是“会话名相同所以永远不变”。

条件成立时有保证；条件不成立时，是未知，不是必然相反

换个场景，照样能用

“固定 IP”也要问租期、续费、故障替换与回收，不把一次测试当成永久合同。

知识怎么接起来：U32 把保持时长、退款范围和费用一起变成采购前要问清的问题。

在自己的环境中验证

在自己的正常使用中记录脱敏会话标记、时间和实际出口；同时查故障重分配条款。

只改一个条件，你来判断

改变：时间改为第十二分钟。

其余保持：会话标记、账号、入口与出口在线状态不变。

问题：还能用这条十分钟合同保证出口不变吗？

另选一个问题

依据：socks

U23 · D风险分是 0，为什么业务仍可能拒绝？

一个信用机构说“目前没发现这类问题”，不等于每家机构都承诺批准你的申请。不同检测站用的数据与打分方法可能不同；目标服务还有自己的权限与使用规则。一个分数不能替这些机构共同签字。

名字与本质

IP 风险或信誉评分
某个供应商依据自己掌握的数据给出的判断信号，不是全球统一的物理刻度。对应检测服务及其更新时间。 例如：0 分要连着供应商、评分定义和时间一起读。
网络能到与业务允许使用
请求能到达，只是通信条件；账户权限和业务规则还由目标服务判断。目标服务的接待与办理环节。 例如：外部检测站不拥有目标平台的最终决定权。

让它实际走一遍

教学检测站 D 给地址 X 打 0 分，目标 T 没有承诺采用 D 的评分。

  1. 可记录 D 的这次检测结果。
  2. 不能把它改写为“目标 T 必然允许使用”。

评分是一个来源的证据，不是全平台通行证。

检测站 D 的判断 ↛ 目标 T 的决定

换个场景，照样能用

采购时把“地址类别、真实速度、产品授权、评分”分开，不接受一张“全绿截图”代替合同。

知识怎么接起来：U25 会用 API 办事窗口的例子把“送到了”和“办成了”具体拆开。

在自己的环境中验证

遇到业务拒绝时读官方错误和支持说明，不用低风险评分替代账户权限与正常诊断。

只改一个条件，你来判断

改变：改用检测站 E，它给同一地址打 70 分。

其余保持：地址、目标和测试时刻不变。

问题：能证明这个地址的真实行为刚刚变坏了吗？

另选一个问题

依据：maxmindhttp

U24 · D出口检测通过一次，就代表整台电脑都通过了吗？

你试过一扇门的锁，不等于检查了整栋房子的所有门窗。一次网页回显只告诉你这一次网页请求从哪里来；另一种地址、查域名的通信、音视频通信，可能是另一个需要检查的入口。

名字与本质

IPv4 与 IPv6：两套地址与选路体系
只验证一种，不等于验证另一种。应用、系统路由和代理支持范围。 例如：网站可能提供两类地址。
DNS 与浏览器实时通信
DNS 负责查名字；WebRTC 用于浏览器音视频等实时通信，会涉及发现可用通信路径。它们不是一次普通网页回显的同一项测试。可能由不同组件与路径处理。 例如：没有测到，先写“未测”，不直接写“泄漏”。

让它实际走一遍

浏览器的一次 IPv4 网页请求显示出口 X。没有其他测试。

  1. 可以给“这个浏览器的这次 IPv4 请求”记一条证据。
  2. 不能替 IPv6、DNS、音视频或远程服务器程序一起打勾。

测试结论的范围，不能比实际测试的范围大。

已验证的通信范围 ⊆ 需要验证的通信范围

换个场景，照样能用

改服务器时区不会改变网络路线；改浏览器语言也不是改变 IP 物理位置的办法。

知识怎么接起来：U31 会把“我测了什么”整理成一条可以复查的排障记录。

在自己的环境中验证

在自己的设备与授权目标中分别核对所需路径；避免在公开页面粘贴完整地址和账户记录。

只改一个条件，你来判断

改变：另一次连接改用 IPv6。

其余保持：浏览器和配置不变；尚未测试 IPv6 路径。

问题：之前的结果足以确定这次还是 X 吗？

另选一个问题

依据：webrtctuncurl

U25 · E能 Ping、能收到回复，为什么 API 仍不能用？

把 API 想成办理某项业务的窗口。你请它“生成一句介绍”。有三种完全不同的情况：根本联系不上；窗口回复“凭证无效”；对方接受并返回了介绍。第二种已经收到回复，却仍没办成。此时继续换路线，未必能解决凭证问题。

名字与本质

HTTP：请求与回复的表达约定
像规定申请单和回执怎样写，允许表达成功，也允许表达拒绝或错误。客户端与服务的 HTTP 通信。 例如：401 可表示缺少有效认证凭证；403 表示服务拒绝履行请求。
API：软件对外办理业务的约定
不只是入口，还规定接受什么要求、做什么、返回什么。本课讨论通过 HTTP 访问的 API。服务的业务接口。 例如：生成文字窗口接受输入与有效凭证，返回内容或错误。
Ping：另一种探测，不是办事前必经的一关
它通常用 ICMP 回显消息探测对方是否回复；与业务用的 TCP、TLS、HTTP 不是同一项测试。探测程序发出，目标或网络可单独限制。 例如：Ping 不回也可能能访问网页；Ping 回了也可能连不上业务端口。
路与通话

地址、选路、建立通信
解决“能不能联系”。

申请单与回执

HTTP
解决“怎样表达请求和回复”。

办事窗口

API
解决“接受什么要求、办理什么、交付什么”。

让它实际走一遍

教学服务已建立安全连接，收到生成文字请求，但访问凭证无效；它按设计回复 HTTP 401。

  1. 收到这份回复，说明已有某个 HTTP 服务回应了本次请求。
  2. 回复内容表示缺少有效凭证，生成任务没有成功。先核对回应来自哪一层，再检查凭证和权限。
  3. 与之不同，连目标端口都连接超时，才是更靠前的通信问题。不要用一种错误覆盖另一种。

送到了、愿意办理、拿到可用结果，是不同的判断。

拿到所需结果 ⇒ 收到相关回复；收到回复 ⇏ 拿到所需结果

换个场景，照样能用

“余额不足”“输入缺项”“内部服务暂不可用”都可能收到 HTTP 回复。不能把它们统称为代理坏了。

知识怎么接起来：U03 负责找到正确对象；U12 负责安全传送；本课判断有没有办成；U29 再测办事有多快。

在自己的环境中验证

保留状态码和脱敏错误信息，确认是目标、反向代理还是前置网关返回的；不要公开凭证。

只改一个条件，你来判断

改变：只把凭证换成有效凭证。

其余保持：仍是同一教学服务与输入；服务没有其他限制，后续处理正常。

问题：这次该继续改路线，还是预计拿到生成结果？请结合保持不变的条件解释。

另选一个问题

依据：httptlsicmp

U26 · E小请求能过，大一点就卡：先想到什么？

一只箱子能通过门，不代表再包几层后仍能通过。网络传送也有大小限制；隧道外面再加的说明信息，会占用空间。这里先把大小算清楚，而不是看见“卡住”就宣布找到了故障原因。

名字与本质

MTU：这一处允许通过的网络包大小上限
计算时要区分原来的包和加上外层包装后的包。不同链路与路径可能不同。 例如：本题上限 1500 字节，纯算术设定。
封装开销：外层包装占用的字节
用于运送原始数据而额外增加的信息。MSS 则是 TCP 一段可承载数据量的相关限制，不等于应用全文大小。隧道或具体传送协议。 例如：本题固定开销 80 字节，不代表某种产品的真实开销。

让它实际走一遍

本题只算大小：原包 1400 字节，额外包装 80 字节，上限 1500 字节。

  1. 外层总大小为 1400 + 80 = 1480 字节。
  2. 1480 不超过 1500，所以这个算术条件满足。

先统一每个数字计的是哪一层，再判断能否容纳。

原包大小 + 外层开销 ≤ 可用上限

换个场景，照样能用

“小请求可用、大请求失败”可把大小限制列为候选，但证书、超时或服务器限制也可能影响结果。

知识怎么接起来：U28 强调同一原则：可疑现象是线索，不直接等于唯一原因。

在自己的环境中验证

故障排查先记录问题是否稳定地随大小改变，再看路径反馈；不要未经验证改全机 MTU。

只改一个条件，你来判断

改变：原包改为 1450 字节。

其余保持：开销仍为 80，上限仍为 1500。

问题：新的总大小超过上限吗？

另选一个问题

依据：pmtutcp

U27 · E“三网优化”要怎么问，才不是一句广告？

你从家到体育场走哪条路，和回家走哪条路，可能不同；换一个出发城市也不同。网络路由同样不能因为一条去程看起来好，就自动给其他方向、运营商和晚高峰打包保证。

名字与本质

去程、回程与网络互联
不同网络各自选择转交路线，两个方向不一定对称。对等互联是网络之间交换约定流量；转接服务帮助到达更多网络。沿途网络的选择和互联。 例如：同一个机房，不同运营商用户可能体验不同。
三网优化：需要拆开的范围声明
要问哪家运营商、哪个城市、哪个方向、哪个时段，以及哪一个具体产品。商家说明与测试记录。 例如：线路商品名或一个网络编号，不自动等于低延迟。

让它实际走一遍

教学证据仅有：运营商 A、城市甲、白天，从本地到 VPS 的一次路径测试。

  1. 先把证据的四个限定写在记录上。
  2. 它没有测回程，也没有测其他运营商或夜间拥塞。

线路质量是具体路径在具体条件下的表现，不是一个永久标签。

城市 × 运营商 × 方向 × 时段：每个结论都有适用范围

换个场景，照样能用

选择中转机，优先测你真正访问的那一段；机房地理距离近，也可能被不佳互联绕远。

知识怎么接起来：U30 说明为什么分段路线好，仍不能直接换算为完整 API 耗时。

在自己的环境中验证

使用服务商的 Looking Glass（从指定网络发起测试的入口）或授权测试机，对照真实业务与时间。

只改一个条件，你来判断

改变：现在要判断从 VPS 回到本地的路线。

其余保持：手中仍只有原来那份去程记录。

问题：证据够不够证明回程也一样？

另选一个问题

依据：bgprouting

U28 · E中间一站“丢包 50%”，是不是线路坏了一半？

你沿路给每个收费站打电话。有个站不爱接电话，不代表经过它的车被扣住了一半。路由器回复探测与转送业务是两种工作：中间站少回复是线索，要继续看目的地和真实业务有没有同样受影响。

名字与本质

Traceroute / MTR：沿途探测工具
前者提供逐跳线索，后者重复探测并统计。中间设备可能限制自己的探测回复。测量端与愿意回应的中间设备。 例如：某一跳少回应，不自动等于后续业务同比例丢失。
往返时间、抖动、丢失与百分位
往返时间是来回花多久；抖动是忽快忽慢；丢失率要说明测了什么。P95 可直观看作这组数据中约 95% 不比它慢的分界，具体算法与样本数要注明。同条件收集的测量样本。 例如：超时单独计失败，不能删掉后只报成功请求平均值。

让它实际走一遍

教学记录：第 5 跳一半探测不回复，但同轮后续站和目标都回复，业务也成功。

  1. 只能先说第 5 跳对探测的回复比例低。
  2. 不能把它改写为“业务经过这里丢了一半”，因为终点与业务证据并未支持。

先检查终点有没有受影响，再解释中间站的探测行为。

探测回复缺失 ≠ 已证实的业务转发丢失

换个场景，照样能用

网络选型里，稳定完成一整段文字，往往比偶尔一次漂亮的 Ping 更值得测。

知识怎么接起来：U29 将观察终点进一步换成“用户真正看到第一段内容的时刻”。

在自己的环境中验证

保存时间、样本数、超时阈值和真实请求结果；同时记录成功耗时分布与失败率。

只改一个条件，你来判断

改变：目标同轮也开始出现明显探测丢失。

其余保持：第 5 跳原记录不变，没有更多业务证据。

问题：这时应该完全忽略，还是进一步检查端到端问题？

另选一个问题

依据：routingmtr

U29 · E0.4 秒有回复，为什么 1.8 秒才开始出字？

餐厅服务员先说“收到订单”，稍后才端上第一道菜。收到回应和开始交付，不是同一时刻。AI 服务也可能先发响应头或保持联系的空消息，随后才发真正的文字。你关心出字，就必须把第一段有效内容单独记时。

名字与本质

TTFB：开始收到回复；TTFT：开始收到有效模型内容
前者看首字节，后者看首个有效 token（模型输出的一小段内容）。先统一起点和什么算内容。由客户端实际接收并记录。 例如：响应头、心跳或空事件，不算本题的有效模型文字。
流式传送 / SSE：做好一点交一点
SSE 是通过 HTTP 连续发送文本事件的一种格式。中间层若攒一会儿再发，用户仍可能迟迟看不到内容。服务端、中间转送层与客户端。 例如：“连接没断”不等于“每段内容都及时到达”。

让它实际走一遍

教学时间线：发出请求后 0.4 秒收到响应头，0.6 秒收到心跳，1.8 秒收到第一段有效文字。

  1. 首字节时间是 0.4 秒。
  2. 本题首内容时间是 1.8 秒；0.6 秒的心跳不是菜。
  3. 两者的差距可能含服务排队、计算、缓冲等等待，不能直接全部归为网络慢。

衡量什么体验，就记录对应的交付事件。

首字节时刻 ≤ 首个有效内容时刻 ≤ 完成时刻（按本例定义）

换个场景，照样能用

curl 的时间字段通常从同一起点累计。比如“连上时刻”不是可再直接加到“首字节时刻”的独立耗时。

知识怎么接起来：U30 用这条时间线解释：网络往返时间为什么不等于 API 完成时间。

在自己的环境中验证

测试时记录首内容、后续停顿和完成或断流。curl 的 time_starttransfer 不能替你解析模型的第一段内容。

只改一个条件，你来判断

改变：第一段有效文字改在 3.0 秒到达。

其余保持：响应头仍在 0.4 秒，心跳仍在 0.6 秒，起点相同。

问题：TTFB 也必然变慢了吗？

另选一个问题

依据：curlsse

U30 · E两段网络延迟相加，就是 API 总耗时吗？

去餐厅用二十分钟，不代表二十分钟后一定吃到饭。还可能排队、点单、等厨房出菜。中转链路的网络时间只是业务等待的一部分；而且有些路段要来回交涉多次，有些连接已经建好可以复用。

名字与本质

往返时间与业务耗时
RTT 测一次来回；业务可能包含多次来回、连接准备、排队、处理和持续传送。每个测量要写明起终点。 例如：本地到中继 30 毫秒，中继到出口 150 毫秒，不等于 API 必在 180 毫秒完成。
连接复用、心跳与缓冲
复用是继续用已有连接；心跳是定时确认还在联系；缓冲是先攒数据再交出去。三者解决不同问题。客户端、代理与服务端各段。 例如：保持连接不等于不缓冲，也不保证模型立刻开始生成。

让它实际走一遍

教学测量只有两段 RTT：30 与 150 毫秒。目标处理多久、是否重建连接、出口到目标怎样走，都尚未知。

  1. 两个数字能帮助比较各自的网络段。
  2. 完整请求还包含未测的部分，因此不能许诺 180 毫秒完成。

分段网络测量用于定位，不是完整业务时延的替代品。

实际业务等待包含网络、连接准备、排队和处理；具体重叠要按时间线看

换个场景，照样能用

中转地与出口地之间的网络当然会影响体验，但最终要看整条实际路径，不靠地址标签估计。

知识怎么接起来：U32 最终把实际完成率、等待时间与总费用放在同一张采购记录中。

在自己的环境中验证

用同样内容、同样连接条件做端到端测量，再用分段数据解释；不要倒过来拼出未测过的总时间。

只改一个条件，你来判断

改变：目标处理额外增加两秒。

其余保持：网络条件、连接状态与其他环节不变。

问题：两段 RTT 没变，用户等待仍会变长吗？

另选一个问题

依据：curlhttp

U31 · F现在就排一次：先查哪里，而不是先重装什么？

别一口气换节点、改 DNS、关 TUN、重装应用。即使最后好了，也不知道哪一步起作用。先沿着首图给同一条请求做记号：在哪儿发出、有没有进代理、选了谁、对方实际看见谁、返回了什么。

名字与本质

同一条请求的证据链
让程序、目标和测试时段尽量固定，每条证据只证明它所在的一段。应用、代理日志、系统路由和授权目标。 例如：面板显示“已连接”，不等于某个具体程序已经用上。

让它实际走一遍

某工具访问失败，面板显示节点 A 可用。还没有这个工具对应的请求日志。

  1. 先找到工具实际运行位置。
  2. 检查它怎样把通信交给代理，以及这次请求有没有对应记录。
  3. 再看命中选择与具体错误。不要用面板状态代替请求轨迹。

先找最后一个有证据的环节，再补查下一段。

有证据的范围，到此为止；下一段用下一段的证据

换个场景，照样能用

每次只改变一个条件，并保存改前改后的同口径结果，才容易知道调整是否真正起作用。

知识怎么接起来：这把 U01、U06、U08、U19、U25 串成了一次实际故障处理，而不是五张独立术语卡。

在自己的环境中验证

本页实战区按“程序 → 接管 → 选择 → 路径 → 回复”给出只读检查，先记录后改动。

只改一个条件，你来判断

改变：新增该次请求的日志：已选择节点 A。

其余保持：没有目标侧来源回显，也不知道 A 后面是否再转送。

问题：现在能断定目标看到的公网来源就是 A 吗？

另选一个问题

依据：modetuncurl

U32 · F月租很低，为什么整月成本和体验仍可能不合算？

租车便宜，不代表里程费、过路费和等待时间都便宜。买服务器或代理也是一样：月租、带宽、流量配额、额外地址、超额费用，解决的是不同问题。先把同一业务整月会发生的账列出来，再比较。

名字与本质

带宽、实际速率、累计流量
带宽像路的通行容量；实际速率是眼下跑多快；流量是累计送了多少。8 bit 等于 1 byte，所以 100 Mbps 理想换算为 12.5 MB/s，实际还有开销。合同、测速与账单各自的口径。 例如：GB 是十进制单位，GiB 是二进制单位；计费方向也要确认。
试用与测试代表性
公开测试机是否与所买产品同线路、同限速，退款是否有排除项，都要确认。当次合同与书面答复。 例如：同商家另一款产品的测试 IP，不必然代表你的实例。

让它实际走一遍

纯教学价格：月租 5 个计价单位，包含 100 GB 出站流量，超出每 GB 收 0.2。没有其他费用，本月用了 90 GB。

  1. 先确认只算出站、周期为一个月，单位一致。
  2. 90 没超过 100，本例费用就是 5。

比较同口径总成本与实际业务表现，不只比较首页月租。

总费用 = 固定费用 + 超出配额的用量 × 单价（按本题合同）

换个场景，照样能用

一条业务经过两家供应商，两段都可能计费；一份采购表要覆盖整条链，不漏掉中转和出口。

知识怎么接起来：回到首图：先确定业务要走哪些段，再对每段提问、测试、算账。

在自己的环境中验证

采购前确认代表性测试、真实接入条件、晚高峰与完成率，并读独享范围、计费与退款条款。

只改一个条件，你来判断

改变：本月出站改为 130 GB。

其余保持：月租、配额、单价和无其他费用条件不变。

问题：本例一共付多少？

另选一个问题

依据：curlrouting

学完后，不是记住 32 个抽屉

找人

哪个程序发起？域名指什么？地址怎样取得？

U01–U03、U13

送到

有没有进代理？选谁转送？最后从哪里来？

U05–U09、U18–U19

办成

收到的是拒绝还是结果？等待发生在哪段？

U25、U29–U30

三张表分开填：路径表记录谁转给谁；地址属性表记录来源、位置、共享与保持规则；业务记录表记录权限、返回内容、耗时与完成情况。一张表的证据，不自动补全另外两张。

从理解到实际操作

动手验证：先预测，再看结果

只在自己的设备与获授权目标上操作。以下命令不修改路由、防火墙或证书；联网测试会产生少量请求和流量。

实战 1 · 不联网，亲手判断地址属于哪个范围

先预测：192.0.2.10 和 192.0.3.10 是否都属于 192.0.2.0/24？然后只运行下面的离线计算。

python3 - <<'PY'
import ipaddress
network = ipaddress.ip_network('192.0.2.0/24')
for address in ['192.0.2.10', '192.0.3.10']:
    print(address, ipaddress.ip_address(address) in network)
PY

把输出对应回 U04 的集合图。这段程序不访问任何示例地址。

实战 2 · macOS：分开看系统代理、具体路由、监听入口

先写你的预测：哪个设置会影响正在失败的程序？下面三项都是读取，不会修改网络。示例地址不发起业务访问。

scutil --proxy
route -n get 192.0.2.10
lsof -nP -iTCP -sTCP:LISTEN

第一条读系统提供的代理设置；第二条询问到这个示例地址会选哪条路；第三条看谁在等待 TCP 连接。要排真实故障，再在本机用实际目标地址查询，勿把含私人信息的全部输出公开。Linux 可用 ip route get 与 ss -lnt 做对应检查。

实战 3 · 显式交给本机代理，读一次 HTTP 结果

先确认自己的代理确实在 127.0.0.1:7890 接受 HTTP 代理请求；端口不同要替换。此实验会向公开示例网站发一条请求，可能计入流量；不用登录、API 密钥或关闭证书检查。先预测日志里会不会出现它。

curl --proxy http://127.0.0.1:7890 \
  --connect-timeout 5 --max-time 15 \
  --output /dev/null --silent --show-error \
  --write-out 'HTTP=%{http_code}\nconnect=%{time_connect}s\nfirst_byte=%{time_starttransfer}s\ntotal=%{time_total}s\n' \
  https://example.com/

将状态、错误与同一时刻的代理记录配对。time_connect 在这里涉及到代理的连接，不能冒充到目标的全部准备时间；first_byte 也不是模型首内容。没有这个本机代理时出现连接失败，是前提未满足。

实战 4 · 只改变“查目标地址由谁负责”

先确认同一入口支持 SOCKS5，且你已完成 U13 的预测。两次测试仅改变 socks5 与 socks5h，不同时切节点。两条命令会各发起一次请求。

curl --proxy socks5://127.0.0.1:7890 --connect-timeout 5 --max-time 15 --output /dev/null --silent --show-error https://example.com/
curl --proxy socks5h://127.0.0.1:7890 --connect-timeout 5 --max-time 15 --output /dev/null --silent --show-error https://example.com/

成功或失败本身不能完整证明解析位置；要结合选项定义与自己可见的解析、代理记录。不要把“没看到日志”直接写成“从未发生”。

实战 5 · 给自己正在用的业务做一张记录

固定一个无敏感内容、获授权的正常请求。先保留现状测一次，再只改一项；不做无限重试。

运行程序 / 所在机器：
目标与测试时间：
有没有进入代理 / 对应证据：
选择的节点 / 最终出口是否另测：
HTTP 状态或原始错误：
首字节 / 首个有效内容 / 完成时间：
最大停顿 / 是否断流或超时：
这次唯一改变：
可以得出的结论 / 仍未测到的部分：

对照 U31 的路径，不知道的写“未测”。凭证、用户内容和完整个人网络记录留在自己的设备，不写进公开课程或共享截图。

术语是标签，需要时再回来查

代理开在电脑上，为什么服务器里的任务没变化？

客户端：这次主动办事的程序：谁发出这次请求，谁就是这段通信的客户端。它不一定在你的电脑上。；代理：请中间程序代转：程序先把通信交给它，再由它转给目标。是否使用它，要看这次请求的实际路径。

回到 U01 的具体场景

Socket、连接、五元组：接听口、通话，还是通话标签？

Socket：程序收发数据用的通信对象：先把它想成程序手里的通信口。等待新连接的口叫监听 Socket；接通后收发这一次通信的口叫已连接 Socket。；IP 与端口：地址与编号：IP 是网络地址；端口是设备上区分通信入口的数字。这里的“门牌”必须连着地址看。；五元组：这段通信的五项标签：来源地址、来源端口、目标地址、目标端口、使用的传输协议。协议就是双方约定的传送办法，本例用 TCP。标签描述通信，不替程序收发数据。

回到 U02 的具体场景

知道网站地址，为什么还要报网站名字？

域名、IP、DNS：名字与找地址：域名是网站名字；IP 是网络地址。DNS 提供名字对应的地址等记录，像查地址簿，不负责替你运送正文。；SNI：安全连接开始时先报网站名：同一接待地址承载多个网站时，客户端可提前说明要找哪个，接待方据此选择网站的身份证明。；证书：网站出示的身份证明：客户端用它检查对方是不是自己要访问的网站。不是你交给网站的账号密码。

回到 U03 的具体场景

192.0.2.0/24 到底表示一个地址，还是一批地址？

地址前缀 / CIDR：用共同开头圈定地址集合：IPv4 地址有 32 位。/24 表示前 24 位固定，剩下 8 位可以变化；因此这个例子覆盖 192.0.2.0 到 192.0.2.255。

回到 U04 的具体场景

默认路线写着 Wi-Fi，为什么请求却走虚拟接口？

路由表：去哪些地址，该交给哪一站：像一张目的范围到下一站的安排表。默认路由是没有更具体安排时的兜底。；网络接口：数据交出去的口：可以是真实网卡，也可以是交给软件处理的虚拟口。接口名是标签，不是直连或代理的保证。

回到 U05 的具体场景

关了“系统代理”，为什么流量还经过代理软件？

系统代理：给应用看的转送设置：愿意读取这个设置的应用，会按它把请求交给代理；不是每个应用都会读。；TUN：把匹配的数据交给软件处理的虚拟口：配合路由，把本来要发出去的数据引到代理程序。它不是靠每个应用主动读取系统代理设置。

回到 U06 的具体场景

经过 Wi-Fi 网卡，怎么还算用了代理？

原始访问与搬运它的通信：前者是应用想访问网站；后者是代理程序为转送数据而建立的另一段通信。

回到 U07 的具体场景

都选了“全局代理”，为什么某个程序仍没走它？

入站与出站：怎么进来、接着怎么走：入站是接收入口，出站是发送选择。两个名字对应两个先后不同的问题。；Global / Rule / Direct：进站后的三种安排：全局交给指定策略；规则模式逐条选；全局直连按直连策略送出。DIRECT 指当前代理不借所选远端节点来转送。

回到 U08 的具体场景

域名规则更具体，为什么反而没有生效？

代理规则：按顺序检查条件：本课以 mihomo 为例，从上往下选首先匹配的一条。；MATCH：最后的其他情况：前面都没匹配时的兜底。PROXY 等组名是用户起的名字，不是固定的一台机器。

回到 U09 的具体场景

自动测速第一名，为什么用起来不一定最快？

节点组：几个可选转送方案：手选由你决定；URL-Test 依据指定网址的探测结果选；Fallback 在当前选择不可用时按顺序找可用方案。

回到 U10 的具体场景

198.18 开头的地址，是我的公网出口吗？

Fake-IP：给域名用的内部代号：代理保存“域名 ↔ 合成地址”的对应关系，后续看到合成地址就能找回相关域名。；198.18.0.0/15：特殊用途范围：登记用途是网络基准测试；一些代理借它做虚拟地址。它不是公网住宅地址证明，也不是常见三段私有地址之一。

回到 U11 的具体场景

代理替我送 HTTPS，能读到里面的文字吗？

HTTPS / TLS：保护这次对话：HTTPS 是通过 TLS 安全通信传送 HTTP；TLS 提供加密和对方身份检查。；CONNECT：请代理打通一条转送通道：HTTP 代理收到目标主机和端口后，建立连接并转送数据。普通 CONNECT 不等于代理解密网站正文。

回到 U12 的具体场景

查网站地址，到底由我查还是代理查？

SOCKS5：把连接目标交给代理的一种约定：可以交给代理一个 IP，也可以交给它一个域名，让它处理目标查找。；curl 的 socks5 与 socks5h：curl 是发起网络请求的命令行工具。在它的代理地址写法中，socks5 让本地查目标地址，socks5h 把目标域名交给代理。h 不是新的 SOCKS 版本。

回到 U13 的具体场景

网页能开，为什么实时通信还是不通？

TCP 与 UDP：两种传送办法：TCP 提供按顺序可靠交付的字节流；UDP 发送独立的数据报，不自带同样的可靠顺序保证，应用可另行实现。；HTTP/3 与 UDP 转送：HTTP/3 使用 QUIC，QUIC 基于 UDP。SOCKS5 规范有 UDP 转送能力，不代表你买到的产品一定开放。

回到 U14 的具体场景

一长串代理账号，哪些部分是地址，哪些是凭证？

入口地址、账号、会话标记：入口告诉程序去哪儿联系代理；账号凭证证明有权使用；有些产品用会话标记选择或保持出口。

回到 U15 的具体场景

云平台已经放行端口，外面为什么还连不上？

VPS：租来的远程电脑：它能运行程序，但“租到电脑”不等于“已经运行好代理服务”。；监听与防火墙：有人接待、允许经过：监听表示程序正在某个本地地址和端口等待；防火墙、安全组决定哪些流量允许经过。

回到 U16 的具体场景

多台设备共用一个公网 IP，回复怎么分给正确的人？

NAT / 地址端口转换：代换外部地址并保存对应：常见家庭网络把内部地址和端口换成公网一侧的地址和端口，并记录两边关系。；端口转发与运营商共享地址：主动访问形成的临时对应，不等于外界随时能主动找进来。端口转发可安排固定外部入口；上层还有运营商转换时，家用路由器未必能控制它。

回到 U17 的具体场景

正向代理、反向代理：到底是谁请来的帮手？

正向代理：替来访者办事：客户端选择它，借它访问目标。；反向代理：替服务方接待：外部访问服务的统一入口，入口再交给内部程序。

回到 U18 的具体场景

经过两级代理，网站最后看到哪个 IP？

出口 IP：这段访问最后向目标呈现的来源地址：在指定目标接入处，观察到连接从哪个地址来。它不等于代理入口地址，也不等于用户账号身份。；转发头：另外写在请求里的来源说明：能处理 HTTP 内容的中间层可能传递来源信息；内容是否可信取决于服务方的信任设置。

回到 U19 的具体场景

数据库写“美国”，机器就一定在美国吗？

ASN / BGP：哪个网络、怎样对外告知路线：ASN 是一个网络的编号；BGP 是网络之间交换到达路线信息的办法。它们不直接给出某台服务器的街道地址。；地理定位标签：数据库对地址位置的判断：它可能来自多种数据并会更新，准确程度并非处处相同。

回到 U20 的具体场景

“ISP、住宅、静态、独享”四个词，分别回答什么？

ISP / Residential / Hosting：来源或用途描述：ISP 是互联网接入服务商；住宅通常强调居民接入场景；Hosting 强调托管用途。商家和数据库用词并不完全统一。；Static / Dynamic 与 Dedicated / Shared：静态或动态说多久变化；独享或共享说约定范围内有谁共同使用。

回到 U21 的具体场景

用了同一个会话名，为什么 IP 还是会换？

会话保持 / Sticky Session：在规定的有效期与出口可用条件内，产品尽量或按合同保持分配。具体保证强度必须看产品说明。

回到 U22 的具体场景

风险分是 0，为什么业务仍可能拒绝？

IP 风险或信誉评分：某个供应商依据自己掌握的数据给出的判断信号，不是全球统一的物理刻度。；网络能到与业务允许使用：请求能到达，只是通信条件；账户权限和业务规则还由目标服务判断。

回到 U23 的具体场景

出口检测通过一次，就代表整台电脑都通过了吗？

IPv4 与 IPv6：两套地址与选路体系：只验证一种，不等于验证另一种。；DNS 与浏览器实时通信：DNS 负责查名字；WebRTC 用于浏览器音视频等实时通信，会涉及发现可用通信路径。它们不是一次普通网页回显的同一项测试。

回到 U24 的具体场景

能 Ping、能收到回复，为什么 API 仍不能用？

HTTP：请求与回复的表达约定：像规定申请单和回执怎样写，允许表达成功，也允许表达拒绝或错误。；API：软件对外办理业务的约定：不只是入口，还规定接受什么要求、做什么、返回什么。本课讨论通过 HTTP 访问的 API。；Ping：另一种探测，不是办事前必经的一关：它通常用 ICMP 回显消息探测对方是否回复；与业务用的 TCP、TLS、HTTP 不是同一项测试。

回到 U25 的具体场景

小请求能过，大一点就卡：先想到什么？

MTU：这一处允许通过的网络包大小上限：计算时要区分原来的包和加上外层包装后的包。；封装开销：外层包装占用的字节：用于运送原始数据而额外增加的信息。MSS 则是 TCP 一段可承载数据量的相关限制，不等于应用全文大小。

回到 U26 的具体场景

“三网优化”要怎么问，才不是一句广告？

去程、回程与网络互联：不同网络各自选择转交路线，两个方向不一定对称。对等互联是网络之间交换约定流量；转接服务帮助到达更多网络。；三网优化：需要拆开的范围声明：要问哪家运营商、哪个城市、哪个方向、哪个时段，以及哪一个具体产品。

回到 U27 的具体场景

中间一站“丢包 50%”，是不是线路坏了一半？

Traceroute / MTR：沿途探测工具：前者提供逐跳线索，后者重复探测并统计。中间设备可能限制自己的探测回复。；往返时间、抖动、丢失与百分位：往返时间是来回花多久；抖动是忽快忽慢；丢失率要说明测了什么。P95 可直观看作这组数据中约 95% 不比它慢的分界，具体算法与样本数要注明。

回到 U28 的具体场景

0.4 秒有回复，为什么 1.8 秒才开始出字？

TTFB：开始收到回复；TTFT：开始收到有效模型内容：前者看首字节，后者看首个有效 token（模型输出的一小段内容）。先统一起点和什么算内容。；流式传送 / SSE：做好一点交一点：SSE 是通过 HTTP 连续发送文本事件的一种格式。中间层若攒一会儿再发，用户仍可能迟迟看不到内容。

回到 U29 的具体场景

两段网络延迟相加，就是 API 总耗时吗？

往返时间与业务耗时：RTT 测一次来回；业务可能包含多次来回、连接准备、排队、处理和持续传送。；连接复用、心跳与缓冲：复用是继续用已有连接；心跳是定时确认还在联系；缓冲是先攒数据再交出去。三者解决不同问题。

回到 U30 的具体场景

现在就排一次：先查哪里，而不是先重装什么？

同一条请求的证据链：让程序、目标和测试时段尽量固定，每条证据只证明它所在的一段。

回到 U31 的具体场景

月租很低，为什么整月成本和体验仍可能不合算？

带宽、实际速率、累计流量：带宽像路的通行容量；实际速率是眼下跑多快；流量是累计送了多少。8 bit 等于 1 byte，所以 100 Mbps 理想换算为 12.5 MB/s，实际还有开销。；试用与测试代表性：公开测试机是否与所买产品同线路、同限速，退款是否有排除项，都要确认。

回到 U32 的具体场景

读配置时再查：匹配条件

IP-CIDR：按目标地址范围匹配；SRC-IP-CIDR：按来源范围匹配。DST-PORT / SRC-PORT：看目标或来源端口。PROCESS-NAME / PROCESS-PATH：按程序名或路径选，能否读取取决于系统。GEOIP：地址地理分类数据；GEOSITE：域名分类集合，不是实时定位。RULE-SET / Rule Provider：引用一组规则及其来源。Proxy Provider：节点配置来源。

回到 U09 的具体场景

读配置时再查：接口与透明接管

Mixed Port：一个入口接受几种支持的代理说法。Transparent Proxy：应用不主动指定，由网络安排接管。TAP：以网络帧交给软件的虚拟口；TUN 则以 IP 包为交接单位。Redirect / TProxy：不同系统上的转交机制，不是所有设备都支持。Split Tunnel：按范围分流；Full Tunnel：广范围转交，但仍要查例外。

回到 U06 的具体场景

读代码时再查：Socket 的内部引用

fd / File Descriptor：程序用来指向已打开对象的小整数，不是 IP。handle：某些系统中类似的引用。accept：从等待新连接的 Socket 接收一次连接，得到新的已连接 Socket。排路径时先理解通信对象与标签，不必先背这些代码接口。

回到 U02 的具体场景

读套餐时再查：容量与稳定性

Bandwidth：容量；Throughput：实际速率；Transfer：累计传输量。GB 与 GiB：十进制与二进制数据量单位。Session Lifetime：保持会话的时长。Rotating：按某种条件重选出口。Dedicated：约定范围内独享，不是永久不换或平台保证。

回到 U32 的具体场景

资料来源

正文使用教学设定展示关系；规范解释通用机制，实现文档解释具体选项。示例数字不是测速结果或实时商家报价。

curl 官方手册
代理选项、超时、计时字段；本页命令的实现依据。

curl：SOCKS 代理
本地与代理侧查找目标域名的分工。

POSIX：accept
监听口接收连接后返回新的已连接通信对象。

RFC 9293：TCP
TCP 连接、双方端点与可靠字节流；五元组在本页固定观察位置。

RFC 1034：域名系统
域名查询与地址等记录；不是正文转送协议。

RFC 6066 §3：Server Name Indication
共享地址时在安全连接建立过程中指明目标网站名。

RFC 9110：HTTP
请求、回复、代理、CONNECT、状态码。API 窗口故事是教学模型。

RFC 8446：TLS 1.3
安全通信与身份检查；普通转送和解密角色分开。

RFC 792：ICMP
回显探测的协议依据；Ping 不属于 HTTP 的必经步骤。

IANA：IPv4 特殊用途地址登记
文档示例、回环、私有与基准测试用途地址。

RFC 1812：IPv4 路由器要求
目的地址选路与最长前缀；本课例题使用单一路由表。

mihomo：全局配置
模式、监听与访问范围按当前实现阅读。

mihomo：TUN
虚拟入口、路由接管及例外。

mihomo：路由规则
规则类型与从上到下的匹配行为。

mihomo：dialer-proxy
代理之间继续转送的实现例子。

mihomo：DNS
Fake-IP 与解析配置；地址在字段中的用途必须区分。

mihomo：自动选择
基于指定测试目标的节点选择。

mihomo：自动回退
按可用性与顺序回退，不等于所有业务最低时延。

RFC 1928：SOCKS5
目标地址类型、连接与 UDP 转送。会话保持故事另有明确教学合同，不是协议承诺。

RFC 9000：QUIC
基于 UDP 的传送协议与流。

RFC 3022：传统 NAT
地址端口改写与对应记录。

RFC 4271：BGP
网络间的路由信息交换，不是设备物理定位证书。

MaxMind：数据准确性
地理定位的准确性与限制；产品标签、风险分与目标决策分别讨论。

W3C：WebRTC
浏览器实时通信与连接机制，不能用单次 HTTP 回显替代测试。

RFC 1191：路径 MTU 发现
大小限制与路径反馈；示例开销是设定，非测量。

MTR 项目说明
沿途重复探测工具；探测回复和业务转发需分开解释。

WHATWG：Server-sent events
事件流格式；第一段有效业务内容需自行识别。

答案附录

U01 · 代理开在电脑上，为什么服务器里的任务没变化？

提示：圈出真正执行下载的那台机器。

参考判断：不会因此自动改道。远程程序没有读取笔记本上的设置。

回看：把“在哪儿操作”当成“在哪儿执行”。 分别写下键盘在哪台机器、下载程序在哪台机器。

U02 · Socket、连接、五元组：接听口、通话，还是通话标签？

提示：不要只盯着目标端口，看看来源的两项。

参考判断：不需要。等待口继续存在，为 B 增加另一个已连接 Socket；B 的来源地址、来源端口与 A 不同。两条连接可以共用代理的 7890 端口。

回看：把“同一个接待入口”当成“只能有一条通话”。 并排写出两条五元组，只圈出不同项。

U03 · 知道网站地址，为什么还要报网站名字？

提示：想想你走到共同接待处后要报的名字。

参考判断：目标网站名应改为 shoe.example.com；只沿用同一个 IP，不能表达“改找卖鞋的网站”。

回看：把“找到接待地址”当成“已经选好网站”。 画两条网站名箭头汇入同一个地址，看反向是否唯一。

U04 · 192.0.2.0/24 到底表示一个地址，还是一批地址？

提示：看固定的第三个数有没有变化。

参考判断：不属于。固定的第三个数要求是 2，而新地址是 3。

回看：只看到共同的 192.0 开头，忽略固定范围。 先在地址上划出不能变的部分，再比较。

U05 · 默认路线写着 Wi-Fi，为什么请求却走虚拟接口？

提示：重新看看还留下哪些匹配项。

参考判断：交给 en0。专门安排删除后，只有默认路线可选。

回看：把“默认”误解成“最高优先级”。 把默认读成“其他情况”；先找例外范围。

U06 · 关了“系统代理”，为什么流量还经过代理软件？

提示：被关闭的那项设置，原本参与这次转送了吗？

参考判断：不能。工具本来就不读那项设置，实际起作用的 TUN 与路由仍在。

回看：把一个开关当成整台电脑所有接管方式的总开关。 画出“应用设置”和“系统选路”两处控制点。

U07 · 经过 Wi-Fi 网卡，怎么还算用了代理？

提示：先问 en0 上这段通信正在联系谁。

参考判断：不能。代理的外发通信也必须经过物理网络。

回看：把物理承载方式当成是否代理的标签。 每条记录旁同时写“谁发、发给谁、用哪个接口”。

U08 · 都选了“全局代理”，为什么某个程序仍没走它？

提示：告示能安排一件没收到的包裹吗？

参考判断：不能。该程序没有进入代理，站内选择不能证明它的路径。

回看：把“收到的全部”当成“整台电脑的全部”。 把“全局”补完整读成“交给此核心处理的流量，统一选策略”。

U09 · 域名规则更具体，为什么反而没有生效？

提示：从新的第一行开始，不要先替规则按精细程度排序。

参考判断：选 A。第一行的域名后缀范围已包括 api.example.com。

回看：把系统路由的最长前缀规则套到代理列表上。 在列表上逐行打勾，遇到第一个匹配就停。

U10 · 自动测速第一名，为什么用起来不一定最快？

提示：便利店的到达时间，测过机场路线吗？

参考判断：不能。要对新目标按同样条件比较，原探测不能替代它。

回看：把局部测试排名当成全网排名。 在每个数字后写上目标、时间与测量动作。

U11 · 198.18 开头的地址，是我的公网出口吗？

提示：这条记录里有没有出现域名与代号的对应关系？

参考判断：不能。它只显示下一跳，尚未给出那个域名的映射。

回看：看数字开头就忽略了字段含义。 先读字段名，再读地址值。

U12 · 代理替我送 HTTPS，能读到里面的文字吗？

提示：两层盒子的钥匙，是不是同一把？

参考判断：不会因此读懂。外层解开后，里面仍是客户端与网站那层加密数据。

回看：把到代理的加密与到网站的加密当成同一层。 分别写两层保护各从谁开始、到谁结束。

U13 · 查网站地址，到底由我查还是代理查？

提示：你交出去的是门牌，还是店名？

参考判断：交给代理一侧；curl 把目标域名传给它。

回看：以为 SOCKS5 这个名字自动规定只能远端解析。 把“找代理入口”和“找目标网站”写成两行。

U14 · 网页能开，为什么实时通信还是不通？

提示：新的货物类型是否在运输公司的能力里？

参考判断：不足以；题设代理不支持所需的 UDP 转送。

回看：把“同一个 443 数字”当成同一种协议能力。 比较记录时，把 TCP 或 UDP 与端口写在一起。

U15 · 一长串代理账号，哪些部分是地址，哪些是凭证？

提示：地点没变，订单是否可能换了一辆车？

参考判断：不能保证；新标记可能影响分配，但也不能保证一定拿到不同 IP。

回看：把入口地址当成最终出口。 在示例字符串下分别标“去哪儿、凭什么用、怎样分配”。

U16 · 云平台已经放行端口，外面为什么还连不上？

提示：哪一项修改了程序接待的地址？

参考判断：不能。仅本机监听没有改变。

回看：把“允许过门”当成“业务窗口已对外营业”。 分别检查接待口与道路许可。

U17 · 多台设备共用一个公网 IP，回复怎么分给正确的人？

提示：总机已经忘记这一通原来转给谁。

参考判断：不能保证。公网 IP 不包含丢失的内部对应关系。

回看：把地址共享误解成无需记录也能自动识别人。 给每个外部端口画一条到内部设备的对应线，再删掉 A 那条。

U18 · 正向代理、反向代理：到底是谁请来的帮手？

提示：这次是来访者请的跑腿，还是网站自己的接待员？

参考判断：反向代理，它代表网站接收访问并交给内部服务。

回看：把软件名称当成固定代理类别。 把两种情形分别标为“替客户端”和“替服务端”。

U19 · 经过两级代理，网站最后看到哪个 IP？

提示：最后一段是谁主动发给目标的？

参考判断：Y 的来源地址。

回看：把最先连到的中继与最后出面的出口混在一起。 给每一段写清发起者；最后一段单独画框。

U20 · 数据库写“美国”，机器就一定在美国吗？

提示：变化的是记录，还是已经观察到设备移动？

参考判断：不能证明；已知改变的是数据库标签。

回看：把数据库描述当成物理事实本身。 做四栏记录：登记、网络、部署、定位；不知道的留空。

U21 · “ISP、住宅、静态、独享”四个词，分别回答什么？

提示：“归谁的资源”和“放在哪里”是否同一问题？

参考判断：不一定矛盾。运营商资源可以用于数据中心。

回看：把产品标签当成所有属性的联合保证。 逐项问来源、部署、共享范围、变化规则。

U22 · 用了同一个会话名，为什么 IP 还是会换？

提示：承诺的时间范围是否仍包含现在？

参考判断：不能保证。实际可能仍相同，但超出了这条合同的保证范围。

回看：把过去相同当成未来永远相同。 给“保持”补上起点、时长和失效条件。

U23 · 风险分是 0，为什么业务仍可能拒绝？

提示：改变的是被测地址，还是评分人和评分尺子？

参考判断：不能。检测服务不同，数据、规则与刻度也可能不同。

回看：把不同供应商的分数直接当成同一把尺子。 先对齐评分定义，再比较结果；保留不确定项。

U24 · 出口检测通过一次，就代表整台电脑都通过了吗？

提示：第二次还在第一项测试覆盖的范围里吗？

参考判断：不足以。需要实际核对 IPv6 路径；仅仅未测试，也不能断言它已经泄漏。

回看：把一个成功样本当成整个环境的认证。 分已测与未测，不拿猜测填空。

U25 · 能 Ping、能收到回复，为什么 API 仍不能用？

提示：线路与服务都没变，窗口原先拒绝的是哪一个办理条件？

参考判断：按题设预计拿到结果：原来是凭证无效，这次换成有效凭证，且没有其他限制、后续处理正常。不是“修好了不通的路”，而是满足了窗口的办理条件。

回看：把业务拒绝等同于完全无法联系。 把错误先放进三格：没接通、收到拒绝、收到结果。

U26 · 小请求能过，大一点就卡：先想到什么？

提示：门检查的是包装后的整体，不是里面单独的物品。

参考判断：超过：1450 + 80 = 1530。系统之后怎样拆分、反馈或丢弃，要再看实际实现。

回看：把内层大小、外层大小与业务正文长度混为一谈。 每个数旁标“原包、包装、总上限”。

U27 · “三网优化”要怎么问，才不是一句广告？

提示：往返是否被规定必须走同一条路？

参考判断：不够，需要相应方向的测试。

回看：把一个方向的观察扩展成双向保证。 把测试表分成去程和回程两栏。

U28 · 中间一站“丢包 50%”，是不是线路坏了一半？

提示：终点的证据改变了哪一部分判断？

参考判断：应进一步检查，但仍不能仅此锁定第 5 跳就是根因。

回看：在“这跳必坏”和“中间跳永远不重要”之间二选一。 保留现象，缩小结论，补上业务验证。

U29 · 0.4 秒有回复，为什么 1.8 秒才开始出字？

提示：服务员确认订单的时刻变了吗？

参考判断：没有，本题仍是 0.4 秒；变慢的是首内容时间，变成 3.0 秒。

回看：把“已经回复”当成“已经开始交付”。 画四个点：回复开始、首内容、最长停顿、结束。

U30 · 两段网络延迟相加，就是 API 总耗时吗？

提示：新增的两秒有没有被那两次网络测量包含？

参考判断：会。新增处理等待不在那两个 RTT 里。

回看：把网络运输当成完成业务的全部工作。 把传送、等待、办理分别记账，避免把重叠的累计时间再相加。

U31 · 现在就排一次：先查哪里，而不是先重装什么？

提示：节点 A 可能是中继，还是已证实是最后出口？

参考判断：还不能。日志证明这层选择了 A，不证明 A 后面没有其他出口或地址转换。

回看：把局部记录扩大成整条路径的证明。 把这条日志贴在首图对应节点上，不替后面的节点填答案。

U32 · 月租很低，为什么整月成本和体验仍可能不合算？

提示：只对超过配额的部分计超额费。

参考判断：11 个计价单位：5 + (130 − 100) × 0.2。

回看：把带宽、配额与费用混成一个“够不够”的数字。 给数字补单位、方向、周期和超额规则。