Loon的DNS模块并不是简单地把所有域名都交给一个公共DNS就完事。移动网络的DNS查询通常发生在代理隧道建立之前，解析结果的正确性会直接决定后续规则能否命中、CDN是否就近、以及部分网站是否会因为DNS污染而打不开。所谓DNS分流，就是按域名、按网络环境或按策略组，把不同类型的解析请求交给不同的DNS服务器处理。
一、DNS分流要解决的核心问题
如果Loon中只设置一个全局DNS，比如运营商DNS或223.5.5.5，境外域名很容易被投毒或返回错误IP。此时即使代理线路正常，也可能因为规则匹配前就拿到错误解析而无法连通。反过来，如果全局都使用8.8.8.8或DoH，虽然境外解析变干净，但大量国内网站会被调度到海外CDN节点，造成图片加载慢、视频卡顿，甚至部分App提示网络异常。
DNS分流的核心思路是：国内域名和本地服务交给国内公共DNS或系统DNS解析，境外域名交给不易被污染的公共DNS，或者直接交给代理服务器远端解析。Loon提供多种方式实现这个目标，包括基础dns-server列表、fallback-dns-server回退、policy-dns策略解析，以及基于Host的精确指定。理解这些配置的职责边界，是配置稳定分流的前提。
另外，移动网络下还有一个容易被忽略的问题：系统DNS缓存和IPv6返回顺序。即使Loon已经配置了正确的DNS，系统或App仍可能使用旧的IPv6地址发起连接，导致分流看起来时好时坏。因此在开始配置前，建议把这类环境因素一并纳入考虑。
二、dns-server与fallback-dns-server怎么选
Loon配置文件的[General]区域中，dns-server用于处理大多数常规解析。通常可以写成系统DNS加国内公共DNS的组合。使用system的好处是，移动网络切换时运营商下发的DNS会自动变化，但缺点是某些运营商DNS可能夹带广告或存在污染。更推荐显式指定国内公共DNS，例如阿里巴巴的223.5.5.5和腾讯的119.29.29.29。它们的响应速度在国内较快，也能避免部分运营商DNS的篡改。
fallback-dns-server用于主DNS不可用、返回异常或需要更干净结果的场景。很多用户会在这里配置DoH地址，例如https://1.1.1.1/dns-query或https://dns.google/dns-query。当主DNS返回的IP被判定为无效或查询超时，Loon会改用回退DNS重新解析。这个机制特别适合国内公共DNS偶尔抽风，或者某些境内DNS对境外域名返回假地址的情况。如果设备或网络环境对DoH不友好，也可以改用DoT，例如tls://1.1.1.1，它使用853端口。Loon会根据写法自动选择对应协议。
[General] dns-server = system, 223.5.5.5, 119.29.29.29 fallback-dns-server = https://1.1.1.1/dns-query, https://dns.google/dns-query hijack-dns = *:53
上面配置中的hijack-dns用于接管系统发出的53端口DNS查询，让没有主动适配代理DNS的App也能被正确分流。如果不开启，部分App可能仍走系统默认DNS，导致分流规则形同虚设。需要注意的是，DoH地址在Loon中直接写完整URL即可，查询会走加密通道，运营商无法看到域名内容。
policy-dns用于更细粒度的策略解析，常常配合[Rule]中的某些扩展字段使用。它与fallback-dns-server的区别在于，fallback是全局查询失败后的兜底，而policy-dns可以被规则按条件引用。例如你希望某条代理规则下的域名强制使用特定DoH，可以单独声明一个策略DNS，再让规则指向它。普通用户如果规则中未使用相关参数，policy-dns可以先不配置，但了解它的存在有助于看懂他人的配置模板。
三、用Host精确控制单个域名解析
全局DNS只能做粗粒度分流，实际使用中常常需要对某个域名单独指定解析服务器。Loon的[Host]区域就承担这个任务。它的基本语法是每行写一个域名，后面跟上server:加DNS地址，或者直接写IP地址。被Host命中的域名，查询优先级高于全局dns-server。
例如，某些海外流媒体服务的DNS结果会影响地区判断，可以单独指定一个海外DoH。反过来，局域网内的NAS、路由器管理页面则可以直接绑定内网IP，避免每次通过公共DNS解析或走代理。
[Host] # 指定域名单独走阿里DNS api.example.cn = server:223.5.5.5 # 指定域名走Cloudflare DoH media.ippipp.com = server:https://1.1.1.1/dns-query # 本地设备直接映射内网地址 nas.local = 192.168.1.200
Host配置的优点是非常直观，适合在手机上快速排查某个域名的问题。但不建议把所有域名都塞进Host，否则配置文件会变得冗长，维护成本也会上升。更好的做法是，Host只处理例外域名，大部分域名继续交给dns-server和规则体系自动分流。
还需要注意，直接映射IP虽然能绕过DNS查询，但只适用于IP固定的服务。如果对方使用CDN或频繁更换IP，写死IP反而会造成访问失败。对于运行在家庭宽带的动态公网服务，应该优先使用DDNS域名，再配合Host指定解析服务器，而不是硬编码IP。
四、让规则与DNS解析形成联动
Loon的DNS分流最终要和规则匹配配合，否则解析得再准确也无法走对代理。规则区域使用[Rule]，常见类型包括DOMAIN、DOMAIN-SUFFIX、IP-CIDR、GEOIP和FINAL。一个典型的移动端规则可能是：国内常见域名走直连，境外域名走代理，局域网网段直连，兜底规则走代理。
[Rule] DOMAIN-SUFFIX,baidu.com,Direct DOMAIN-SUFFIX,apple.com,Direct DOMAIN-SUFFIX,google.com,Proxy IP-CIDR,192.168.0.0/16,Direct FINAL,Proxy
当Loon收到一个连接请求时，会先判断是否已有缓存解析结果，如果域名需要代理转发，可以不在本地暴露解析过程，而是交给代理服务器远端解析。这个行为的好处是，本地ISP完全看不到你访问了哪些境外域名；坏处是，如果代理服务器本身的DNS服务差，也可能返回不合适的IP。此时可以结合Host强制给关键域名指定DoH，让本地解析后再送代理连接。
如果遇到规则匹配正确但连接失败的场景，优先检查解析结果是否指向了被墙IP或错误CDN。可以用Loon的日志查看请求匹配到了哪个策略，再确认对应DNS返回的IP是否合理。调整规则时，尽量避免把大段国内域名错误放进代理策略，否则国内CDN会明显变慢。
五、验证配置效果与常见排错
配置完成后，不要只看Loon界面显示已连接。需要实际验证DNS分流是否按预期工作。最简单的办法是在Safari中访问一个能显示当前解析IP的网站，例如1.1.1.1的帮助页面，观察返回的DNS服务器归属地。对国内域名，可以搜索IP归属地查询或使用运营商提供的测速工具，确认解析到了本地CDN节点。
手机端还可以使用一些网络诊断App，输入域名后选择Loon的DNS查询功能，看返回IP与未开启代理时是否不同。尤其是境外域名，如果开启Loon后仍然返回一个明显属于境内的IP，很可能fallback-dns-server没有生效，或者请求被系统DNS缓存干扰。
常见问题包括：只改了dns-server，没开hijack-dns，导致部分App仍走系统DNS；IPv6优先级过高，拿到IPv6地址但连接不稳定；DoH地址书写错误；Host中域名重复但写法冲突。遇到问题时，可以先把IPv6关闭，再在Loon中清空DNS缓存并重启代理。使用fallback-dns-server时，尽量保留一个国内DoH和一个海外DoH，避免单点故障。
最后建议把最终配置导出保存。Loon支持通过文本编辑和导入配置，在家庭Wi-Fi、移动数据、公司网络之间切换时，可以根据网络环境微调DNS服务器。一个经过验证的DNS分流配置，配合合理的规则和代理策略，通常能明显改善移动端的整体访问体验。