从今年 3 月以来，在 mac 上使用魔法的时候，总是出现所有代理节点全部超时的情况。而且在重启等方法恢复正常之后，只要开着机从宿舍走到二教，节点又都全部超时了。经过一番排查，发现问题不是代理垃圾，也不是 DNS 设置或者 interface-name 等参数问题，而是校园网认证状态只通过了 IPv6 出口，IPv4 出口被认证网关拦截了。具体的原因可能和我学习 PKU VPN 3 - 用校内服务器实现 PKU 内网和 Clash/Surge 兼容使用 ↗，使用了 Tailscale 转发 IPv4 请求到校内服务器有关，导致我在访问 its.pku.edu.cn 认证页时，IPv4 请求被转发到内网的 Tailscale 服务器上了，而不是直接访问校园网认证网关。下面是我详细的排查过程和解决办法，由于我并没有系统学过计算机系统和网络相关知识，因此大部分内容和判断都是和 GPT-5.5 讨论得到的。供有类似问题的同学参考。
现象#
失败但有启发的排查过程#
首先我根据学长的建议，检查了一下网卡参数
networksetup -listallhardwareports
route -n get default结果显示 Wi-Fi 是 en0，默认路由也是 en0，是合理的。
但代理测试失败：
curl -I -x http://127.0.0.1:7890 https://www.google.com同时 Clash 日志里出现大量：
i/o timeout
connect: operation timed out当我使用
lsof -nP -iTCP -sTCP:LISTEN | grep -Ei 'mihomo|clash|party'时，发现 Clash 并没有在监听 7890 等端口。
GPT-5.5 认为可能是内核的问题，让我重启内核
osascript -e 'quit app "Clash Party"'
open -a "Clash Party"结果也不 work，但是 Clash 没有监听 7890 了，说明问题不一定在 Clash 本身，可能是网络本身哪里出了问题.
尤瑞卡！#
curl -6 https://www.baidu.com是正常的，但是
curl -4 https://www.baidu.com就超时了。说明 IPv6 出口是正常的，而 IPv4 是有问题的。由于 Clash 的节点走 IPv4，节点就会全部超时了。
GPT-5.5 指导我使用以下命令检查是否是 IPv4 的网关被拦截：
curl --noproxy '*' -4 http://captive.apple.com/hotspot-detect.html如果正常联网，会返回：
<HTML><HEAD><TITLE>Success</TITLE></HEAD><BODY>Success</BODY></HTML>当时返回的是 PKU 认证跳转：
https://its.pku.edu.cn/?cause=unauthN...说明 IPv4 出口还被校园网认证网关拦截。由于 Clash 的节点走 IPv4，节点就会全部超时。所以问题的根源是校园网认证状态失效了。
临时解决办法#
先关闭系统代理，再打开认证页登录：
http://captive.apple.com/hotspot-detect.html登录成功后恢复代理，即可发现节点全部正常了。
长期解决办法#
绕开系统代理#
如果不想每次都这么麻烦一遍，可以把校园网认证入口加入 macOS 的代理绕过列表，让认证页始终直连：
networksetup -setproxybypassdomains "Wi-Fi" \
127.0.0.1 \
192.168.0.0/16 \
172.16.0.0/12 \
localhost \
'*.local' \
'*.crashlytics.com' \
'<local>' \
captive.apple.com \
its.pku.edu.cn这样系统代理仍然保持开启，但访问 captive.apple.com 和 its.pku.edu.cn 时会直连，不会经过 Clash。
注意我没有加入：
*.pku.edu.cn因为这会让所有 PKU 域名都绕过代理，范围太大。
让认证相关域名直连#
也可以在 Clash 的规则覆写里，在 pku.edu.cn 的前面添加以下规则：
+rules:
- DOMAIN,its.pku.edu.cn,DIRECT
- DOMAIN-SUFFIX,pku.edu.cn,🎓 北京大学这样在使用魔法时，访问 its.pku.edu.cn 就会直接走直连，不会经过 Tailescale 了。以后切换 Wi-Fi 后可以直接打开认证页登录，不需要手动关闭系统代理了。
验证#
认证成功后检查：
curl --noproxy '*' -4 http://captive.apple.com/hotspot-detect.html看到 Success 说明 IPv4 已经放通。
再测试 Clash：
curl -I -x http://127.0.0.1:7890 https://github.com
curl -I -x http://127.0.0.1:7890 https://www.google.com能返回 200 就说明代理恢复正常。
总结#
这次故障的本质是校园网 IPv4 认证状态失效。Clash 本地端口和 Wi-Fi 网卡参数都正常。长期方案是让认证相关域名直连，这样以后切换 Wi-Fi 后可以直接打开认证页登录，不需要手动关闭系统代理。