Mac M1 上 v2rayN 提示“中国大陆证书问题访问不了”：一次真实排障复盘
2026-05-30
一、问题背景
在 Mac M1 / Apple Silicon 设备上安装 v2rayN 后，用户反馈访问部分网站失败，v2rayN 提示类似：
中国大陆有证书问题，访问不了。
很多人第一反应会认为是“证书坏了”“系统证书不对”“网站证书异常”。但从实际排查过程看，这类问题不一定真是证书问题。
这次案例的真实原因是：
v2rayN 主程序启动了 xray / sing-box 核心也启动了 但 macOS 系统代理没有启用 而且实际代理端口不是默认的 10809 / 10808 同时 DNS 解析也存在异常
所以最终表现出来像是 TLS / SSL / 证书问题，但底层真正的问题是：
系统流量没有进入 v2rayN 代理，而是在直连；直连时 DNS 又解析异常，导致 TLS 握手超时。
二、先看现象：为什么看起来像“证书问题”？
执行检测脚本时，直连访问 https://www.google.com 出现了：
SSL connection timeout curl: (28) SSL connection timeout
这句话非常关键。
它不是：
SSL certificate problem certificate verify failed unable to get local issuer certificate
如果是上面这类报错，才更像是系统证书链、根证书、目标证书或者中间人证书问题。
但本次是：
SSL connection timeout
这说明连接已经到了 TLS 握手阶段，但握手一直没有完成，最后超时。
通俗说就是：
不是证书校验失败，而是连到一个不正常的目标之后，TLS 握手卡住了。
三、第一处异常：DNS 解析不正常
检测结果里，www.google.com 被解析成了：
157.240.7.20
这个结果明显不正常。
157.240.x.x 更像 Meta / Facebook 相关 IP 段，不应该是 Google 常规解析结果。
同时 curl 里还出现了：
IPv6: 2001::1 IPv4: 157.240.7.20
这说明当前网络环境下 DNS 解析有较大概率存在以下情况之一：
1. DNS 污染 2. 路由器 / 热点 DNS 异常 3. 上游 DNS 不可靠 4. 网络链路对特定域名做了错误解析
DNS 解析错了之后，浏览器或者 curl 就会连到错误的 IP。连到错误 IP 后，TLS 握手自然容易失败、卡住、超时。
所以这里的第一条判断是：
直连链路不可靠，DNS 已经异常。
四、第二处异常：v2rayN 默认代理端口没有监听
检测脚本默认测试了两个常见端口：
HTTP 代理端口：10809 SOCKS5 代理端口：10808
但是检测结果显示：
127.0.0.1:10809 没有监听 127.0.0.1:10808 没有监听
随后通过 curl 测试代理访问：
curl -Iv -x http://127.0.0.1:10809 https://www.google.com
返回：
Connection refused Failed to connect to 127.0.0.1 port 10809
再测 SOCKS5：
curl -Iv --socks5-hostname 127.0.0.1:10808 https://www.google.com
同样返回：
Connection refused Failed to connect to 127.0.0.1 port 10808
Connection refused 的含义非常直接：
这个端口上没有程序在接收连接。
也就是说，不是节点不通，也不是远端服务器拒绝，而是本机 127.0.0.1:10809 / 127.0.0.1:10808 这两个代理端口根本没开。
五、第三处异常：v2rayN 核心其实启动了，但监听的是另一个端口
继续检查进程：
ps aux | grep -Ei "v2ray|v2rayn|xray|sing-box|mihomo|clash" | grep -v grep
可以看到：
v2rayN 主程序已启动 sing-box 已启动 xray 已启动
这说明 v2rayN 不是完全没运行。
再看监听端口：
lsof -nP -iTCP -sTCP:LISTEN | grep -Ei "108|789|2017|2080|9090|v2ray|xray|sing|clash|mihomo"
发现实际监听的是：
xray TCP 127.0.0.1:59022 (LISTEN)
这一步直接把问题定位清楚了：
你以为代理端口是 10809 / 10808 但真实监听端口是 59022
所以之前拿 10809 / 10808 测代理，当然会失败。
六、第四处异常：macOS 系统代理没有启用
继续检查 macOS 系统代理：
networksetup -getwebproxy Wi-Fi networksetup -getsecurewebproxy Wi-Fi networksetup -getsocksfirewallproxy Wi-Fi
结果显示：
Enabled: No Server: 127.0.0.1 Port: 15236 Enabled: No Server: 127.0.0.1 Port: 15236 Enabled: No Server: 127.0.0.1 Port: 15235
这里有两个关键信息。
第一，Enabled: No：
系统代理没有启用
第二，系统记录的旧端口是：
15235 / 15236
但实际 xray 监听的是：
59022
这说明系统代理配置和 v2rayN 当前实际监听端口完全错位。
最终状态就是：
v2rayN 核心在跑 但 macOS 系统流量没有走它 浏览器 / curl / 系统请求仍然在直连 直连 DNS 又异常 于是表现为 SSL / TLS / 证书类错误
一句话概括：
代理核心在旁边跑着，但系统流量没有进代理通道。
七、正确排查命令清单
1. 查看 v2rayN / xray / sing-box 是否运行
ps aux | grep -Ei "v2ray|v2rayn|xray|sing-box|mihomo|clash" | grep -v grep
如果没有任何输出，说明 v2rayN 或核心没起来。
如果能看到：
v2rayN xray sing-box
说明主程序和核心至少已经启动。
2. 查看本机实际监听端口
lsof -nP -iTCP -sTCP:LISTEN | grep -Ei "108|789|2017|2080|9090|v2ray|xray|sing|clash|mihomo"
重点看类似：
127.0.0.1:59022 (LISTEN)
这个端口才是当前真实代理端口。
不要死盯 10809 / 10808，因为 v2rayN 可能会动态生成或使用其他端口。
3. 测试这个端口是 HTTP 代理还是 SOCKS5 代理
假设实际监听端口是 59022，先测 HTTP：
curl -Iv -x http://127.0.0.1:59022 --connect-timeout 10 --max-time 20 https://www.google.com -o /dev/null
再测 SOCKS5：
curl -Iv --socks5-hostname 127.0.0.1:59022 --connect-timeout 10 --max-time 20 https://www.google.com -o /dev/null
判断规则：
HTTP 那条成功：59022 是 HTTP 代理端口 SOCKS5 那条成功：59022 是 SOCKS5 代理端口 两条都失败：核心配置、节点、端口类型或入站配置可能有问题
4. 查看 macOS 系统代理状态
networksetup -getwebproxy Wi-Fi networksetup -getsecurewebproxy Wi-Fi networksetup -getsocksfirewallproxy Wi-Fi
如果你不是用 Wi-Fi，可以先查看网络服务名称：
networksetup -listallnetworkservices
常见结果：
USB 10/100/1000 LAN Wi-Fi iPhone USB Thunderbolt Bridge
如果当前网络是 Wi-Fi，就继续用 Wi-Fi。
八、修复方法一：在 v2rayN 里开启系统代理
最推荐先用图形界面操作。
打开 v2rayN，找到类似选项：
设置系统代理 自动配置系统代理 开启系统代理 Set system proxy System Proxy
开启后，再执行：
networksetup -getwebproxy Wi-Fi networksetup -getsecurewebproxy Wi-Fi networksetup -getsocksfirewallproxy Wi-Fi
看到：
Enabled: Yes
才说明系统代理真的打开了。
如果仍然是：
Enabled: No
那说明 v2rayN 没有成功写入 macOS 系统代理配置。
九、修复方法二：手动设置 macOS 系统代理
如果确认 59022 是 SOCKS5 代理端口，可以执行：
sudo networksetup -setsocksfirewallproxy Wi-Fi 127.0.0.1 59022 sudo networksetup -setsocksfirewallproxystate Wi-Fi on
验证：
networksetup -getsocksfirewallproxy Wi-Fi
正常应该显示：
Enabled: Yes Server: 127.0.0.1 Port: 59022
如果确认 59022 是 HTTP 代理端口，可以执行：
sudo networksetup -setwebproxy Wi-Fi 127.0.0.1 59022 sudo networksetup -setsecurewebproxy Wi-Fi 127.0.0.1 59022 sudo networksetup -setwebproxystate Wi-Fi on sudo networksetup -setsecurewebproxystate Wi-Fi on
验证：
networksetup -getwebproxy Wi-Fi networksetup -getsecurewebproxy Wi-Fi
正常应该显示：
Enabled: Yes Server: 127.0.0.1 Port: 59022
十、修复方法三：处理 DNS 异常
本次日志里 DNS 也明显不正常，所以建议把 DNS 改成更稳定的公共 DNS。
执行：
sudo networksetup -setdnsservers Wi-Fi 1.1.1.1 8.8.8.8
然后清理 DNS 缓存：
sudo dscacheutil -flushcache sudo killall -HUP mDNSResponder
重新测试：
dig www.google.com
如果 DNS 结果仍然异常，说明当前网络链路本身可能存在 DNS 污染或拦截。这时候更要先保证系统代理真正生效。
十一、如何判断已经修好？
1. 系统代理启用
networksetup -getwebproxy Wi-Fi networksetup -getsecurewebproxy Wi-Fi networksetup -getsocksfirewallproxy Wi-Fi
至少对应协议要看到：
Enabled: Yes Server: 127.0.0.1 Port: 正确端口
2. 代理端口有监听
lsof -nP -iTCP -sTCP:LISTEN | grep -Ei "v2ray|xray|sing|59022|108|789"
要看到类似：
127.0.0.1:59022 (LISTEN)
3. 通过代理访问成功
HTTP 代理测试：
curl -Iv -x http://127.0.0.1:59022 https://www.google.com -o /dev/null
或者 SOCKS5 测试：
curl -Iv --socks5-hostname 127.0.0.1:59022 https://www.google.com -o /dev/null
如果看到：
HTTP/2 200 HTTP/1.1 200
或者没有 TLS 超时报错，说明代理链路基本正常。
十二、这类问题的排查模型
以后遇到 v2rayN、Clash、sing-box、xray 类似问题，不要一上来就重装。
按这个顺序排：
第一步：程序是否启动 第二步：核心是否启动 第三步：本地端口是否监听 第四步：系统代理是否开启 第五步：系统代理端口是否和实际监听端口一致 第六步：DNS 是否异常 第七步：通过代理 curl 是否成功 第八步：再考虑证书问题
很多所谓“证书问题”，本质并不是证书坏了，而是：
DNS 解析错了 系统代理没开 端口配错了 代理核心没监听 系统流量没走代理
十三、本次案例最终结论
本次问题不是典型证书问题。
真实原因是：
1. v2rayN 主程序已启动； 2. xray / sing-box 核心也已启动； 3. 但默认检测端口 10809 / 10808 没有监听； 4. 实际监听端口是 127.0.0.1:59022； 5. macOS 系统代理处于 Disabled； 6. 系统代理记录的端口还是旧的 15235 / 15236； 7. 当前 DNS 解析也异常； 8. 所以浏览器和 curl 仍然直连，导致 TLS 握手超时； 9. 最终表现成类似“证书问题”。
一句话总结：
v2rayN 不是没运行，而是系统流量没有接入它；修复重点不是重装证书，而是确认本地监听端口、开启系统代理，并修正 DNS。
发表评论: