![[截图 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)
此前我曾经整理过一篇与当前 v4 配置有关的实践记录。
那篇文章对后续维护这套配置比较重要，因为它记录了一个低频 DNS 解析异常从出现、定位到调整的过程。不过，后来根据相关要求，那篇中文文章已经停止公开提供，目前原地址返回 HTTP 404。
关于当时为什么调整部分中文文章，以及网站最终采用了怎样的处理方式，我已经在另一篇文章中单独做过记录：
这一次并不是恢复原来的文章，也不是重新发布原文。
我希望重新整理一篇更简洁的技术记录，以目前电脑中实际长期使用的 v4 配置为基准，保留真正还有参考价值的部分。
更重要的一点是：
当时偶尔出现的 DNS 解析超时问题，在完成 v4 调整并持续使用一段时间之后，目前已经没有再出现。
因此，现在重新回顾这次调整，已经不仅仅是记录一次配置尝试，也多了一段后续实际运行结果作为参考。
一、为什么重新整理这篇文章
此前相关记录的地址是：
https://www.shuijingwanwq.com/2026/07/06/19005/
目前访问这个地址，会看到页面已经停止提供，并返回 HTTP 404。
虽然旧文章已经不再公开，但其中记录的 v4 配置后来一直保留在我的实际使用环境中。
经过后续持续使用，我没有再遇到当时那种每隔几天偶尔出现一次的 DNS 解析超时。
因此我认为，这部分配置仍然值得重新整理。
不过，这一次文章的重点有所变化。
旧记录更偏向：
出现异常
↓
查看日志
↓
定位 DNS 解析
↓
调整配置
↓
继续观察
而现在重新整理，更偏向：
回顾实际使用中的 v4
↓
说明 v3 与 v4 的差异
↓
解释为什么只进行小范围调整
↓
记录长期使用结果
这也更符合目前这套配置的实际状态。
二、配置开始同步维护到 GitHub
这一次还有一个比较重要的变化。
以前博客文章本身承担了不少配置记录功能。如果文章发生调整，后续再回头寻找某个历史版本会比较麻烦。
因此从现在开始，这套配置会同步维护在 GitHub：
目前仓库已经包含：
metacubex-v1.yaml
metacubex-v2.yaml
metacubex-v3.yaml
metacubex-v4.yaml
其中：
metacubex-v4.yaml
是目前最新稳定版本。
以后如果继续发现需要优化的地方，我会优先更新 GitHub 仓库，再根据实际情况同步博客。
如果你也在参考这套配置，建议收藏 GitHub 仓库。
相比某一篇固定文章，仓库更适合作为后续版本更新和历史配置查询的长期入口。
三、当时的问题现在已经没有再出现
v3 在正常使用过程中整体已经比较稳定。
不过，当时我观察到一个非常低频的现象：
某些网站偶尔会出现短暂的 DNS 解析超时。
它并不是持续发生。
当时的表现大概是：
- 平时正常使用；
- 可能隔两三天才出现一次；
- 出现后等待几秒或者十几秒；
- 再次访问通常又能恢复。
当时查看日志，也曾经出现类似：
dns resolve failed
all DNS requests failed
context deadline exceeded
因此，当时继续检查的重点逐渐转向 DNS 配置。
不过这里需要特别说明：
这个问题目前已经没有再出现。
v4 调整完成以后，我继续正常使用这套配置，到现在没有观察到原来的低频 DNS 超时再次出现。
当然，这并不能严格证明某一条配置就是唯一原因。
实际网络环境本身也会变化，DNS 服务状态、线路质量以及客户端版本都可能影响最终表现。
因此我更愿意把现在的结果描述为：
v4 调整以后，在我的实际使用环境中，原来观察到的低频 DNS 超时目前没有再出现。
四、v4 没有重新设计整套配置
当时遇到这个问题以后，我并没有大幅修改已有结构。
这是整个 v4 最重要的思路。
v3 已经可以满足日常使用。
如果为了一个两三天才偶尔出现一次的问题，重新设计全部 DNS 配置，反而可能引入更多变量。
所以 v4 没有调整：
- WireGuard 节点结构；
- Wstunnel 使用方式；
- 主要分流规则；
GEOSITE与GEOIP的整体结构；- v3 已经验证过的规则顺序。
真正发生变化的主要还是：
dns:
这一部分。
简单来说，就是：
保留原有方案，只给几个可能形成单点的位置增加备用能力。
五、v3 的 DNS 配置有什么特点
v3 中的 DNS 配置比较简单。
nameserver 只有一个 DoH：
nameserver:
- https://dns.alidns.com/dns-query
fallback 也只有一个 DoT：
fallback:
- tls://1.1.1.1:853
同时没有显式配置：
default-nameserver
平时这些配置完全可以正常工作。
但如果某一个解析入口在某个时刻响应变慢，就可能产生一次短暂的解析异常。
因此，v4 并没有增加很多复杂规则，而只是针对几个位置增加备用项。
六、改动一：增加 default-nameserver
v4 首先增加：
default-nameserver:
- 223.5.5.5
- 119.29.29.29
这里主要用于处理 DoH、DoT 服务自身域名的基础解析。
例如：
dns.alidns.com
doh.pub
它们本身也是域名。
在访问对应的 DoH 服务以前，需要先完成这些域名自身的解析。
因此增加两个基础解析入口，可以让这一层的依赖关系更加明确。
这并不是重新建立一套 DNS 体系，只是在原有配置中增加一个很小的基础兜底。
七、改动二：nameserver 增加备用 DoH
v3：
nameserver:
- https://dns.alidns.com/dns-query
v4：
nameserver:
- https://dns.alidns.com/dns-query
- https://doh.pub/dns-query
也就是在原有阿里公共 DoH 的基础上，再增加腾讯 DoH。
这样做的目的很简单：
避免整个 nameserver 只依赖一个解析入口。
一个 DNS 服务长期稳定，并不意味着它永远不会出现一次短暂延迟。
既然当时的问题本身就是低频偶发现象，那么增加一个备用解析入口，比重新设计大量规则更加符合这次调整的目标。
八、改动三：fallback 增加备用 DoT
v3：
fallback:
- tls://1.1.1.1:853
v4：
fallback:
- tls://1.1.1.1:853
- tls://8.8.8.8:853
也就是说，在 Cloudflare DoT 的基础上，再增加 Google DoT。
思路与 nameserver 类似：
尽量避免单一解析入口成为唯一依赖。
这里也没有继续增加第三个、第四个甚至更多服务。
因为 v4 的目的不是把配置变得“大而全”，而是在不明显增加维护复杂度的情况下，为已有配置增加适量冗余。
九、v3 与 v4 的变化其实非常小
直接对比两个版本的 DNS 部分，可以看到新增内容非常有限。
主要就是三处：
1. 增加 default-nameserver
2. nameserver
从 1 个 DoH 增加到 2 个
3. fallback
从 1 个 DoT 增加到 2 个
除此之外，整体结构仍然沿用 v3。
这也是我比较喜欢这次修改的地方。
很多时候，配置维护并不是功能越多越好。
如果现有方案已经稳定，那么为了一个低频问题一次增加大量规则，很容易让以后排查问题变得更加困难。
相比之下，小范围修改更容易判断实际效果。
十、目前实际使用的 v4 DNS 配置
当前 v4 中的 DNS 部分如下：
dns:
# 用于解析 DoH / DoT DNS 服务器自身域名
default-nameserver:
- 223.5.5.5
- 119.29.29.29
# 主要 DoH，并增加一个备用入口
nameserver:
- https://dns.alidns.com/dns-query
- https://doh.pub/dns-query
# 沿用现有 Proxy 组
proxy: Proxy
# DoT 备用解析
fallback:
- tls://1.1.1.1:853
- tls://8.8.8.8:853
fallback-filter:
geoip: true
geoip-code: CN
文章这里主要展示 DNS 部分。
完整配置统一维护在 GitHub：
https://github.com/shuijingwan/clash-config
这样以后如果继续出现 v5、v6，就不需要依赖某一篇博客保存最新配置。
十一、为什么没有继续增加更多 DNS 设置
实际上还可以继续增加很多配置项。
例如：
- 更多
nameserver； - 更多
fallback； nameserver-policy；- 其他 DNS 工作模式；
- 针对特定域名增加单独的解析策略。
但我目前仍然没有这样做。
原因是现在已经没有实际问题推动这些修改。
v4 调整以后，原来偶尔出现的 DNS 超时目前没有再观察到，日常使用也比较稳定。
在这种情况下，再继续增加配置，收益并不明确，维护成本却一定会上升。
所以目前仍然坚持一个原则：
只在实际问题出现以后进行有针对性的小范围调整，不为了让配置看起来更加复杂或者更加完整而不断增加项目。
十二、从 v1 到 v4，我越来越倾向于渐进维护
回头看整个过程，其实每一个版本的变化都不算大。
v1 建立基础结构。
v2 开始完善 DNS 配置。
v3 调整一处规则顺序。
v4 则只是给 DNS 增加几个备用入口。
没有哪一个版本进行大规模重构。
但这种方式反而比较适合长期维护：
先建立可以工作的基础配置
↓
实际使用
↓
遇到明确问题
↓
只修改相关部分
↓
继续观察
↓
确认稳定后保留
到目前为止，v4 已经经过了一段时间的实际使用。
当时最希望改善的低频 DNS 超时也没有再出现。
因此我暂时不会继续修改它。
如果以后出现新的、能够稳定复现的问题，再考虑是否需要进入 v5。
十三、后续更新以 GitHub 仓库为准
这次重新整理文章，还有一个目的，就是逐渐把“博客记录”和“配置维护”分开。
博客更适合解释：
- 为什么这样修改；
- 当时观察到了什么；
- 修改思路是什么；
- 后续实际效果如何。
GitHub 则更适合保存：
- 当前稳定版本；
- 历史版本；
- 配置文件；
- 后续版本变化。
仓库地址：
如果后续这套配置继续调整，我会同步更新这个仓库。
如果这套配置对你有参考价值，可以收藏 GitHub 仓库。后续版本会继续在这里维护。
十四、总结
这次重新整理 v4，并不是因为现在又出现了新的 DNS 问题。
恰恰相反：
当时偶尔出现的 DNS 解析超时，目前已经没有再出现。
重新写这篇文章，一方面是因为此前相关记录已经停止公开提供，而这部分技术实践仍然有保存价值；另一方面，也是希望把当前实际运行中的稳定配置重新形成一份更简洁、更容易长期维护的记录。
v4 最核心的变化只有三项：
增加 default-nameserver
nameserver 增加备用 DoH
fallback 增加备用 DoT
不调整整体结构，也不为了一个低频问题进行大规模重构。
经过后续持续使用，目前原来的低频 DNS 超时没有再次观察到。
因此现阶段，我会继续保持 v4 不变。
后续如果出现真正需要处理的新问题，再继续记录下一次小范围调整。
而从这一篇开始，最新配置也会持续维护在 GitHub：
https://github.com/shuijingwan/clash-config
如果希望继续关注后续版本，建议收藏这个仓库。
🚀 推荐 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
发表回复