Synology DSM918 HTTPS访问异常求助（路由直连设备故障）

这问题我之前帮朋友排查过好几个类似的，结合你给出的排查信息（PC2无线网桥能正常访问、PC1直连仅能用内网IP、SSL握手失败），大概率是路由器的**NAT回环（Hairpin NAT）**配置缺失，或者是本地DNS/端口转发的细节没处理到位，给你拆解几个优先级从高到低的排查方向：

1. 优先检查路由器的NAT回环（Hairpin NAT）功能 #

简单来说，当你在路由器内网用公网域名访问NAS时，路由器需要把原本发向公网IP的请求，重新转发回内网的NAS设备——这个机制就是NAT回环。很多家用路由器默认关闭这个功能，而无线网桥可能处于路由器的另一个网段（比如网桥自身做了NAT），或者路由器对网桥的流量没做限制，所以PC2能正常访问。

• 操作步骤：登录路由器管理后台，找「NAT设置」「端口转发」「高级网络」这类菜单，看看有没有「Hairpin NAT」「内网回流」「Loopback NAT」的开关，直接开启它。
• 如果你的路由器没有这个选项，那可以用本地DNS劫持的替代方案：在路由器的DNS设置里，把你的域名映射到NAS的内网IP，这样内网设备访问域名时会直接解析到内网地址，绕开公网回环。

2. 验证本地DNS解析是否正确 #

有时候问题出在DNS解析上，PC1访问域名时可能解析到了公网IP，但路由器没做回环导致请求卡住；或者解析出的IP根本不对。

• 执行命令排查：在PC1的终端里运行 nslookup <你的域名> 或者 dig <你的域名>，看返回的IP是NAS的公网IP还是内网IP？
  • 如果是公网IP：那回到第一步，确认NAT回环是否开启；
  • 如果是错误的IP：清空PC1的DNS缓存（Windows用 ipconfig /flushdns，Mac用 sudo dscacheutil -flushcache），再重新解析试试。
• 临时测试：修改PC1的hosts文件，手动添加一行 <NAS内网IP> <你的域名>，然后再执行 curl https://<你的域名> -v，如果能正常访问，那说明问题确实出在DNS解析或NAT回环上。

3. 检查端口转发与防火墙规则 #

确保路由器的端口转发和防火墙没有限制内网设备的访问：

• 端口转发规则：确认HTTPS端口（默认443）的转发规则是「公网IP:443 → NAS内网IP:443」，并且没有设置源IP限制（比如不要只允许外网IP段访问，把内网IP段排除在外）。
• 路由器防火墙：有些路由器默认会拦截内网设备访问自身公网IP的请求，防止环路，但这会影响回环访问。找防火墙规则里的「内网到公网」选项，看看有没有阻止443端口的规则，临时禁用或者添加允许内网IP访问公网IP 443端口的规则。

4. 抓包定位SSL握手异常点 #

既然你怀疑路由器导致SSL报文异常，可以通过抓包来确认问题环节：

• 在PC1上执行抓包命令：tcpdump -i any port 443 -w pc1_capture.pcap（Windows可以用Wireshark可视化抓包）
• 在NAS上开启SSH后执行抓包命令：tcpdump -i any port 443 -w nas_capture.pcap
• 发起curl请求后停止抓包，对比两个文件：
  • 如果PC1发送的Client Hello报文没出现在NAS的抓包里：说明路由器没把请求转发到NAS，是端口转发或NAT回环的问题；
  • 如果NAS回复了Server Hello但PC1没收到：说明路由器的回程转发有问题；
  • 如果报文都正常但握手失败：可能是NAS的SSL配置（比如证书、加密套件）有问题，但PC2能访问的话这个概率很低。

5. 排查路由器固件兼容性 #

有些低端路由器的NAT回环实现有bug，或者对SSL报文的分片处理存在问题，导致握手失败。可以尝试：

• 升级路由器到最新官方固件；
• 临时换一个路由器测试，看PC1是否能正常访问，以此排除路由器硬件/固件的问题。

内容的提问来源于stack exchange，提问作者Jozef Lang