'github.com' 解析，但超时

Question 1

我也遇到了这个问题，也持续了好几天，而且和你的 IP 地址一样！今天早上刚修好。

我修复该问题的方法是查看我的 /etc/hosts 并查看 github.com 列出的 IP，然后注释掉该行。

有人给我的解释

libc（在不同的操作系统中方式不同）使用 /etc/hosts 来覆盖主机名查找。这在测试某些东西时有时很有用，但我常常会忘记其中的东西……

192.30.253.113 是一个 github 地址，因为他们拥有 192.30.252.0/22。您可以运行 whois 192.30.253.113 进行确认。这很可能是 github.com 的有效服务器地址，但几天前已退役。我甚至无法 ping 它。他们会将其从他们的 DNS 服务器中删除，但由于它是硬编码在您笔记本电脑的 /etc/hosts 中，所以它对这种变化一无所知！

Answer

我也遇到了这个问题，也持续了好几天，而且和你的 IP 地址一样！今天早上刚修好。

我修复该问题的方法是查看我的 /etc/hosts 并查看 github.com 列出的 IP，然后注释掉该行。

有人给我的解释

libc（在不同的操作系统中方式不同）使用 /etc/hosts 来覆盖主机名查找。这在测试某些东西时有时很有用，但我常常会忘记其中的东西……

192.30.253.113 是一个 github 地址，因为他们拥有 192.30.252.0/22。您可以运行 whois 192.30.253.113 进行确认。这很可能是 github.com 的有效服务器地址，但几天前已退役。我甚至无法 ping 它。他们会将其从他们的 DNS 服务器中删除，但由于它是硬编码在您笔记本电脑的 /etc/hosts 中，所以它对这种变化一无所知！

Question 2

但是你的命令已经显示域名做解析（到第 2 行中的 IP 地址 192.30.253.113）。如果没有，那么跟踪根本就无法启动。

其余的跟踪输出有与解析 DNS 名称无关– 这根本不是 traceroute 检查的内容。（域名是不是重新解析每个数据包。一旦应用程序知道 IP 地址，它就会直接使用该地址。）相反，traceroute 可以显示随后的实际网络连接存在问题。

您的输出并不一定意味着存在普遍问题 - 它只是表明这些节点不想响应跟踪路由探测具体来说。当 traceroute 在 UDP 模式下使用时，这在 GitHub 系统中实际上是正常的（因为他们只是有一个防火墙，可以在早期阻止 UDP 探测）。您可以将其切换到 ICMP 探测以获得更准确的结果：

sudo traceroute -I github.com
sudo traceroute -I 192.30.253.113

但是，对于您来说，跟踪不会告诉您太多信息，因为最终系统本身，即 192.30.253.113 负载均衡器，无法接受您的 HTTPS 连接。但通常情况下，GitHub 的操作员会迅速从 DNS 中删除错误地址（并且正如您的第二个命令所示，错误地址实际上不再存在于 DNS 中）。

换句话说，问题在于域名解析为错误的每当 curl 或 traceroute 使用操作系统提供的名称查找功能时，地址。

可能的选择：

你刚好解析了域名仍然有该地址，它将被操作系统缓存几分钟（GitHub 指定 60 秒，但并非所有系统都遵守如此低的 TTL）。只需等待一段时间再试一次。
您在 /etc/hosts 中将错误地址设置为覆盖（traceroute 和 curl 会接受该地址，但host或dig工具会绕过该地址）。请使用其他设备进行检查。
您的 DNS 服务器此时正在撒谎，例如，网络管理员可能愚蠢地尝试使用自定义地址覆盖域名。（host不过，您的第二个命令显示效果不错。）尝试使用其他连接（例如公共 Wi-Fi 或移动 4G）来绕过任何拦截。
GitHub 的域名服务器不一致，在不同的查询中返回不同的结果。（该域名由 AWS 托管和Dyn，一个更新调用成功，一个失败，这并非不可能。）等待一段时间后再试。

Answer

但是你的命令已经显示域名做解析（到第 2 行中的 IP 地址 192.30.253.113）。如果没有，那么跟踪根本就无法启动。

其余的跟踪输出有与解析 DNS 名称无关– 这根本不是 traceroute 检查的内容。（域名是不是重新解析每个数据包。一旦应用程序知道 IP 地址，它就会直接使用该地址。）相反，traceroute 可以显示随后的实际网络连接存在问题。

您的输出并不一定意味着存在普遍问题 - 它只是表明这些节点不想响应跟踪路由探测具体来说。当 traceroute 在 UDP 模式下使用时，这在 GitHub 系统中实际上是正常的（因为他们只是有一个防火墙，可以在早期阻止 UDP 探测）。您可以将其切换到 ICMP 探测以获得更准确的结果：

sudo traceroute -I github.com
sudo traceroute -I 192.30.253.113

但是，对于您来说，跟踪不会告诉您太多信息，因为最终系统本身，即 192.30.253.113 负载均衡器，无法接受您的 HTTPS 连接。但通常情况下，GitHub 的操作员会迅速从 DNS 中删除错误地址（并且正如您的第二个命令所示，错误地址实际上不再存在于 DNS 中）。

换句话说，问题在于域名解析为错误的每当 curl 或 traceroute 使用操作系统提供的名称查找功能时，地址。

可能的选择：

你刚好解析了域名仍然有该地址，它将被操作系统缓存几分钟（GitHub 指定 60 秒，但并非所有系统都遵守如此低的 TTL）。只需等待一段时间再试一次。
您在 /etc/hosts 中将错误地址设置为覆盖（traceroute 和 curl 会接受该地址，但host或dig工具会绕过该地址）。请使用其他设备进行检查。
您的 DNS 服务器此时正在撒谎，例如，网络管理员可能愚蠢地尝试使用自定义地址覆盖域名。（host不过，您的第二个命令显示效果不错。）尝试使用其他连接（例如公共 Wi-Fi 或移动 4G）来绕过任何拦截。
GitHub 的域名服务器不一致，在不同的查询中返回不同的结果。（该域名由 AWS 托管和Dyn，一个更新调用成功，一个失败，这并非不可能。）等待一段时间后再试。

Question 3

Github.com 确实可以在您的计算机上解析，这一点可以从 traceroute 有一个可用的 IP 地址 ( 192.30.253.113) 得到证明。您的问题不在于 DNS 解析。

事实上，你尝试进行的测试与 DNS 关系不大。解析在测试开始之前就已经完成了。你的问题是你的数据包没有到达 Github 的服务器。

但是，traceroute 无法确定这一点，因为似乎通往 Github.com 的路径上的某些方以某种方式禁用了 traceroute（见下文）。尽管我看到了星星，但 Github.com 对我来说仍然运行良好。

 mtak@dc4:~$ traceroute github.com
traceroute to github.com (140.82.118.4), 30 hops max, 60 byte packets
 1  * * *
 2  l6.f2.ams4.transip.net (77.72.151.70)  16.942 ms  16.917 ms l5.f1.ams4.transip.net (77.72.151.8)  15.319 ms
 3  f1.r2.ams0.transip.net (77.72.151.124)  0.261 ms f2.r1.ams0.transip.net (77.72.151.122)  0.594 ms  0.577 ms
 4  r1-a0.e1.ams7.transip.net (157.97.168.1)  0.407 ms  0.391 ms r2-a0.e1.ams8.transip.net (157.97.168.4)  0.407 ms
 5  transip.telecity2.openpeering.nl (82.150.159.226)  0.704 ms  1.247 ms 213.198.92.21 (213.198.92.21)  2.528 ms
 6  * * xe-0-2-1.er1.ams1.nl.zip.zayo.com (64.125.12.137)  0.879 ms
 7  ae9.cs1.ams17.nl.eth.zayo.com (64.125.31.10)  6.972 ms  7.191 ms  7.150 ms
 8  ae2.cs1.fra6.de.eth.zayo.com (64.125.29.58)  7.067 ms  6.956 ms  9.627 ms
 9  ae1.mcs1.fra6.de.eth.zayo.com (64.125.29.57)  6.791 ms  6.843 ms  6.911 ms
10  82.98.193.31.IPYX-270403-001-ZYO.zip.zayo.com (82.98.193.31)  7.432 ms  7.339 ms  7.291 ms
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

目前，我认为你能做的不多。解决成功了，你就可以上网了。剩下的就交给其他方了。

Answer