我试图从我的业务到达一个域名。 我正在对ip：443做跟踪路由，达到dns后跟踪失败。 我想知道错误在哪里。
跟踪的最后四行：
10 er1-te-3-1.sanjoseequinix.savvis.net（204.70.200.129）15.641 ms 12.127 ms 14.280 ms
11 cr1-tenge-0-3-5-0.sanfrancisco.savvis.net（204.70.200.198）18.039 ms 17.210 ms 18.242 ms
12 cr2-bundle-pos-1.losangeles.savvis.net（204.70.197.29）23.199 ms 24.002 ms 27.607 ms
13 er2-tengig-3-1.lay.savvis.net（204.70.198.10）24.649 ms 24.145 ms 25.182 ms
14 phyber.losangeles.savvis.net（208.173.55.226）30.955 ms 20.603 ms 25.967 ms
当您尝试接触主机时，您看到了什么症状？
你是指“在ip：443上做traceroute”是什么意思？ 端口与traceroute不相关。 你能告诉我们你正在执行的实际traceroute命令吗？
跟踪路由到DNS服务器还是目标主机？
我也感到困惑的是，“到达DNS后跟踪失败”，作为一个主机的跟踪路由不会遍历用于parsing主机的DNS服务器…除非DNS服务器也是您的网关。 你能澄清一下这个说法吗？
该跟踪看起来很好，假设目标主机是208.173.55.226。 Traceroute实际上是有限的实用程序，因为它常常会被丢弃，当正常的TCP / UDP数据包的合法端口将被接受。 在某些情况下使用tcptraceroute可以照亮。
只是一个猜测，但尝试一个不同的DNS。 18.72.0.3是麻省理工的一个从来没有让我失望的人。
根据这个痕迹，你没有丢失任何数据包… 30毫秒是一个相当合理的回报时间。
一个澄清虽然DNS和traceroute（使用ICMP）都不知道端口443（第4层）。 除非你使用基于TCP的traceroute，否则你可能会看到tracert将443转换为IP地址（你是否看到关于0.0.1.187的消息？）然后试图追踪它。 检查我的窗口框的行为，如果你这样做，似乎会发生：tracert valid.ip.add.ress 443追踪路由到0.0.1.187最多30跳1 * ^ C
Traceroute是一个ICMP诊断，并不总是给出与TCP conenction相同的结果。 使用执行基于TCP的跟踪路由的tracetcp可以在这些情况下提供更多信息。
如果这些是最后四行（即：后面没有“* * *”行），那么您的跟踪路由到达目的地，所以您需要开始了解为什么服务器不会响应Web请求 – 尝试远程login到端口80（http）或443（https）来查看是否可以打开连接到适当的端口。
telnet remote.server.com 80 如果您无法build立TCP连接，请使用tracetcp查看连接失败的时间 – 可能是您的末端的防火墙或远程的防火墙/死亡服务等。 一旦你确切知道数据包在哪里失败，你可以联系适当的人。 如果您可以在端口80/443上build立TCP连接，那么请联系远程pipe理员作为缺less响应，这意味着他们有服务监听，但没有返回正确的响应。