适合已经导入订阅、节点可以连接,但遇到部分域名打不开或国内网站访问变慢的 macOS 用户。先区分系统解析与内核解析,再配置直连 DNS、远程 DNS 和域名规则,最后用终端与日志核对实际路径。本文以 v2rayN 使用 Xray 内核的配置思路为主;切换内核后,应重新核对 DNS 字段,不能直接照搬配置。
一、DNS 分流先分清三条路径
DNS 的任务是把域名转换成 IP 地址。v2rayN 是客户端,真正执行连接与部分解析工作的是所选内核。浏览器、macOS 系统解析器、内核内置 DNS 都可能参与同一次访问;只改其中一处,不代表所有请求都会走新设置。
上面是应用把域名交给代理时的简化流程。若应用先在本机解析,代理收到的可能只有 IP;若域名由代理服务端解析,本机内核则不一定发出目标域名的 DNS 查询。因此,日志里没有某个域名的查询记录,不一定表示配置没有生效。
- 解析器选择:国内域名交给直连解析器,需要代理的域名交给远程解析器。
- DNS 传输路径:查询本身从直连还是代理出口发出,需要单独核对。
- 业务连接路径:拿到地址后,网页连接仍由路由规则决定走向。
二、直连 DNS 与远程 DNS 怎么填写
先打开 v2rayN 的「设置」→「DNS 设置」,并在「设置」→「参数设置」核对当前内核。不同版本和内核的字段可能不同;若界面按内核分别配置 DNS,应修改正在使用的那一组。保存原配置副本,再改解析器,避免同时调整路由、TUN 和 IPv6。
| 用途 | 可用于起步的示例 | 必须核对的条件 |
|---|---|---|
| 直连 DNS | 223.5.5.5 | 当前网络可达;普通 DNS 查询通常不加密 |
| 直连 DoH | https://dns.alidns.com/dns-query | 内核支持该格式;端点域名可完成引导解析 |
| 远程 DoH | https://dns.google/dns-query | 查询按预期走代理;TLS 验证与系统时间正常 |
这些是公开服务的地址示例,不是每种网络下的速度排名。起步时每类保留一个明确可达的解析器即可。一次填入很多地址会增加回落与并发查询的复杂度,也让日志更难定位。企业内网、校园网或需要本地域名解析的网络,应保留对应的内部解析路径。
端口号用于识别传输方式,不代表本机已经监听这些端口。v2rayN 的代理监听端口与 DNS 监听端口是不同设置;不要把 HTTP 或 SOCKS 代理端口直接填进 macOS 的 DNS 服务器列表。
三、geosite 规则要同时照顾解析与连接
geosite 是域名分类数据,geoip 是 IP 分类数据。二者不是解析器,也不会自动提供 DNS 服务。以 Xray 为例,路由中的 geosite:cn 可以用于匹配国内域名;内置 DNS 的服务器条目也可以通过 domains 指定优先处理的域名集合。两处用途相关,但不能互相替代。
- 先检查规则数据。确认当前内核能加载所用的域名与 IP 数据,日志没有文件缺失或分类不存在的错误。分类内容会变化,不应把它当成永远准确的地理边界。
- 设置直连解析范围。将
geosite:cn对应域名优先交给直连 DNS;内部域名用单独规则处理,避免发送到公共解析器。 - 设置远程解析范围。将需要代理的域名交给远程 DNS;若使用
geosite:geolocation-!cn,先确认数据中存在该分类。它是分类集合,不是对所有非国内域名的实时判断。 - 核对业务路由。国内域名走直连,需要代理的域名走代理。Xray 路由规则按顺序匹配,将明确的域名规则放在可能抢先命中的宽泛规则之前。
- 检查回落策略。域名未命中、响应为空或地址不符合预期时,查询可能转给其他服务器。若要求某类域名不使用直连 DNS,就必须同时审查其回落范围。
Xray 的 routing.domainStrategy 控制路由阶段是否借助解析结果匹配 IP 规则。AsIs 不会为 IP 规则主动解析域名;IPIfNonMatch 会在域名规则未匹配时尝试解析后再匹配。它与 DNS 模块里的 queryStrategy 不是同一个开关,后者主要涉及查询地址族等行为。
结论:先命中域名规则,再排查 IP 规则
某个网站走错出口时,先查它是否命中预期域名分类及规则顺序。只有业务确实需要按 IP 判断时,再调整路由阶段的解析策略,不要用更换 DNS 掩盖路由错误。
四、DoH 防污染与引导解析怎么处理
DoH 把 DNS 查询放入 HTTPS 连接,能够保护到解析器这一段传输,降低途中被读取或篡改的风险。它不保证解析器给出的答案一定正确,也不隐藏连接目的 IP。若浏览器启用了独立的安全 DNS,还可能绕过内核中配置的解析器。
- 引导解析:访问
dns.google这类域名端点前,连接的一方需要先知道端点地址。若解析端点本身又依赖这个尚未连通的 DoH,就会产生循环依赖。 - 节点域名:代理节点若使用域名,也需要在代理建立前完成解析。不要把节点域名的唯一解析路径设置成依赖该节点才能访问的服务。
- 证书验证:macOS 打开「系统设置」→「通用」→「日期与时间」,核对自动设置时间。证书错误应查时间、端点名称和网络拦截,不要通过关闭验证绕过。
- 出口安排:远程解析器若需通过代理访问,应在对应内核支持的 DNS 传输与路由配置中明确安排,并用日志确认;不能仅凭字段名判断。
不建议为了省去引导解析,直接把 DoH 地址的主机名随意改成 IP。HTTPS 还涉及证书名称与服务端虚拟主机。只有解析服务明确支持该 IP 端点时,才使用其公布的地址格式。
五、FakeDNS 什么时候需要开启
FakeDNS 不是另一个公共 DNS 服务。它为域名分配合成 IP,并在流量再次进入内核时,将该 IP 映射回原域名。这样即使应用后续只提交 IP,内核仍有机会按域名分流。它常用于配合透明接管,但不是开启 TUN 就必须启用。
| 对比项 | DoH | FakeDNS |
|---|---|---|
| 主要目的 | 加密传输真实 DNS 查询 | 保留域名与合成 IP 的对应关系 |
| 返回结果 | 解析器提供的真实地址记录 | 由本地映射池生成的地址 |
| 关键前提 | 端点可达、证书有效、出口正确 | 查询和后续连接都被配套机制处理 |
| 常见故障 | 引导解析失败、连接超时 | 合成 IP 逃逸到直连、缓存映射失配 |
只使用系统代理、浏览器已经把域名交给代理时,通常先保持 FakeDNS 关闭。若 TUN 场景中应用先解析、域名规则因此失效,再检查当前内核与客户端是否提供完整的 DNS 接管和映射支持。切换内核时,应重新验证,不能假定实现细节相同。
结论:先验证接管链路,再启用 FakeDNS
先确认 DNS 查询进入预期处理路径,再确认合成地址对应的连接不会绕过客户端。启用后若只有部分应用断网,优先检查缓存、绕过规则与映射,而不是立即更换节点。
六、macOS 上按顺序验证解析与代理
每次只改一组设置。保存后重新启动内核,观察启动日志是否报错,再进行下列测试。命令中的域名用于演示;测试故障网站时替换为该网站的主机名。不要把订阅地址、节点凭据或完整连接配置贴进公开日志。
- 查看系统 DNS。运行
scutil --dns,检查当前网络、VPN 或其他网络服务配置了哪些解析器。它展示系统解析配置,不直接展示 Xray 内置 DNS 的全部状态。 - 测试指定解析器。运行下面的
dig命令,判断该解析器在当前网络是否有响应。这一步不等于验证 v2rayN 的 DNS 分流。 - 测试代理连接。先核对「设置」→「参数设置」中的本地监听端口与协议,再执行代理请求。示例假定
10808提供 HTTP 或混合代理;若实际只有 SOCKS 服务,不要照用 HTTP 写法。 - 核对内核日志。对照同一测试时段,检查目标域名、命中的路由、出站选择及 DNS 超时。必要时临时提高日志级别,测试结束后恢复。
# 查看 macOS 系统解析器
scutil --dns
# 直接询问指定解析器,2 秒超时,仅尝试 1 次
dig @223.5.5.5 www.baidu.com A +time=2 +tries=1
# 仅在 10808 提供 HTTP 或混合代理时使用
curl -I --proxy http://127.0.0.1:10808 \
--connect-timeout 10 --max-time 20 https://www.example.com/
若监听端口支持 SOCKS5,可再比较下面两条命令。第一条通常在本地解析目标域名,第二条把域名交给 SOCKS 代理。第二条成功、第一条失败时,优先检查本地解析路径;但仍需结合日志,排除地址族差异或站点连接限制。
# 本地解析目标域名
curl -I --proxy socks5://127.0.0.1:10808 \
--connect-timeout 10 --max-time 20 https://www.example.com/
# 将目标域名交给 SOCKS 代理
curl -I --proxy socks5h://127.0.0.1:10808 \
--connect-timeout 10 --max-time 20 https://www.example.com/
调整后仍得到旧结果时,先退出并重新打开测试应用。确需清理 macOS 系统 DNS 缓存时,可在终端运行以下命令;第二条需要管理员权限。它们不清除浏览器独立缓存、内核缓存或上游解析器缓存。
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
七、DNS 分流常见问题
改成 DoH 后,为什么所有网站都变慢了?
先恢复原解析器,确认是否恢复正常。再检查 DoH 端点的引导解析、代理出口与超时日志。国内域名若也交给远程解析器,可能得到不适合当前直连出口的地址;应将国内域名解析与业务连接一起分流,而不是只换一个 DNS 地址。
dig 正常,浏览器还是打不开,说明什么?
dig @223.5.5.5 只证明这次向指定解析器的查询有响应。浏览器可能使用独立安全 DNS,也可能存在系统代理或扩展冲突。先用上面的显式代理命令复测,再核对浏览器代理与安全 DNS 设置。
国内网站解析到境外 IP,一定是污染吗?
不一定。CDN 调度、解析器位置和业务部署都可能影响结果。分别向直连与远程解析器查询同一域名,并比较连接是否成功、路由是否符合预期。不同答案不能单独作为污染证据,也不建议直接把某次结果长期写进 hosts。
有 A 记录却连接超时,要关闭 IPv6 吗?
先分别查询 A 与 AAAA,再比较 curl -4 和 curl -6 的结果。经代理测试时,地址族还可能由代理端决定,不能据此直接判断本机 IPv6。确认是哪条 IPv6 路径失败后,再调整对应查询或出口策略,避免一次关闭整个系统功能。
安卓端可以照搬这套 DNS 配置吗?
分流原则可以参考,配置不能直接照搬。v2rayNG 使用 Xray 内核,v2flyNG 使用 v2fly 内核;客户端的 VPN 接管、DNS 入口和支持字段需要分别核对。迁移时先验证单个域名、单个解析器,再增加分类规则与回落策略。
最终验收看三件事:国内域名使用预期的直连解析路径,需要代理的域名没有意外回落到直连解析,业务连接命中正确出口。保留一份可以正常工作的配置,再逐项增加 DoH、IPv6 或 FakeDNS,后续出现问题时才有明确的回退点。