F50 + OpenList统一访问方案/低维护的个人 NAS 访问体验

局域网内不建议继续解析到公网地址再“绕回”设备，否则可能受 NAT Loopback、Hairpin、IPv6 回环等限制影响。更稳妥的办法是在设备上运行 AdGuard Home，并对 OpenList 域名做内网 DNS 重写。

连接设备 Wi‑Fi 时：
openlist.example.com
        ↓
客户端 DNS = 设备地址（如 192.168.0.1）
        ↓
AdGuard Home DNS 重写
        ↓
返回设备局域网可达地址
        ↓
Lucky :443 → OpenList

推荐做法：可以用 CNAME 指向一个专门的内网别名（例如 lan-openlist.example.com），再让内网别名解析到局域网 IPv4/IPv6；这样逻辑更清晰，也方便单独维护。

IPv4-only 外网访问

(F50测试NAT类型为NAT4，端口持续变化，F50上没成功)

实际部署时应根据网络条件选择一种稳定的 IPv4 公网入口

• 真正可入站的公网 IPv4 + 端口映射。

• FRP / 反向隧道 / 中继节点。

• 支持自定义域名的公网穿透服务。

• 其他能提供稳定双向 TCP 的 IPv4 入口。

最终统一转发到 Lucky HTTPS 入口即可。

IPv4-only 客户端
        ↓
openlist.example.com（A 记录 / IPv4 入口）
        ↓
稳定 IPv4 公网入口
        ↓
Lucky :443
        ↓
OpenList

踩坑：STUN 能探测到公网映射，并不等于该映射适合长期 Web 服务。若 NAT 类型在 NAT3/NAT4 间变化、端口持续变化，或出现“TCP Connected 但 HTTP/TLS 数据无法稳定返回”，就不应将 STUN 映射作为正式公网入口。

代理软件TUN兼容配置

启用 TUN / Fake-IP 后，OpenList 域名可能被代理内核接管 DNS，获得 198.18.0.0/16 之类的 Fake-IP，进而破坏 AdGuard Home 的局域网 Split DNS。解决方法是：OpenList 域名强制 DIRECT，同时从 Fake-IP 中排除。

YAML配置示例

dns:
  ipv6: true
  enhanced-mode: fake-ip
  fake-ip-filter:
    - “openlist.example.com”
  nameserver-policy:
    “openlist.example.com”：
      - system

rules:
  - DOMAIN,openlist.example.com,DIRECT

JavaScript配置示例

const dnsConfig = {
  "ipv6": true,
  "enhanced-mode": "fake-ip",
  "fake-ip-filter": [
    "openlist.example.com",
    "+.lan",
    "+.local"
  ],
  "direct-nameserver-follow-policy": true,
  "nameserver-policy": {
    "openlist.example.com": ["system"]
  }
};

const rules = [
  "DOMAIN,openlist.example.com,DIRECT",
  // 其余规则……
];

连接设备 Wi‑Fi 时，system DNS 可以命中 AdGuard Home 的内网重写；切到其他网络时，又会使用该网络的正常 DNS，获得公网地址。

视频播放自动化兼容脚本（上一篇，点击跳转）