当我运行mtr --report tokyo1.linode.com我看到下面的报告。 它看起来像我的交通在我的本地networking内弹跳12次，甚至在打“互联网”之前。 任何想法是什么可能导致这个，我怎么可以解决它？
我的电脑通过Wi-Fi连接到路由器，路由器通过墙上的sockets连接到DSL连接。 我的路由器和墙上的连接之间没有调制解调器。 这是我第一次使用宽带提供商，不需要使用调制解调器，但它以某种方式工作。
请注意，为了安全，我在下面的报告中用R和Qreplace了一些数字。
HOST: MacBook-Pro.local Loss% Snt Last Avg Best Wrst StDev 1.|-- 10.0.0.1 0.0% 10 0.7 0.9 0.7 1.3 0.2 2.|-- 10.84.0.1 80.0% 10 2.9 3.3 2.9 3.7 0.5 3.|-- 192.168.R.73 80.0% 10 2.1 2.7 2.1 3.2 0.8 4.|-- 192.168.R.10 80.0% 10 2.0 2.2 2.0 2.4 0.3 5.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 6.|-- 192.168.R.209 80.0% 10 24.7 14.5 4.3 24.7 14.4 7.|-- 192.168.R.205 80.0% 10 2.3 4.3 2.3 6.2 2.7 8.|-- 192.168.R.21 80.0% 10 4.5 6.3 4.5 8.2 2.6 9.|-- 192.168.Q.158 80.0% 10 10.4 6.2 2.1 10.4 5.9 10.|-- bogon 80.0% 10 2.8 2.4 2.0 2.8 0.5 11.|-- 192.168.R.37 80.0% 10 3.8 4.4 3.8 5.0 0.8 | `|-- 192.168.R.49 12.|-- 192.168.R.37 80.0% 10 12.5 7.7 2.9 12.5 6.8 13.|-- 124.68.6.189 80.0% 10 4.3 4.7 4.3 5.1 0.5 14.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 15.|-- 221.122.35.65 80.0% 10 2.7 8.5 2.7 14.2 8.1 ... (etc)
他们有机会通过你的服务提供商的networking而不是你的实际networking，而你在所谓的运营商级NAT之后。
Tracert不是testing连接质量的工具，它是确定两个端点之间path的工具。 Tracert通过发送ICMP回应请求来工作，在每个连续的跳跃处将TTL递增1，以确定两个端点之间的path。 结果显示了每一跳对发送给它的ICMP回显请求的响应，这并不表示该跳如何处理通过它发送的“真实”stream量。
如果您的结果真的显示了通过这些跳数的数据包丢失，那么每个连续的跳将显示相同的数据包丢失或增加数据包丢失。
你看到的显示数据包丢失的跳是如何跳响应ICMP回应请求发送到它，在许多情况下被忽略，丢弃，或给予低优先级。 路由器关心路由实际stream量，而不是回应您的tracert。
因此，我不认为需要修正的“问题”。
编辑
回答你的评论：
我应该仔细看看你的踪迹。 您的跟踪显示了第二跳上的数据包丢失以及每个连续跃点上的相同数据包丢失（显示100％数据包丢失的跃点可能完全忽略了ICMP数据包）。 这可能是一个问题的迹象。 这并不能解释为什么删除路由器似乎“修复”了数据包丢失。