AI科研的必备计网技巧拾遗

• 参考：【科研要懂的网络基础 - 哈基彤在update | 小红书 】

名词解释

▸计网相关概念

应用与端口

应用程序通过端口号（Port，0–65535）标识自身，操作系统据此将网络数据分发给对应程序。例如 HTTP 用 80，HTTPS 用 443。

DNS: Domain Name System，域名系统。负责将人类可读的域名（如 example.com）解析为机器可读的 IP 地址（如 93.184.216.34），是互联网的“电话簿”。

IP、默认网关与路由

• IP：Internet Protocol，网络层协议，为每台设备分配逻辑地址（IPv4 或 IPv6），实现跨网络寻址。
• 默认网关：设备在本地子网找不到目标地址时，将数据包转发到的“出口”路由器 IP。
  • 例如家用 Wi‑Fi 下本机 192.168.1.100、网关常是 192.168.1.1；访问 8.8.8.8 时，系统发现目标不在 192.168.1.0/24 内，就会把包交给 192.168.1.1，再由路由器继续往外转发。
• 路由：决定数据包从源到目的的路径选择机制，由路由表和路由协议（如 OSPF、BGP）实现。
  • 操作系统查路由表，为每个目标 IP 选“走哪张网卡、下一跳是谁”。例如 default -> 192.168.1.1 via en0 表示大多数外网流量走 Wi‑Fi；若另有 10.2.11.117/32 -> utun9，访问该实验室 IP 时会走 VPN/零信任虚拟接口，而不是默认网关。

ARP 与 NDP

• ARP：Address Resolution Protocol，地址解析协议。用于 IPv4 网络中，根据 IP 地址查询对应的 MAC 地址（数据链路层地址）。
  • IP 只解决“发给哪台机器”，真正在局域网里发以太网帧时还需要对方的 MAC 地址（网卡硬件地址）。ARP 相当于在局域网里广播一问：“谁是 192.168.1.1？请告诉我你的 MAC地址。”得到应答后，本机才能把包真正发到路由器。若 ARP 失败，常见现象是同一 Wi‑Fi 下 ping 不通网关，尽管 IP 配置看起来正常。
• NDP：Neighbor Discovery Protocol，邻居发现协议。IPv6 中替代 ARP 的协议，功能包括地址解析、路由器发现、重复地址检测等。
  • IPv6 本机要 ping 同一 Wi‑Fi 下路由器的链路本地地址 fe80::1 时，会先发出邻居请求（Neighbor Solicitation，组播到 ff02::1），问”谁的地址是 fe80::1？”路由器用邻居通告（Neighbor Advertisement）回复自己的链路层地址，本机才能把 IPv6 包真正发出去——这一步相当于 IPv4 的 ARP。开机后还会监听路由器发来的路由器通告（Router Advertisement），从而知道默认网关是谁；配置新 IPv6 地址前，也会先发邻居请求做重复地址检测，避免与局域网里已有地址冲突。

NAT、防火墙与安全组

• NAT：Network Address Translation，网络地址转换。将私有 IP 地址映射为公网 IP，实现多设备共享上网，同时隐藏内网拓扑。
  • 例如宿舍电脑 192.168.1.100 访问 8.8.8.8:443 时，家用路由器会把源地址改成自家宽带公网 IP（如 123.45.67.89）再发出去；远端服务器看到的往往是路由器公网 IP，而不是某一台笔记本的内网地址。多台设备同时上网时，靠不同源端口区分回包。
• 防火墙：基于规则过滤网络流量的安全设备/软件，可控制进出数据包的允许或拒绝。
  • 例如本机 ufw 默认拒绝外网连入 22 端口，则即使实验室服务器在内网可达，从公网直接扫 22 也会被挡在门外；又如在服务器上只放行 10.0.0.0/8 访问 8888，则宿舍公网 IP 未入白名单时，Jupyter 页面会打不开。
• 安全组：云计算环境中的虚拟防火墙，以实例/端口粒度定义访问控制策略（如 AWS Security Group、阿里云安全组）。
  • 例如在云主机安全组里只添加”TCP 22 来自实验室网段””TCP 6006 来自办公室 IP”，未写入规则的端口即使服务已在机器内监听，外网仍无法访问——这与”进程已启动但安全组未放行”导致的连不上，是两类不同问题。

TUN 接口

虚拟网络接口（Tunnel Interface），工作在网络层。应用程序通过 TUN 设备读写 IP 数据包，常用于 VPN 实现，将原始 IP 包封装后通过另一网络传输，到达对端再解封装。

• 例如安装 TrustAgent 或 Cisco VPN 后，系统会多出 utun8、utun9 这类接口；路由表若写 10.2.11.117/32 -> utun9，发往该实验室 IP 的包会先进入 utun9，由对应程序读走，而不是从物理网卡 en0 直接发出。对操作系统而言，TUN 与 Wi‑Fi 网卡一样都是”一张网卡”，只是背后接的是用户态程序。

隧道

Tunnel，一种封装技术。将一种网络协议的数据包封装在另一种协议中传输，实现穿越异构网络或加密传输。

• 例如 Cisco VPN 从 utun8 读到”要去 10.2.11.117“的原始 IP 包后，再套一层发向公司网关的外层 IP 头（常加密），经公网送到对端后拆开，内层包才继续转发——外层负责”怎么穿过互联网”，内层仍是原来的业务地址。

代理

Proxy，中间人服务。客户端不直接连接目标服务器，而是将请求发给代理，由代理代为转发。

• 例如浏览器配置 Clash 的 HTTP 代理 127.0.0.1:7890 时，访问 github.com 会先连本机 7890，再由 Clash 决定是否直连或走远端节点；若终端未设置 http_proxy，同一台机器上 git clone 可能失败，而浏览器仍正常——说明流量是否”主动交给代理”，取决于应用是否配置代理，而非整机路由。

VPN

Virtual Private Network，虚拟专用网络。通过加密和隧道技术在公共网络上建立私有通信通道，实现远程安全接入内网或保护隐私。常见协议包括 WireGuard、OpenVPN、IPsec。

• 例如宿舍电脑拨入学校 Cisco VPN 后，会获得 10.8.0.5 这类虚拟地址，并下发”10.2.0.0/16 走 utun8”的路由；此后访问实验室 10.2.11.117:22 的流量经加密隧道进校内网，就像暂时坐在校园网里一样。与传统”整机改路由”的 VPN 不同，零信任客户端往往只放行少量目标网段。

TLS

Transport Layer Security，传输层安全协议。为应用层通信（如 HTTPS、SMTPS）提供加密、身份认证和完整性保护，是 SSL 的继任者。TLS 1.3 为当前主流版本。

• 例如浏览器访问 https://huggingface.co 时，在 TCP 443 连接建立后还要完成 TLS 握手：校验证书是否可信、协商加密密钥，之后的 HTTP 内容才在密文中传输。若系统时间错误或证书过期，页面会报 TLS/证书错误——此时路由与 DNS 可能都正常，问题已落在应用层安全握手。

一次请求

假设打开一个网站，或在终端里执行一条命令，大致会经过以下步骤：

1. 应用发起请求
2. 如果目标是域名，先查 DNS，拿到目标 IP
3. 应用决定协议和端口
4. 操作系统查路由表，决定目标 IP 走哪个接口
5. 如果目标不在本地网段，流量先交给默认网关
6. 如果命中了 TUN 接口，流量先进入虚拟接口
7. 如果程序要建隧道，原始 IP 包会再封装一次
8. 如果应用使用代理，请求会先发给代理
9. 流量离开本机后，还会经过 NAT、防火墙、安全组、企业网关
10. 到达目标服务以后，很多应用还会继续做 TLS 校验

遇到网络问题时，“连不上”背后，可能是完全不同的环节出了问题。

摘录自 【科研要懂的网络基础 - 哈基彤在update | 小红书 】

应用与端口

网络请求的起点是某个应用，常见的有：

• 浏览器
• curl
• git
• pip
• SSH 客户端
• VS Code Remote
• Python 程序里的某个库

应用通过 socket 与操作系统交互。IP 回答“去哪台机器”，端口回答“那台机器上的哪个服务”。
一些IP：

• 1.1.1.1:53 常见于 DNS
• 8.8.8.8:443 常见于 HTTPS
• 10.2.11.117:22 常见于 SSH

完整连接目标通常写成：协议 + 目标 IP + 目标端口。

科研里很多“服务器能不能连上”的问题，最后都落在端口上。ping 通只能说明机器大概率在线，22、8888、6006 能不能访问，是另一回事。

DNS

如果输入的是 example.com 这种域名，系统会先查 DNS，把它翻译成 IP。DNS 只管“这个域名对应哪个 IP”，后面的路径、代理、VPN 都不在它的范围里。

常见情况有：

• 内网域名只有企业 DNS 能解析
• 校园网和家宽下，解析结果不一样
• 代理已经接管流量，DNS 还在本地解析，于是出现 DNS 泄漏

所以“网站打不开”这句话太粗了。更有用的问法是：

• 域名有没有被正确解析
• 解析出来的 IP 对不对
• 这个 IP 是公网目标，还是企业内网目标

IP、默认网关与路由

电脑连上网络以后，通常会拿到一个本地 IP；开了 VPN 或零信任客户端，还会多出一层虚拟 IP。系统会先判断：目标 IP 和本机是不是在同一个本地网段。

• 如果在同一个网段，数据通常可以直接发过去
• 如果不在，就要交给默认网关

默认网关是兜底的下一跳。系统没有命中更具体的路由时，先把包交给它，剩下的交给路由器继续转发。路由表负责决定：

• 去某个目标 IP 时，应该走哪张接口
• 必要时，应该交给哪个下一跳

流量不总是走默认网关。只要路由表里有更具体的规则，系统就会优先走那条规则。

例如路由表里同时有：

• default -> en0（兜底：不知道往哪送的，都先交给 Wi‑Fi 网卡 en0）
• 10.2.11.117/32 -> utun9（专条：只针对这一台机器 10.2.11.117，走虚拟接口 utun9）

在宿舍 Wi‑Fi 下执行 ssh user@10.2.11.117 时，操作系统会查路由表，发现有一条规则”目标正好是 10.2.11.117 这一个 IP”，比”default 管所有地址”更精确，于是包从 utun9 交给 TrustAgent 等程序处理，不会从 en0 直接当普通公网流量发出去。

反过来，访问 github.com（解析成公网 IP）时，路由表里没有为它单独写规则，只能命中 default，流量仍走 en0 和家里路由器。因此同一台电脑可以同时开着 Clash、Cisco VPN、TrustAgent：去 GitHub 走 Wi‑Fi，去实验室 10.2.11.117 走 utun9。
【不是谁后开谁接管整机，而是”目标 IP 命中哪条路由”决定走哪条路。】

ARP 与 NDP

这一步偏底层。路由表用 IP 告诉系统下一跳是哪台设备，但网卡真正发以太网帧时，交换机认的是二层标识(在常见 Wi‑Fi/有线网里就是 MAC 地址（如 aa:bb:cc:dd:ee:ff）)。

层级	标识	作用范围
三层（网络层）	IP 地址	跨网段寻址，“要去哪台机器”
二层（链路层）	MAC 地址	同一 Wi‑Fi/网线内，“帧贴给谁”

IPv4 里靠 ARP 把 IP 换成 MAC，IPv6 里靠 NDP。它们要回答的是：

• 默认网关的 MAC 是什么
• 本地网段里某台机器的二层标识是什么

如果这一步出问题，常见现象是：

• DNS 看起来正常
• 路由也没问题
• 目标就在本地网段
• 结果还是发不出去

网络问题有时候会卡在比 DNS 和路由更靠后的位置。

NAT、防火墙与安全组

流量离开电脑以后，还会遇到 NAT、防火墙、安全组。NAT 是网络地址转换，本地私有 IP 离开路由器时，常会被改写成公网出口 IP，所以远端网站看到的，往往是家庭网络或学校网络的出口 IP。防火墙和安全组则决定流量能不能继续往前走。

它可能出现在：

• 本机
• 家用路由器
• 学校出口
• 公司网关
• 云服务器安全组

有路由，只说明路径在表里。能不能访问，还要看中间有没有被拦。科研服务器外网访问里，这类问题尤其常见。

在服务器上启动了一个服务，只说明它在本机能跑。想让外网访问到它，通常还要继续检查：

• 服务有没有监听正确端口
• 本机防火墙有没有放行
• 云平台安全组有没有放行
• 上级网络有没有公网入口
• 需不需要端口映射

很多人第一次配远程 JupyterLab、TensorBoard、Gradio、API 服务，都会停在这里。

TUN 接口

TUN 接口是一个虚拟接口。操作系统会把它当成一张网络接口，背后连接的是某个程序。

• 物理接口负责真正把包发出去
• TUN 接口负责让程序在系统层面接管 IP 包

很多现代网络工具都靠它工作：

• Cisco Secure Client
• 零信任客户端
• WireGuard
• Tailscale
• Clash 的 TUN 模式
• Cloudflare WARP

普通代理模式下，应用主动把请求交给代理。到了 TUN 模式，请求是否经过某个程序，已经变成系统网络层的问题了。

摘录自 【科研要懂的网络基础 - 哈基彤在update | 小红书 】

隧道

隧道做的事情很直接：

• 把原始 IP 包再包一层
• 让它穿过另一个网络到达远端
• 在远端再拆开

可以把它理解成一条逻辑运输管道。常见过程是：

1. 路由命中 TUN 接口
2. 程序从 TUN 接口读到原始 IP 包
3. 程序把原始 IP 包封装进隧道
4. 封装后的外层包再通过物理接口发出去

TUN 接口和隧道经常一起出现，但它们不是一回事：

• TUN 接口是入口
• 隧道是运输方式

代理

代理的核心思路很直接：应用先访问一个中间人，再由这个中间人代它访问目标。

常见场景包括：

• 浏览器代理
• HTTP 代理
• SOCKS 代理
• Clash 普通代理模式

如果应用使用代理，链路会变成：应用先连代理，代理再连目标，最后把结果转回来。

代理和 VPN 容易被混在一起。代理主要改变的是应用怎么出去，它未必会改系统路由，也未必会接管整机流量。所以很多人会遇到这种情况：

• 浏览器能正常走代理
• 命令行工具却像完全没配置过

这通常说明，应用有没有主动把请求交给代理，差别很大。

VPN

VPN 常常会和代理放在一起说。它往往会把这些机制组合起来：

• 新的虚拟 IP
• TUN 接口
• 隧道
• 路由修改
• DNS 修改

最终效果是，设备在逻辑上接入了另一张网络。科研者访问实验室内网、公司内网、校园内网资源时，经常依赖这种能力。

企业零信任客户端也会用到同样的积木：

• TUN 接口
• 隧道
• 路由
• DNS

差别更多体现在策略层。传统 VPN 给更大的远端网络访问面，零信任会把授权范围收得更小。

辨析

三者常被混在一个图标里，但层次不同：隧道是一种运输方式，代理是一种应用侧转发关系，VPN 往往是多种机制打包后的产品名。

	隧道	代理	VPN
工作在	网络层附近（封装 IP 包）	应用层为主（HTTP/SOCKS 等）	系统网络层（路由 + 虚拟接口 + 隧道等组合）
核心动作	把内层包再包一层，经另一网络送到对端	应用主动连中间人，由中间人代连目标	让本机逻辑上接入另一张网，按策略转发流量
是否改路由表	本身不改；常配合 TUN/VPN 程序改	普通代理通常不改；TUN 模式会改	通常会改
典型例子	Cisco 把去 10.2.11.117 的包套进外层 IP 发往公司网关	浏览器走 127.0.0.1:7890，Clash 代为访问 github.com	宿舍拨入学校 VPN，获得 10.8.0.5，可访问 10.2.0.0/16
常见误区	有 TUN 就等于有隧道（TUN 是入口，隧道是封装方式）	开了 Clash 等于整机都能出国（普通模式只管配了代理的程序）	VPN 已连接等于所有流量都走 VPN（实际仍看路由命中哪条）

可以按“谁发起、改不改路由、包怎么长”来记：

• 代理：应用说“我把请求发给代理”。链路是 应用 → 代理 → 目标，很多工具默认不碰系统路由，所以 git、pip 容易漏网。
• 隧道：程序说“我把这个 IP 包再包一层发出去”。关心的是包怎么穿过公网，不关心浏览器有没有填代理地址。单独存在时用户较少直接感知，多嵌在 VPN/零信任里。
• VPN：系统说“去某网段的流量走虚拟网卡”。常见组合是 TUN 接口 + 隧道 + 路由（有时还有 DNS）。Cisco VPN、TrustAgent 更接近这一类；Clash TUN 模式也有 VPN 味，但策略上往往只管公网分流，不像企业 VPN 那样给一整张内网。

同一台机器上的分工示例：访问 github.com 可能走 Clash 代理或 en0；访问 10.2.11.117 则命中 10.2.11.117/32 -> utun9，包经 TrustAgent 隧道送到企业网——这里“代理”未参与，但“隧道”和“类 VPN 接入”都在起作用。

TLS

▸HTTP与HTTPS

HTTP → HTTPS（HTTP Secure）
具体含义：在 HTTP 协议基础上，通过 TLS（或早期的 SSL）进行加密传输
提供三大安全保障：

• 加密：防止窃听（中间人看不到明文内容）
• 身份认证：通过数字证书验证服务器身份
• 完整性：防止数据被篡改
  端口默认 443（HTTP 是 80），浏览器地址栏显示 🔒 锁形图标。

很多人以为连上目标 IP，事情就结束了。很多应用层连接还会继续用 TLS，它负责：

• 加密应用数据
• 校验证书
• 确认连接到的是预期服务

VPN 和 TLS 不冲突：

• VPN 保护的是网络通道
• TLS 保护的是应用会话

完全可以同时存在：

• 一条被 VPN 保护的路径
• 一个继续被 TLS 保护的 HTTPS 连接

TLS 发生在 TCP 连上之后、真正传网页/ API 数据之前。可以把它理解成：路（路由、VPN）已经通了，进门还要再核对一次“对面是不是真网站”，并把之后说的话打码传输。

▸浏览器打开 https://huggingface.co 时 TLS 在做什么

1. 前面的 DNS、路由、代理/VPN 已经把 TCP 连接建到对方 443 端口。
2. 浏览器和服务器先做 TLS 握手：协商加密方式、交换密钥。
3. 浏览器检查证书：是不是 huggingface.co 签发的、是否在有效期内、是否由可信机构签发。通过后才显示页面。
4. 之后的 HTTP 内容（登录 cookie、模型下载请求等）都在密文里传；中间路由器能看到你在连 huggingface.co，但看不到具体请求路径和正文。

没有 TLS 时（纯 HTTP）：同一 Wi‑Fi 下的其他人，理论上能嗅探到明文请求内容。所以科研站点、Git 拉代码、API 密钥交换几乎都要求 HTTPS。

和 VPN 的分工：VPN 像“先修一条到校内的专用通道”；TLS 像“进 Hugging Face 网站时，网站和你之间再加一把锁”。即使 VPN 已加密外层通道，HTTPS 仍会对应用数据再加密一层—。二者防的不是同一件事。

▸TLS 常见报错与粗测命令

• NET::ERR_CERT_DATE_INVALID / 证书过期：TLS 校验失败，和 DNS、路由无关，先查系统时间或站点证书。
• SSL: CERTIFICATE_VERIFY_FAILED（git clone / pip）：本机不信任对方证书链，或公司中间人代理替换了证书。
• 页面能打开但浏览器提示“连接不安全”：往往卡在 TLS 这一步，而不是“网不通”。

用命令粗看 TLS 是否在干活：curl -v https://github.com 2>&1 | grep -i "SSL connection"，能看到协议版本（如 TLSv1.3）和证书校验是否通过。

科研场景

放回科研场景里，把链路套到实际工作里，很多现象会清楚很多。

上网探索：查论文、下代码、拉模型、访问 Hugging Face / GitHub / 文档站。真正影响体验的，常常是：

• DNS 解析对不对
  • 例如 nslookup huggingface.co 一直超时，或解析出明显不对的内网 IP，页面会卡在“正在解析”；校园网和家里宽带的 DNS 服务器不同，同一域名两边结果不一样也常见。
  • 处理：先换公共 DNS 试（如 1.1.1.1、8.8.8.8），或在 Clash 里打开“远程 DNS / fake-ip”看是否改善；内网域名需连 VPN/零信任后再解析，或临时在 hosts 里写死正确 IP 验证是不是 DNS 层的问题。
• 请求有没有被代理接管
  • 浏览器能开 GitHub，终端里 git clone 却超时，多半是浏览器走了代理、命令行没配 http_proxy；反过来，只有终端设了代理而系统没设，也会出现“一边通一边不通”。
  • 处理：在终端里 export https_proxy=http://127.0.0.1:7890（端口按 Clash 实际配置改），git config --global http.proxy 同理；需要长期生效可写进 ~/.zshrc。不确定时可 curl -I https://github.com 和 curl -x http://127.0.0.1:7890 -I https://github.com 对比。
• Clash 是普通代理模式还是 TUN 模式
  • 普通模式只接管主动填了 127.0.0.1:7890 的程序；pip install、huggingface-cli download 若没走代理，仍会直连。TUN 模式则更像“整机换出口”，对不认代理字段的工具也管用，但和 VPN 抢路由时更容易乱。
  • 处理：只用浏览器时，普通模式 + 系统代理就够；pip/conda 经常挂，可开 TUN，或在 Clash 规则里把 pypi.org、huggingface.co 标成代理。和校园 VPN 同时用时，优先让 VPN 管内网网段、Clash 管公网，避免两边都改 default。
• 路由有没有把流量送到预期出口
  • 访问 github.com 应命中 default -> en0；若误把大段公网网段指进 utun9，会出现“代理/VPN 明明没开目标站，却绕远路或直接断掉”的情况。route -n get 8.8.8.8（macOS）或 ip route get 8.8.8.8（Linux）可以看出系统实际选了哪张接口。
  • 处理：对照路由表删掉多余条目（VPN 退出后残留的 utun 路由很常见）；Clash TUN 异常时先关 TUN 再测。目标站连不上时，对该站解析出的 IP 查路由，不要只看默认网关通不通。

访问实验室服务器：从宿舍或家里连实验室服务器时，真正要看的通常是：

• 目标服务监听了哪个端口
  • SSH 常见 22，Jupyter 常见 8888，TensorBoard 常见 6006。在服务器上 ss -lntp | grep 8888 能看到进程在不在；本机 nc -zv 10.2.11.117 8888 则测“这条路径上这个端口达不达得到”，两层要分开看。
  • 处理：服务只绑 127.0.0.1 时外网永远进不来，需改成 0.0.0.0（如 jupyter lab --ip=0.0.0.0 --port=8888）。服务器上 ss 有监听、本机 nc 仍失败，说明问题在路由/防火墙，而不是进程没起。
• 外网入口有没有打开
  • 机器在实验室内网、没有公网 IP 时，宿舍直连 10.2.11.117 往往根本到不了，必须先有 VPN/零信任隧道，或实验室网关在防火墙上做了端口映射。ping 不通公网 IP 不等于服务没起，可能只是根本没有对外入口。
  • 处理：无公网 IP 时先连 VPN/TrustAgent，再 ssh 内网地址；短期可用校内跳板机中转，或经导师申请端口映射/NAT。有公网 IP 但 ping 不通时，先确认运营商/学校是否禁 ping，改用 nc 或 curl 测具体端口。
• 防火墙和安全组有没有放行
  • 服务器本机 ufw、机房防火墙、云厂商安全组各管一段。常见情况是 jupyter 已在 0.0.0.0:8888 监听，但安全组没放行 8888，外网依旧连不上——进程正常，链路在更外层被挡。
  • 处理：服务器上 sudo ufw allow 8888/tcp 或关本机防火墙做对比测试；云主机在控制台安全组添加入站规则（来源 IP 尽量收窄到宿舍/办公室段）。Connection refused 偏本机没监听或被本机拒；长时间 timeout 偏中间防火墙丢包。
• 是否必须通过 VPN 或零信任通道进入
  • 很多实验室机器只接受来自 10.x 网段的访问。宿舍侧需先连 Cisco VPN 或 TrustAgent，路由里出现 10.2.0.0/16 -> utun8 之类规则后，ssh user@10.2.11.117 才有机会进到内网；没连通道就试 SSH，失败点往往在路由而不是密码。
  • 处理：先连 VPN/零信任，用 route -n get 10.2.11.117 确认走 utun 而非 en0，再 ssh -v 看卡在哪一步。仍失败时核对账号是否限源 IP、密钥是否过期，而不是反复改密码。

同时开多个网络工具：同时开 Clash、Cisco VPN、TrustAgent 时，最好脑子里有一张清晰的图：

• Clash 普通代理模式更靠近应用层
  • 只影响自己配置了代理的软件；系统级 ping、traceroute 不会自动走 Clash。适合“只想让浏览器和少数工具出国”的场景。
• Clash TUN 模式会下沉到系统网络层
  • 和 VPN 一样会动路由表，可能和 Cisco VPN 抢 default 或特定网段。开 TUN 后若校园内网访问异常，要先看路由是不是被 Clash 改写了。
• Cisco VPN 和 TrustAgent 常见的插法是接管 TUN 接口，再建立隧道
  • 各自占一个 utun 口，按路由表分流：公网走 en0，实验室 IP 走 utun9。图标栏三个都在线，不代表所有流量都经过同一个程序。
• 最后谁接管哪部分流量，核心还是 DNS、路由表和接口匹配顺序
  • 同一台机器访问 GitHub 和访问 10.2.11.117 可以走完全不同的路；排查时应对具体目标 IP 查 DNS 和路由，而不是只看“VPN 已连接”的状态灯。

▸Cloudflare WARP：关了 Clash，公网 IP 为什么还是“外网”

WARP 和 Clash 是两套独立程序。WARP 连接后会出现 CloudflareWARP 虚拟网卡，公网出口走 Cloudflare（常见 104.x 段 IP），不依赖 Clash 是否在运行。

典型误会：

• 只关了 Clash Verge 窗口，但 verge-mihomo.exe 仍在后台监听 7890；
• 同时 WARP 客户端显示 Connected，且可能开了 Always On；
• 此时查 IP 仍是 Cloudflare 出口，看起来像“代理没关干净”。

粗查：

• Windows：Get-NetAdapter 看有没有 CloudflareWARP；netstat -ano | findstr 7890 看 Clash 核心是否还在；
• WARP：warp-cli status（路径通常在 C:\Program Files\Cloudflare\Cloudflare WARP\）。

要恢复运营商宽带 IP：先在 WARP 里 Disconnect，并确认 Clash 选“退出”而非只关窗口（结束 verge-mihomo 进程），再查 (Invoke-RestMethod https://api.ipify.org?format=json).ip。

和 Cisco VPN / TrustAgent 的分工：WARP 主要改公网出口和 DNS，一般不像企业 VPN 那样下发 10.x 内网路由；实验室 10.2.11.117 仍要靠各自的 VPN/零信任，不能指望 WARP 替代。

排查顺序

理解这套链路以后，最大的变化通常是：知道应该从哪一层下手。

排查顺序通常是：

1. 先看 DNS
   • 对打不开的域名做 nslookup / dig：能解析出 IP 吗？IP 合理吗？校园内网域名在校外解析失败，往往说明缺企业 DNS 或 VPN 通道，而不是目标站宕机。
2. 再看路由
   • 对目标 IP 查路由：route -n get 10.2.11.117（macOS）看走 en0 还是 utun9。若应走 VPN 却走了 default，后面代理和 TLS 查得再细也连不上。
3. 再看默认网关和接口
   • ping 192.168.1.1（家用网关）或 ping 当前默认网关：网关都不通时，问题还在本地局域网；网关通但外网不通，再往 NAT/运营商侧想。
4. 再看代理、TUN、VPN 谁在接管
   • 对比浏览器与 curl -I https://github.com、curl -x http://127.0.0.1:7890 ... 的结果；再看 ifconfig / ip addr 里有哪些 utun 或 CloudflareWARP。弄清“这个请求到底有没有进 Clash / WARP / VPN”，避免在错误通道上查防火墙。
5. 再看 NAT、防火墙、安全组
   • 本机防火墙、路由器、云安全组逐段排除。Connection refused 多半是端口没监听或被本机拒绝；长时间 timeout 更像是中间某层丢包或未放行。
6. 最后看目标服务和 TLS
   • nc -zv 目标IP 端口 确认端口可达后，再测应用：curl -v 看 TLS 握手是否失败、证书是否过期。HTTPS 报证书错而 ping 正常，说明网络路径已通，问题在应用层。

到这一步，很多原本模糊的报错会开始有形状。排查不再是试运气。