我需要 HTTPS 访问主机ws.betaqxl.com，但连接失败：
:: curl -k -v https://ws.betaqxl.com
* About to connect() to ws.betaqxl.com port 443 (#0)
* Trying 91.204.81.183... Timed out
* couldn't connect to host
* Closing connection #0
curl: (7) couldn't connect to host
需要注意两点：
- 他们的防火墙必须允许我们的 IP 号码访问该主机。
- 我们发送到该主机的数据包必须通过非默认接口（静态而非动态 IP 号码）从我们的网络路由出去，该接口配置为对方应该授予访问权限的 IP 号码。
有，我认为，有两个可能的原因导致此方法失败：
- 我被他们的防火墙挡住了；尽管他们声明相反，但访问权限尚未被授予。
- 我们针对该特定主机的静态路由很糟糕，并将我的请求路由到涅槃境地。
因此，这里或那里都存在人为错误。
接下来如何确定问题的原因？让我们尝试ping一下tracert。好吧，我没有收到该主机的 ping 回复：
:: ping ws.betaqxl.com
Ping wird ausgeführt für ws.betaqxl.com [91.204.81.183] mit 32 Bytes Daten:
Zeitüberschreitung der Anforderung.
...
Ping-Statistik für 91.204.81.183:
Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4
(100% Verlust),
换句话说，超时，100% 的数据包丢失。ICMP 被防火墙阻止肯定可以解释这一点。
第一个问题，糟糕的路线也能解释这一点吗？
我思考（但我不太确定）traceroute 是否允许我查看数据包的去向。不幸的是，我们公司网络中的某些组件拒绝 traceroute 包，因此：
tracert ws.betaqxl.com
Routenverfolgung zu ws.betaqxl.com [91.204.81.183] über maximal 30 Abschnitte:
1 * * * Zeitüberschreitung der Anforderung.
...
也就是说，超时，没有回复。
第二个问题：我可以从家里获得但不能从办公室获得超出 DECIX（法兰克福）的跟踪路由，这是否证明数据包已正确地从我们公司网络路由出去？
第三个问题：除了上面列出的两个原因之外，还有其他可能的原因导致此操作失败吗？不排除我的愚蠢疏忽……但主机名和整个 URL 绝对正确，并且curl和ping工具tracert通常是可靠的。
第四个也是最后一个问题：除了显而易见的非技术步骤（要求我们的 IT 部门和他们的 IT 部门验证配置，已经这样做了），我还能做什么技术的能否判断此次故障的原因？
抱歉，我一次问了四个问题，但我想您会发现，对于网络方面的非专家来说，它们都与同一个问题有关。
答案1
这个问题的答案是在 ServerFault.com 上简而言之，由于 ICMP 被阻止，因此没有 traceroute 数据包返回给您，“您几乎无能为力”（引用 syneticon-dj 的回答），实际上可以理解为：由于您的诊断工具已被阻止，因此您在技术层面上无能为力。