长期以来，我的网络一直存在一个难以捉摸的问题。
我更换了路由器、接入点，并将无线连接改为有线连接，以寻找性能窃贼，但却没有深入了解我的设置出了什么问题。
该问题非常模糊，就像“网络感觉很慢”一样，并且该问题的特定症状并没有足够的持续性让我找到其根本原因。
我当前的基础设施由以下部分组成：
在 esxi 上运行的 pfsense 虚拟机。目前，主机上运行的唯一虚拟机（Proliant ML110、Core 2 Duo）可消除其他虚拟机对性能的干扰。服务器有两个 NIC，一个用于 WAN，一个用于 LAN。
三台 Procurve 1800/1810 8 端口和 24 端口交换机。两个 VLAN，一个用于 LAN，一个用于 WAN。
一台 Ubiquiti Unifi UAP-AC。
该网络为 20 多个单位提供连通服务。
昨天出现了一个更持久的问题，我无法在 Netflix 上开始观看电影，我谷歌了一下，找到了这里Netflix 支持人员告诉我，问题不在于他们，而在于我的 ISP。
那里的描述与我遇到的问题很相符，启动应用程序非常慢，播放并不总是有效。
我尝试拔下 Apple-TV，用同一根电缆连接我的 Macbook。在电脑上，Netflix 运行顺畅。用这根电缆进行速度测试，我确认带宽为 100 双向兆比特。重新连接 Apple-TV 后，Netflix 无法工作。
将 Apple-TV 所连接端口上的 VLAN 从 LAN 更改为 WAN，使其能够通过公共 IP 直接连接到互联网，这样就可以毫无问题地播放电影。
将其重新连接到 LAN 播放再次失败。我断开了除 Apple-TV 和交换机上行链路之外的所有连接。使用互联网接入交换机，断开了除两个 pfSense 端口、光纤转换器连接和 Apple-TV 交换机上行链路之外的所有连接。之后，它就可以开始播放了。
因此，我推断我应该能够通过重新连接所有东西来找出问题所在，看看是哪根电缆导致播放中断。没有。当所有东西重新连接后，一切都恢复正常。
每次我试图弄清楚为什么我的连接性能不佳时，我都会遇到这种情况。在 100 兆比特双向连接上，它应该相当快，但我曾多次关闭手机上的 wifi，因为 4G 速度更快。Speedtest 总是显示 100 兆比特。
流媒体似乎特别难处理，使用 AirPlay 镜像屏幕几乎没用。使用相同技术播放音乐可以，但播放中断很常见。
虽然昨天绕过防火墙似乎表明它是这一切中的骗子，但今天的结果却相反：
$ ip addr show dev eth0 | grep "inet\b" && time for i in {1..100}; do ping -c 1 -s 1600 -M dont google.se > /dev/null; done
inet 80.216.153.211/22 brd 80.216.155.255 scope global eth0
real 2m23.383s
user 0m0.046s
sys 0m0.253s
$ ip addr show dev eth0 | grep "inet\b" && time for i in {1..100}; do ping -c 1 -s 1600 -M dont google.se > /dev/null; done
inet 10.11.12.162/24 brd 10.11.12.255 scope global eth0
real 0m52.497s
user 0m0.054s
sys 0m0.253s
另外，为了尝试验证网络的 MTU（根据苹果论坛理论），我尝试使用来自 WAN 的不同大小的数据包进行 ping 操作，我的测试表明大数据包无法很好地穿越网络：
$ ip addr show dev eth0 | grep "inet\b" && time for i in {1..2}; do ping -c 1 -s 1500 google.se ; done
inet 80.216.153.211/22 brd 80.216.155.255 scope global eth0
PING google.se (64.233.163.94) 1500(1528) bytes of data.
--- google.se ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
PING google.se (64.233.163.94) 1500(1528) bytes of data.
--- google.se ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
real 0m20.015s
user 0m0.003s
sys 0m0.003s
一些实验似乎验证了 WAN 上的 MTU 确实为 1500：
$ ip addr show dev eth0 | grep "inet\b" && time for i in {1..2}; do ping -c 1 -s 1472 google.se ; done
inet 80.216.153.211/22 brd 80.216.155.255 scope global eth0
PING google.se (216.58.209.131) 1472(1500) bytes of data.
72 bytes from arn09s05-in-f3.1e100.net (216.58.209.131): icmp_seq=1 ttl=59 (truncated)
--- google.se ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 4.497/4.497/4.497/0.000 ms
PING google.se (216.58.209.131) 1472(1500) bytes of data.
72 bytes from arn09s05-in-f3.1e100.net (216.58.209.131): icmp_seq=1 ttl=59 (truncated)
--- google.se ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 4.454/4.454/4.454/0.000 ms
real 0m0.034s
user 0m0.003s
sys 0m0.003s
$ ip addr show dev eth0 | grep "inet\b" && time for i in {1..2}; do ping -c 1 -s 1473 google.se ; done
inet 80.216.153.211/22 brd 80.216.155.255 scope global eth0
PING google.se (216.58.209.131) 1473(1501) bytes of data.
--- google.se ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
PING google.se (216.58.209.131) 1473(1501) bytes of data.
--- google.se ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
real 0m20.018s
user 0m0.001s
sys 0m0.007s
在 LAN 上，断点位于相同的数据包大小，但我必须手动指定不允许数据包分段：
$ ip addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 68:b5:99:e7:07:a8 brd ff:ff:ff:ff:ff:ff
inet 10.11.12.162/24 brd 10.11.12.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::6ab5:99ff:fee7:7a8/64 scope link
valid_lft forever preferred_lft forever
$ ping -c 1 -s 3000 google.se
PING google.se (83.255.235.35) 3000(3028) bytes of data.
3008 bytes from 83.255.235.35: icmp_seq=1 ttl=61 time=82.3 ms
--- google.se ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 82.324/82.324/82.324/0.000 ms
$ ping -c 1 -s 1472 -M do google.se
PING google.se (83.255.235.123) 1472(1500) bytes of data.
1480 bytes from cache.google.com (83.255.235.123): icmp_seq=1 ttl=61 time=74.7 ms
--- google.se ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 74.779/74.779/74.779/0.000 ms
$ ping -c 1 -s 1473 -M do google.se
PING google.se (83.255.235.35) 1473(1501) bytes of data.
ping: local error: Message too long, mtu=1500
--- google.se ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
我不明白我的网络出了什么问题，也不知道该如何进一步排除故障。请帮我重新规划我的故障排除方案，以便一劳永逸地清除网络中的幽灵。
编辑，关于我的 DNS 设置：
如果我理解正确的话，这意味着 Google 解析器仅在 ISP 的 DHCP 分配名称服务器不可用时用作后备。对吗？还是我随机向很远的名称服务器询问地址？
正如您在下面看到的，pfSense 首先尝试自行处理名称解析，其次和第三询问 ISP，最后只求助于谷歌作为第四和第五个选项，这对我来说似乎很合理？
Apple TV 具有 DHCP 分配的网络设置，并使用网关作为名称服务器。DHCP 服务器没有专用的 DNS 设置，但继承了上面的名称服务器列表：
编辑，关于 for 循环：
运行 ping 100 次而不是运行一次 100 个数据包的原因是为了每次都执行名称解析，因为当我手动运行它时，似乎需要花费相当不同的时间才能让 ping“启动”，我想也许我可以通过将操作乘以 100 来让这种感觉更加明显。
假设 Ubuntu 具有以下配置：
$ grep nameserver /etc/resolv.conf
nameserver 127.0.1.1
但这个想法可能有点傻……
编辑，关于Apple TV：
我已将 Apple TV 重置为出厂默认设置。我曾多次拔下设备电源（有时甚至非常愤怒）。
编辑，pfSense：
前几天我恢复了 pfSense 的出厂默认设置，只重新启用了其中比较重要的部分（dns、dhcp、nat、静态 dhcp 租约、一些端口转发），但昨天 Netflix 仍然在播放中途停止。不过问题又消失了，所以重新启动电影就可以了。
我想知道 Netflix 是否需要 DNS 中途传输，感觉到那时应该已经解决了。
由于服务器运行的是最新的 pfSense 版本 (2.2.2)，因此它使用未绑定默认情况下。
可以使用诊断工具进行两次连续查找来验证解析器是否成功缓存解析：
但不同的答案令我困惑。
编辑，MTU：
MTU 设置为自动。
编辑，ATV 速度测试：
在 Apple TV 上进行速度测试会在 pfSense 上生成以下图表：
此后，Apple TV 会显示“测试成功完成”，但只持续了一瞬间，然后变为：
尽管出现错误，我仍可以使用 Netflix。
答案1
确保使用本地 ISP 的 DNS 服务器，而不是某些远程 DNS 服务。
大部分可以下载或流式传输到 Apple TV 的内容都来自 Akamai CDN（Apple 多年来一直是 Akamai 最大的客户之一）。Akamai 会根据您的 DNS 查询来源找到离您最近的 CDN 边缘节点（服务器），而您的 DNS 查询通常来自您已配置客户端设备使用的本地递归/解析 DNS 服务器。
确保您的 Apple TV 已设置为使用本地 ISP 的 DNS 服务器，而不是某些可能远程的服务器，例如 Google DNS（8.8.8.8 和 8.8.4.4）或 Level 3（4.2.2.x）或 OpenDNS 或类似的任何服务器。请注意，您的 Apple TV 可能通过 DHCP 获取其 DNS 设置，并且您的 DHCP 服务器可能是路由器/网关上的进程。如果 DHCP 服务器告诉您的 Apple TV 使用 NAT 网关（或其他本地防火墙或路由器）的私有 IP 地址作为其 DNS 地址，则意味着您的 NAT 网关正在充当 DNS 代理。如果您想继续这样做，请确保该 NAT 网关正在使用您本地 ISP 的 DNS 服务器作为它是DNS 服务器。
通过使用本地 DNS 服务器，Akamai 将引导您的客户端从位于瑞典的最近的 Akamai 服务器发出下载/流式传输请求，而不是从位于美国 Google 数据中心附近的某个服务器（Google 的 8.8.8.8 DNS 服务器所在地）发出下载/流式传输请求。
[即使这对您来说不是正确答案，但对于其他找到此问题的人来说，这可能就是正确答案，因此无论如何我都会将其留在这里。]