我每天都会通过浏览器直接访问第三方网站，或者通过我开发的 JavaScript 应用程序请求文件。今天早上，我与该网站的连接速度非常慢，以至于我的大部分请求都超时了。
我做了一些测试，我可以通过我的 WIFI 网络正常访问该网站，但无法通过 LAN 访问。我的 WIFI 网络只是一个连接到 LAN 的 WIFI 接入点，因此两者都使用相同的子网和网关。我在多台计算机上都遇到了同样的问题，而且似乎只与这个网站有关。我访问过的其他网站都没有问题。
我完全被搞糊涂了。我们打电话给了该站点的技术支持，他们说这肯定是我们这边的问题，因为他们的所有诊断都检查无误。
为什么特定域只能在 WIFI 接入点上运行，而不能在 LAN 本身上运行？
答案1
如果 Wi-Fi AP 充当 NAT 网关（假定其 WAN 端口插入上游路由器的 LAN 端口），则它可能以不同的方式执行 DNS，或者它在 TCP MSS 限制方面可能比上游 NAT 网关做得更好。
至于 DNS，假设您的上游 NAT 网关在向有线以太网客户端提供 DHCP 租约时，会告诉客户端使用 DNS 服务器 A。支持您的 Wi-Fi AP 在向 Wi-Fi 客户端提供 DHCP 租约时，会告诉客户端使用 DNS 服务器 B。现在假设 DNS 服务器 A 有一个错误，它会阻塞对某个网站域名的 DNS 响应。您的所有以太网客户端都无法找到连接到该网站所需的 IP 地址，因此它们都无法连接。但您的 Wi-Fi 客户端会询问没有该错误的 DNS 服务器 B，因此它们会得到它们想要的答案并能够连接。
要测试 DNS 是否存在问题，请确保您的以太网和 Wi-Fi 客户端都获取相同的 DNS 服务器地址。
TCP MSS 限制是一种方法，其中 NAT 网关认为它比其客户端更了解上游 MTU（MTU = 最大传输单元；可以将其视为最大 IP 数据包大小），因此如果它发现客户端尝试协商 TCP MSS（MSS 是 TCP 层最大段大小，是 TCP 层等同于 IP 层的“MTU”概念）大于上游管道所能容纳的大小，NAT 网关将重写 TCP SYN 数据包中的那些 TCP MSS 协商字段，以诱骗 TCP 端点同意较小的 MSS，考虑到 NAT 网关了解其他网络跳数的 MTU 限制，这实际上应该有效。
要测试是否是 MTU 的问题，请尝试使用正常的 ~64 字节 ICMP 回显请求 ping 问题网站，然后使用填充整个 1500 字节帧的 ICMP 回显请求重试：
# Normal small pings first, just to see if pings work
ping badwebsite.example.com
# Now pad the pings out to 1472 so that, after headers are added, it's a full 1500 byte frame.
ping -s 1472 badwebsite.example.com
（我想我不应该这么说，但为了以防万一，请确保你从以太网客户端而不是 Wi-Fi 客户端执行这些 ping 测试。）
如果小 ping 有效但大 ping 失败，则表明存在 MTU 问题。之后尝试不同的值，-s看看哪个最大值适合您。将 28 添加到该值，找出您可以在以太网客户端上安全设置的 MTU。实际上，比在以太网客户端上手动设置较小的 MTU 更好的方法是修复上游 NAT 以进行正确的 MSS 限制或类似操作。
答案2
我不是专家，但我遇到了同样的问题，所以我启用并禁用了我的 LAN 适配器，然后我检查了我的 IP 地址 v4，结果显示 IP 地址已被与我的路由器不同的 IP 地址网络，所以我点击了“自动获取IP地址”。
它解决了这个问题。