![[截图 5：Clash 规则片段，突出显示新增的两行 DST-PORT 规则]](https://media.shuijingwanwq.com/2026/06/5-8.png)
![[截图 2：Play 商店更新界面，显示两个应用正常下载]](https://media.shuijingwanwq.com/2026/06/2-2-465x1024.jpg)
今天准备进入 WordPress 后台时，突然遇到了一个以前从未出现过的问题。
访问：
admin.shuijingwanwq.com/wp-admin/
Firefox 没有打开后台，而是直接提示：
PR_END_OF_FILE_ERROR
一开始看到“建立安全连接失败”，很容易把问题怀疑到服务器、Nginx 或 SSL 证书上。
但经过逐层排查，最后发现生产服务器完全正常，真正异常的是 Clash Verge / Mihomo 当前的代理分流状态：本应走国内直连的 admin.shuijingwanwq.com，竟然落入了最终的 MATCH 规则并走了代理。
最终，我没有给这个域名单独增加强制直连规则，也没有修改现有分流架构，而是更新 GeoData，并重启 Mihomo 内核。随后 WordPress 后台立即恢复正常。
这篇文章记录整个排查过程。
一、背景：现有规则原本就是“国内直连、国外代理”
我目前在 Ubuntu 桌面环境中使用 Clash Verge Rev。
现有分流方案并不是今天临时配置的，而是已经使用了一段时间，基本原则就是：
- 国内网站和国内 IP：直接连接；
- 国外网站：通过代理；
- 最后再由
MATCH处理没有被前面规则匹配到的请求。
这套配置此前已经正常使用。
我在 2026 年 7 月 6 日的 Clash Verge Rev 配置文章中，也已经记录过目前使用的这套规则和 DNS 配置：
因此，这次出现问题时有一个很重要的背景：
规则并没有刚刚修改过，而且这是第一次出现国内站点突然被错误送入代理的情况。
也正因为如此，后面排查时，我没有接受“给 admin.shuijingwanwq.com 单独增加一条 DIRECT 规则”作为最终解决办法。
那只能解决这一个域名，却不能解释为什么原本长期正常的国内直连机制突然失效。
二、故障现象：Firefox 提示 PR_END_OF_FILE_ERROR
打开 WordPress 后台：
admin.shuijingwanwq.com/wp-admin/
Firefox 显示：
建立安全连接失败
错误代码：
PR_END_OF_FILE_ERROR
PR_END_OF_FILE_ERROR】从浏览器表现来看，这时候只能知道 HTTPS/TLS 连接没有正常建立，还不能判断究竟是哪一层出了问题。
可能涉及：
- DNS；
- Clash Verge；
- 代理节点；
- 网络链路；
- Nginx；
- SSL 证书；
- PHP；
- WordPress。
所以第一步不是修改服务器，而是继续收集证据。
三、Clash Verge 日志暴露了真正的异常方向
打开 Clash Verge 的日志，并搜索：
admin.shuijingwanwq.com
马上发现大量 WARNING。
日志基本都是：
[TCP] dial Proxy (match Match) / 127.0.0.1:xxxxx --> admin.shuijingwanwq.com:443 error: context deadline exceeded
admin.shuijingwanwq.com 被 MATCH 规则发送到 Proxy】这里最关键的不是最后的：
context deadline exceeded
而是前面的：
dial Proxy (match Match)
这实际上已经说明：
admin.shuijingwanwq.com没有命中预期的国内直连规则，而是一路落入了最终的MATCH，随后被发送到了代理。
Mihomo 的 MATCH 本身就是无条件匹配剩余请求的兜底规则，因此如果前面的国内规则都没有命中，请求最终进入 MATCH → Proxy 是符合规则执行机制的。(虚空终端)
而我的这个后台域名对应的是自己的阿里云国内服务器：
121.40.248.29
正常情况下它没有必要通过国外代理节点访问。
到这里，排查方向已经开始从“服务器故障”转向“Clash Verge / Mihomo 分流异常”。
不过，仅凭代理日志还不足以证明服务器正常。
接下来需要从服务器侧验证。
四、服务器内部验证：Nginx、SSL 和 WordPress 都正常
我先登录阿里云服务器。
没有重启 Nginx，也没有修改 Nginx 配置，而是直接从服务器本机访问 admin.shuijingwanwq.com 对应的虚拟主机。
测试时将：
admin.shuijingwanwq.com:443
临时解析到：
127.0.0.1
这样可以直接进入本机 Nginx，同时继续保留正确的 Host 和 TLS SNI。
最终获得：
HTTP/2 302
server: nginx
location: https://admin.shuijingwanwq.com/wp-login.php?...
x-redirect-by: WordPress
strict-transport-security: max-age=15768000
x-robots-tag: noindex, nofollow, noarchive
HTTP/2 302】这一条结果其实一次性验证了很多东西：
- Nginx 正常运行；
admin.shuijingwanwq.com虚拟主机能够正确匹配；- 443 端口正常；
- TLS 握手正常；
- SSL 证书正常；
- PHP 可以处理请求；
- WordPress 正常运行；
/wp-admin/能够正常跳转到登录页面。
特别是：
x-redirect-by: WordPress
已经证明请求真正进入了 WordPress。
因此：
生产服务器本身基本可以排除。
五、本机绕过显式代理，再直接访问真实服务器 IP
服务器内部正常之后，我又从 ThinkPad 做了第二层验证。
首先，正常 DNS 查询时出现了：
198.18.0.50
同时 curl 也发现当前系统设置了：
https_proxy=http://127.0.0.1:7897
结合 Clash Verge 当前的 Fake-IP/TUN 环境，这种 198.18.x.x 地址本身不能简单认为是错误。Mihomo 的 Fake-IP 模式本来就会使用虚拟 IP 地址进行映射。(虚空终端)
所以接下来不再使用这个 Fake-IP，而是直接指定服务器的真实公网 IP：
121.40.248.29
执行：
curl --noproxy '*' -vkI \
--connect-timeout 10 \
--max-time 20 \
--resolve admin.shuijingwanwq.com:443:121.40.248.29 \
https://admin.shuijingwanwq.com/wp-admin/
121.40.248.29 直接验证后台 HTTPS】结果 TLS 握手完整成功：
SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
Server certificate:
subject: CN=admin.shuijingwanwq.com
并且成功建立 HTTP/2 连接。
这一步非常重要。
它说明：
ThinkPad 到阿里云服务器真实公网 IP 的网络链路也是正常的。
到这里，已经基本排除了：
- WordPress 故障；
- PHP 故障；
- Nginx 故障；
- SSL 证书故障；
- 阿里云 443 端口故障；
- 本地到服务器真实公网 IP 无法通信。
真正值得继续调查的，就只剩下 Clash Verge / Mihomo 当前的分流行为。
六、为什么我不想给 admin 增加一条强制 DIRECT
排查到这里，一个最简单的临时处理办法当然是增加：
DOMAIN,admin.shuijingwanwq.com,DIRECT
这样很可能立即解决问题。
但我并不想这么做。
因为这涉及另外一个更重要的问题：
如果我的现有规则本来应该实现国内直连，那么为什么今天突然失效了？
如果只是给 admin.shuijingwanwq.com 增加例外，那么解决的只是表象。
以后可能又出现：
abc.example.com
再增加一条 DIRECT；
另一个国内域名出问题，再增加一条 DIRECT。
最后本来应该由 GeoSite、GeoIP 等统一判断的规则体系，就会逐渐变成大量人工维护的例外规则。
这显然不是我想要的结果。
更重要的是：
当前这套规则以前一直是正常的，而这又是第一次出现这种现象。
所以相比“规则设计从一开始就有问题”，我更倾向先检查规则依赖的数据或者 Mihomo 当前的运行状态。
七、开始怀疑 GeoData 或 Mihomo 当前运行状态
Mihomo 的规则体系本身支持基于 GeoSite 和 GeoIP 对域名、目标 IP 等进行判断；针对目标 IP 的规则，域名请求在需要时还可以触发 DNS 解析，然后继续进行 IP 规则判断。(虚空终端)
Geo 数据则是这些判断的重要基础之一。Mihomo 也专门提供 Geo 数据模式、Geo 数据加载以及自动更新相关配置。(虚空终端)
由于：
- 原有规则没有修改；
- 以前一直正常；
- 今天第一次发生；
- 国内服务器域名突然直接落入
MATCH → Proxy；
我决定先不修改规则，而是尝试：
更新 GeoData。
当前 Clash Verge Rev 中可以直接进入：
设置 → 更新 GeoData
执行更新。
GeoData 很快更新成功。
但我没有到这里就直接判断问题一定已经解决。
更新完成以后，我又打开 Clash 内核管理界面。
八、更新 GeoData 后重启 Mihomo 内核
当前环境显示：
- Clash Verge Rev：v2.5.2；
- Mihomo：v1.19.29。
更新 GeoData 之后，我没有点击“升级内核”，而是直接执行：
重启内核
这里需要区分两个操作：
升级内核是改变 Mihomo 版本；
重启内核只是让当前 Mihomo 重新启动并重新加载现有配置和数据。
这次并没有必要引入新的软件版本变量。
所以整个恢复过程中实际上只做了两件事：
更新 GeoData
↓
重启 Mihomo 内核
没有修改：
- 现有代理规则；
GEOSITE规则；GEOIP规则；MATCH；- DNS 配置；
- Fake-IP 配置；
- TUN 配置；
- 代理订阅；
admin.shuijingwanwq.com专用规则；- WordPress；
- Nginx；
- SSL。
九、WordPress 后台恢复正常
完成 GeoData 更新以及 Mihomo 内核重启以后，我重新打开：
admin.shuijingwanwq.com/wp-admin/
这一次后台立即正常显示。
WordPress 仪表盘重新出现。
与此同时，再进入 Clash Verge 日志搜索：
admin.shuijingwanwq.com
之前不断产生的：
[TCP] dial Proxy (match Match) ... admin.shuijingwanwq.com:443 error: context deadline exceeded
也没有继续产生新的 WARNING。
问题至此恢复。
最重要的是：
整个过程中并没有给 admin 域名单独增加 DIRECT 规则。
原有的分流体系继续保持不变。
十、能不能直接下结论说“GeoData 坏了”？
虽然结果非常像：
国内直连异常
↓
更新 GeoData
↓
恢复正常
但这次我并不准备直接把根因写成：
GeoData 文件损坏。
原因是这次实际上连续执行了两个动作：
1. 更新 GeoData
2. 重启 Mihomo 内核
这两个变量是一起改变的。
所以目前至少存在两种可能。
第一种可能是：
原有 GeoData 本身或者当前 GeoData 状态出现异常，重新更新数据以后恢复。
第二种可能是：
Mihomo 当时加载的 GeoData、DNS、规则缓存或者其他运行时状态发生了一次偶发异常，重启内核重新加载后恢复。
当然，也可能两者共同参与。
因此，基于目前掌握的证据，我认为更加准确的结论应该是：
Clash Verge / Mihomo 的 GeoData 或规则运行状态发生了一次异常，导致原本应该国内直连的
admin.shuijingwanwq.com未命中前面的国内规则，最终落入MATCH → Proxy。更新 GeoData 并重启 Mihomo 内核之后恢复正常。
这样既符合实际现象，也没有把尚未完全证明的推测写成确定事实。
十一、如果以后再次出现，我会把两个恢复动作拆开
这次因为是第一次碰到这个问题，所以更新 GeoData 以后顺手又重启了 Mihomo。
这样虽然很快恢复了，但也留下了一个遗憾：
无法严格判断究竟是哪一个动作真正解决了问题。
如果以后再次发生完全相同的现象，我会改变排查顺序。
首先观察 Clash Verge 日志。
如果发现一个本来应该直连的国内地址出现：
dial Proxy (match Match)
并且已经证明真实服务器本身正常，那么第一步只做：
重启 Mihomo 内核
然后重新测试。
如果恢复：
更偏向 Mihomo 当时的运行状态或数据加载状态异常。
如果仍然异常，再执行：
更新 GeoData
然后重新测试。
如果这时候才恢复：
GeoData 本身出现异常的可能性就会明显增大。
这样下一次就可以真正把：
内核运行状态
和：
GeoData 数据状态
两个变量拆开验证。
十二、这次排查带来的几个经验
1. PR_END_OF_FILE_ERROR 不一定意味着服务器 SSL 出问题
浏览器最开始显示的确实是 HTTPS 安全连接失败。
但最终证明：
- SSL 证书正常；
- TLS 1.3 握手正常；
- Nginx 正常；
- WordPress 正常。
真正的问题发生在代理分流链路。
所以遇到这类错误，不能仅凭浏览器错误名称就去重新签发证书或者修改 Nginx。
2. Clash Verge 的 match Match 日志非常关键
这次真正改变排查方向的是：
dial Proxy (match Match)
因为 MATCH 是最终兜底规则。(虚空终端)
对于一个原本应该国内直连的请求，如果它一路掉到了：
MATCH → Proxy
说明真正值得调查的是：
为什么前面的国内规则没有命中？
这比单纯看到：
context deadline exceeded
更有诊断价值。
3. 不要看到 Fake-IP 就马上判断 DNS 错了
第一次检查时：
admin.shuijingwanwq.com
→ 198.18.0.50
看起来非常奇怪。
但结合 Clash Verge/Mihomo 的 Fake-IP 环境，这类地址本身并不意味着公网 DNS 把域名真的解析到了 198.18.x.x。Mihomo 的 Fake-IP 模式本身会维护这样的虚拟地址映射。(虚空终端)
真正的源站 IP：
121.40.248.29
仍然可以单独验证。
4. 能验证根因时，不要急着添加例外规则
如果这次一开始就添加：
DOMAIN,admin.shuijingwanwq.com,DIRECT
后台大概率也能恢复。
但我可能永远不会注意到：
原有国内直连机制实际上已经出现异常。
“网站能打开”和“问题真正解决”并不是一回事。
特别是一套长期维护的代理规则，应该尽量保证整体逻辑正确，而不是不断堆积单站例外。
5. 服务器没有问题时，就不要因为代理故障去动生产环境
这次服务器侧已经连续证明：
- Nginx 正常；
- SSL 正常；
- WordPress 正常；
- 公网 443 正常。
所以整个处理过程中最终没有：
- 重启生产服务器；
- 修改 Nginx；
- 修改 WordPress；
- 清理 WordPress 缓存；
- 重新申请 SSL 证书。
这也避免了为了修复一个客户端代理问题，反而给正常运行的生产环境引入新的风险。
十三、最终故障链路
把整个过程压缩以后，故障状态大致可以表示为：
Firefox
↓
admin.shuijingwanwq.com
↓
Clash Verge / Mihomo
↓
未命中国内直连规则
↓
MATCH
↓
Proxy
↓
连接超时
↓
PR_END_OF_FILE_ERROR
而服务器真实状态则是：
ThinkPad
↓
121.40.248.29:443
↓
TLS 1.3
↓
Nginx
↓
WordPress
↓
HTTP/2 302
↓
正常
最后的恢复过程则非常简单：
更新 GeoData
↓
重启 Mihomo 内核
↓
重新加载数据和运行状态
↓
admin.shuijingwanwq.com 恢复访问
↓
不再产生原来的 Proxy WARNING
十四、总结
这次故障最初表现得很像 WordPress 后台或者 HTTPS 出问题：
PR_END_OF_FILE_ERROR
但真正排查以后发现：
服务器始终是正常的，异常发生在 Clash Verge / Mihomo 的代理分流链路。
最关键的证据是 Clash Verge 日志中的：
dial Proxy (match Match)
一个原本应该走国内直连的后台域名，没有命中预期规则，而是最终进入 Proxy。
由于当前规则以前一直稳定运行，而且这是第一次出现相同问题，我没有选择给 admin.shuijingwanwq.com 增加专用 DIRECT 规则，而是优先检查规则依赖的数据与 Mihomo 的运行状态。
最终：
更新 GeoData → 重启 Mihomo 内核
之后问题立即恢复。
目前还没有足够证据证明一定是“GeoData 文件损坏”，因此更严谨的记录是：
本次故障很可能与 Clash Verge/Mihomo 的 GeoData 或规则运行状态异常有关。更新 GeoData 并重启 Mihomo 后恢复，原有“国内直连、国外代理”规则无需修改。
这次排查也让我更加确定一个原则：
当一套长期正常运行的规则第一次出现异常时，先验证运行状态和规则依赖的数据，再决定是否修改规则本身。
否则，一个临时的 DIRECT 虽然能够让网页立即打开，却也可能把真正值得解决的问题藏起来。
🚀 推荐 VPS（WireGuard / Clash / 自建 VPN 专用）
本系列方案推荐使用 Vultr VPS 作为基础服务器环境：
✔ 支持 WireGuard / Clash / VPS 架构部署
✔ 全球多机房节点可选
✔ 稳定适合长期运行的网络服务
👉 点击访问 Vultr（推荐注册入口）
💡 新用户优惠说明
Vultr 官方可能会针对新用户提供一定的试用额度或促销活动，例如：
– 最高可能获得 $300 新用户测试额度
– 用于 VPS 部署与测试用途
– 是否生效取决于 Vultr 官方活动规则及账户条件
⚠️ 不同地区、时间或账户类型可能存在差异。
⚠️ 重要说明
本站提供的链接为 Vultr 官方联盟推广链接，用于推荐 VPS 服务。
所有优惠活动均由 Vultr 官方提供与解释，本网站不保证所有用户均可获得相同促销权益。
拒绝反复折腾｜专属 WireGuard VPN 远程部署与优化服务
本系列长期记录 WireGuard、Clash、VPS、DNS、Linux 网络环境和 AI 工具访问优化等实践。如果你不想反复踩坑、折腾服务器与协议配置，可以联系我做一次远程排查或专属方案部署。
适合以下用户：
✅ ChatGPT、Claude、Gemini 等 AI 工具使用者
✅ 海外远程办公用户
✅ 技术学习与开发环境访问需求
✅ 不想长期折腾 VPS 与代理配置的用户
✅ 希望拥有专属节点而非公共机场的用户
服务内容：
✅ 远程代搭建：在你自己的服务器上部署专属 WireGuard VPN，数据完全掌控。
✅ 免费试用：可申请免费试用我的自建节点，再决定是否继续。
✅ 分流优化：针对 AI 工具、开发环境及日常使用进行优化。
✅ 问题排查：协助排查连接失败、速度慢、DNS 异常、规则配置等常见问题。
如需了解方案或申请试用，请直接联系我，并注明：VPN 咨询。
联系方式：
Telegram：@shuijingwan
微信：13980074657
邮箱：shuijingwanwq@gmail.com
发表回复