计算机网络- iStoreOS域名解析时好时坏问题

type

status

date

slug

summary

解决iStoreOS下域名解析与端口转发不稳定问题的踩坑实录

一、问题背景

作为一名长期折腾家庭网络的玩家，最近在使用 iStoreOS 系统的 Lucky 插件时，遭遇了一系列 DNS 解析和 DDNS 配置问题，从域名解析到错误 IP、公网 IP 检测混乱，再到服务无法访问，踩了不少坑。今天把这些问题的排查过程和解决方案整理出来，希望能帮到有同样困扰的朋友。

二、排查过程

一、初遇问题：域名解析 “飘忽不定”，服务访问频繁失败

最开始发现问题时，是通过域名访问自家服务（如 NAS、Web 站点）时，时而能打开，时而提示 “无法连接”。起初以为是网络波动，直到查看/var/log/dnsmasq.log日志，才发现了异常 —— 我的域名www.niub.plus竟然解析出多个不同 IP：

有时返回正确的公网 IP 220.192.131.220；

有时返回陌生 IP 141.11.77.140、103.235.17.62；

甚至偶尔会解析到198.18.0.x这类 IANA 预留的测试网段 IP。

这就导致客户端随机连接到错误 IP，自然无法稳定访问服务。初步判断是 DNS 解析环节出了问题，但具体是哪里的问题，还需要一步步排查。

二、排坑第一步：定位 DNS 解析异常的 “真凶”

💡

排除 dnsmasq 自身配置问题

最开始怀疑是 iStoreOS 自带的 dnsmasq 服务配置错误，于是查看/etc/dnsmasq.conf和/etc/config/dhcp配置文件，发现上游 DNS 指向的是运营商默认 DNS（221.7.92.98、221.5.203.98）。为了验证是否是运营商 DNS 缓存问题，临时将上游 DNS 改为阿里云公共 DNS（223.5.5.5、223.6.6.6），并执行killall -HUP dnsmasq清除缓存。

但多次执行nslookup www.niub.plus后，发现解析结果依然混乱，有时正确有时错误。这说明问题不在 dnsmasq，而是有其他服务在 “干扰” DNS 解析。

💡

分析DNS解析日志

虽然dnsmasq状态正常，但域名解析可能存在问题。尝试开启dnsmasq的debug模式查看解析日志：

当域名访问异常时，执行tail -f /var/log/dnsmasq.log查看日志。发现所有域名解析都被转发到127.0.0.1#7874这个本地端口，但没有该端口的响应记录，这说明上游DNS服务（监听7874端口的程序）失效或未运行。log如下：

在Clash中找到DNS劫持选项，将其禁用。

等待一会之后，果然还是不行，依旧无法正常访问。

三、排坑第二步：DDNS 公网 IP 检测 “混乱”，解析地址不匹配

解决了 DNS 解析问题后，发现域名虽然不再指向错误 IP，但偶尔会出现 “域名解析 IP 与路由器 WAN 口 IP 不一致” 的情况。查看 Lucky 的 DDNS 日志，发现其使用的 IP 检测接口返回了多个不同 IP，比如：

https://ddns.oray.com/checkip返回54.223.109.249；

https://4.ipw.cn返回123.58.10.198；

https://v4.66666.host:66/ip返回123.58.10.198 lucky666.cn；

而我的路由器 WAN 口真实 IP 是220.192.131.220。

这就导致 DDNS 频繁将域名更新到错误 IP，服务依然无法访问。

锁定 Lucky 插件的域名解析异常

我之前从未考虑过域名解析会出问题，因为如果域名解析如果存在问题，它不会一会正常一会异常，直到我手动触发同步之后，发现每次结果都不一样，且存在规律：多次解析总会大概率是正确的IP，所以会造成时好时坏的假象。

💡

分析 IP 检测接口 “混乱” 的原因

新版本的lucky中，手册建议使用接口方式获取公网地址；如下

深入排查后，发现接口返回异常主要有 4 类原因：

（1）部分接口 “失效”，返回非请求者 IP

比如https://www.taobao.com/help/getip.php，这是淘宝早期的测试接口，目前已失效，返回的是淘宝 CDN 节点的内网 IP，而非我的公网 IP；https://v4.66666.host:66/ip这类非知名第三方接口，代码逻辑存在 bug，误将自身服务器 IP 当作请求者 IP 返回。

（2）CGNAT 导致接口无法获取真实公网 IP

我的家用宽带使用了运营商的 CGNAT（运营商级 NAT），路由器 WAN 口的220.192.131.220其实是 “大内网 IP”，而非真正的互联网公网 IP。此时 IP 检测接口只能识别到运营商的 “出口公网 IP”（如123.58.10.198），无法穿透 CGNAT 获取我路由器的真实 IP。

（3）接口数据格式错误，Lucky 解析失败

比如http://v4.ip.zxinc.org/getip返回的是 “IP + 地区” 格式（如220.192.131.220 江苏苏州电信），而 Lucky 只能解析纯文本 IP，误将 “江苏苏州电信” 当作 IP 处理，进而触发重新检测，调用其他接口返回不同 IP。

（4）接口缓存 / 负载均衡，返回历史 IP

部分接口为了降低压力，会缓存之前的检测结果。比如https://ddns.oray.com/checkip，若其他用户曾通过该接口检测过54.223.109.249，缓存未过期时会直接返回这个历史 IP，而非我的真实 IP。

💡

2. 解决 DDNS IP 检测问题的实战方案

修改获取公网方式为通过网卡获取，关联拨号WAN口，测试发现可以稳定正确获取到公网IP，至此，完美解决。