Github.com 解决但超时

Question

由于某种原因，我无法github.com连接，连接超时；过去几天我一直有这个问题。我在任何其他网站上都没有这个问题。

我正在运行 macOS 10.15.5。运行traceroute我看到 DNS 解析但随后丢失（编辑：答案指出这是 github 预期的）：

$ traceroute github.com
traceroute to github.com (192.30.253.113), 64 hops max, 72 byte packets
 1  10.0.0.1 (10.0.0.1)  5.508 ms  1.134 ms  1.275 ms
 2  192.168.1.1 (192.168.1.1)  3.066 ms  2.711 ms  2.658 ms
 3  80.10.124.196 (80.10.124.196)  69.645 ms  53.357 ms  55.386 ms
 4  10.125.222.74 (10.125.222.74)  54.702 ms  61.938 ms  38.273 ms
 5  ae44-0.niidf202.paris15earrondissement.francetelecom.net (193.252.98.246)  108.873 ms  32.476 ms  102.200 ms
 6  193.252.137.74 (193.252.137.74)  55.651 ms  82.649 ms  70.433 ms
 7  zayo-9.gw.opentransit.net (193.251.250.188)  38.020 ms  85.435 ms  91.153 ms
 8  ae27.cs1.cdg11.fr.eth.zayo.com (64.125.29.4)  168.142 ms  220.846 ms  195.284 ms
 9  ae0.cs1.cdg12.fr.eth.zayo.com (64.125.29.84)  180.439 ms  119.870 ms  108.460 ms
10  ae2.cs3.lhr11.uk.eth.zayo.com (64.125.29.25)  114.051 ms * *
11  * * *
12  * * *
13  * * *
14  209.66.120.181.ipyx-243981-004-zyo.zip.zayo.com (209.66.120.181)  112.761 ms  120.212 ms  113.661 ms
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
...

使用host确认 DNS 解析

$ host github.com
github.com has address 140.82.113.4
github.com mail is handled by 5 ALT1.ASPMX.L.GOOGLE.com.
github.com mail is handled by 5 ALT2.ASPMX.L.GOOGLE.com.
github.com mail is handled by 10 ALT3.ASPMX.L.GOOGLE.com.
github.com mail is handled by 10 ALT4.ASPMX.L.GOOGLE.com.
github.com mail is handled by 1 ASPMX.L.GOOGLE.com.

从host我的 IP 上运行 curl可以看到尝试到达的连接超时192.30.253.113：

$ curl -v --insecure -L 140.82.113.4

*   Trying 140.82.113.4...
* TCP_NODELAY set
* Connected to 140.82.113.4 (140.82.113.4) port 80 (#0)
> GET / HTTP/1.1
> Host: 140.82.113.4
> User-Agent: curl/7.64.1
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Content-length: 0
< Location: https://140.82.113.4/
<
* Connection #0 to host 140.82.113.4 left intact
* Issue another request to this URL: 'https://140.82.113.4/'
*   Trying 140.82.113.4...
* TCP_NODELAY set
* Connected to 140.82.113.4 (140.82.113.4) port 443 (#1)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: C=US; ST=California; L=San Francisco; O=GitHub, Inc.; CN=github.com
*  start date: May  5 00:00:00 2020 GMT
*  expire date: May 10 12:00:00 2022 GMT
*  issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=DigiCert SHA2 High Assurance Server CA
*  SSL certificate verify ok.
> GET / HTTP/1.1
> Host: 140.82.113.4
> User-Agent: curl/7.64.1
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Content-length: 0
< Location: https://github.com/
<
* Connection #1 to host 140.82.113.4 left intact
* Issue another request to this URL: 'https://github.com/'
*   Trying 192.30.253.113...
* TCP_NODELAY set
* Connection failed
* connect to 192.30.253.113 port 443 failed: Operation timed out
* Failed to connect to github.com port 443: Operation timed out
* Closing connection 2
curl: (7) Failed to connect to github.com port 443: Operation timed out
* Closing connection 0
* Closing connection 1

在这一点上，我认为问题出在 github 一边，但是我是所有同事中唯一一个遇到此问题的人。

编辑 2 我使用 macOS 来宾帐户登录，并且能够访问 github。不过，该问题仍然出现在另一个普通用户帐户上。所以问题来自一些特定于用户的配置。

我也跑sudo killall -HUP mDNSResponder和sudo dscacheutil -flushcache; 它没有解决问题。

编辑 3 如果我在curl没有-L（即没有重定向）的情况下调用请求成功，我会返回 GitHub 的 HTML：

$ curl -H "Host: github.com" --insecure -v https://140.82.118.3/
*   Trying 140.82.118.3...
* TCP_NODELAY set
* Connected to 140.82.118.3 (140.82.118.3) port 443 (#0)
[...]
* TLSv1.2 (IN), TLS handshake, Finished (20):
[...]
<!DOCTYPE html>
<html lang="en">
  <head>
[...]

Answer 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 2

但是您的命令已经显示域名确实解析（到第 2 行中的 IP 地址 192.30.253.113）。如果没有，那么跟踪甚至根本无法开始。

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

您的输出并不一定意味着一般存在问题——它只是表明这些节点不想专门响应 traceroute 探测。当在 UDP 模式下使用 traceroute 时，这对于 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托管，一个更新调用成功但一个失败并非不可能。）稍等片刻，再试一次。