【原创】curl: (7) Failed to connect to raw.githubusercontent.com port 443: Connection refused

相关环境

Ubuntu 18.04.1 x64

curl 7.58.0

问题描述

使用 curl 安装运行 github 上的 shell 脚本时,报错。报错信息如下

jiangzl@ubuntu:~$ curl -fsSL https://code-server.dev/install.sh | sh
curl: (7) Failed to connect to raw.githubusercontent.com port 443: Connection refused

问题原因

尝试过程

1、ping raw.githubusercontent.com

我尝试 ping raw.githubusercontent.com 这个域名,发现被解决到了 localhost。遂觉得非常诡异。

jiangzl@ubuntu:~$ ping raw.githubusercontent.com
PING raw.githubusercontent.com (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.021 ms
64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.083 ms
64 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=64 time=0.089 ms
64 bytes from localhost (127.0.0.1): icmp_seq=4 ttl=64 time=0.088 ms
^C
--- raw.githubusercontent.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3080ms
rtt min/avg/max/mdev = 0.021/0.070/0.089/0.029 ms

2、telnet 443 端口

尝试 telnet 443 端口仍然诡异地连接到 0.0.0.0

jiangzl@ubuntu:~$ telnet raw.githubusercontent.com 443
Trying 0.0.0.0...
Trying ::...
telnet: Unable to connect to remote host: Connection refused

3、查看本地的 hosts 文件

尝试查看本机的 hosts 文件,没有对应的 raw.githubusercontent.com 相关的配置,这也不太可能。之前我没有人为配置过 hosts 文件。

jiangzl@ubuntu:~$ cat /etc/hosts
127.0.0.1       localhost
127.0.1.1       ubuntu
# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

4、使用 nslookup 查看 DNS 解析

使用 nslookup 查看 raw.githubusercontent.com 的 DNS 解析,发现解析 DNS 的 Server 是 127.0.0.53,而 raw.githubusercontent.com 确实是被解析到了 0.0.0.0

jiangzl@ubuntu:~$ nslookup raw.githubusercontent.com
Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
Name:   raw.githubusercontent.com
Address: 0.0.0.0
Name:   raw.githubusercontent.com
Address: ::

5、查看本机的 DNS 设置

jiangzl@ubuntu:~$ cat /etc/resolv.conf 
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "systemd-resolve --status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.
nameserver 127.0.0.53
options edns0

从以上信息分析,看起来是 DNS 服务器在解析时出现了问题。在网上搜索了一下这个错误,很多都是关于 homebrew 的解决方案,但思路也是类似。

https://github.com/hawtim/blog/issues/10

解决方法

1、获取 raw.githubusercontent.com 的 IP,添加本地的 hosts 文件映射。

这种方法不建议使用,因为不是一劳永逸的方法,如果 raw.githubusercontent.com 域名解析的 IP 发生了变化,那么 hosts 文件中添加的映射就失效了。

这种方法此处不介绍了,如果确实需要可以参考以下地址的解决方法:

https://github.com/hawtim/blog/issues/10

2、更改本机的 DNS 设置

将 nameserver 改为 114.114.114.114 (如果需要访问的域名多在中国大陆,建议改为此 DNS,这个 DNS 是中国电信提供的免费 DNS Server,解析国内域名相对较快)或者 8.8.8.8 (如果需要访问的域名多在海外,建议改成 8.8.8.8,这个 DNS 是 Google 提供的供全球免费使用的 DNS Server)

如下示例:

jiangzl@ubuntu:~$ sudo vim /etc/resolv.conf

更改 nameserver 设置后,保存退出,然后再尝试

jiangzl@ubuntu:~$ nslookup raw.githubusercontent.com
Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:

raw.githubusercontent.com       canonical name = github.map.fastly.net.

Name:   github.map.fastly.net

Address: 151.101.0.133

Name:   github.map.fastly.net

Address: 151.101.64.133

Name:   github.map.fastly.net

Address: 151.101.128.133

Name:   github.map.fastly.net

Address: 151.101.192.133

可以看到 raw.githubusercontent.com 能正常解析到了,尝试之前的命令,可以正常运行了

jiangzl@ubuntu:~$ curl -fsSL https://code-server.dev/install.sh | sh -s -- --dry-run
Ubuntu 18.04.5 LTS
Installing v3.5.0 deb package from GitHub releases.

+ mkdir -p ~/.cache/code-server

+ curl -#fL -o ~/.cache/code-server/code-server_3.5.0_amd64.deb.incomplete -C – https://github.com/cdr/code-server/releases/download/v3.5.0/code-server_3.5.0_amd64.deb

+ mv ~/.cache/code-server/code-server_3.5.0_amd64.deb.incomplete ~/.cache/code-server/code-server_3.5.0_amd64.deb

+ sudo dpkg -i ~/.cache/code-server/code-server_3.5.0_amd64.deb

To have systemd start code-server now and restart on boot:

  sudo systemctl enable –now code-server@$USER

Or, if you don’t want/need a background service you can run:

  code-server

注:

(1) 已经尝试过设置为 114.114.114.114,但发现 code-server.dev 的域名解析不到,所以只能改为 8.8.8.8。

(2) 也可以同时设置 114.114.114.114 与 8.8.8.8 作为 DNS Server,这样可以避免某个 DNS 解析不到的问题。 DNS Server 会按顺序使用

如下所示:

vi /etc/resolv.conf
nameserver 114.114.114.114
nameserver 8.8.8.8

附录

1、使用 114.114.114.114 与 8.8.8.8 作为 DNS Server 的 ping 延时测试

均使用 www.baidu.com 作为测试目标,使用 114.114.114.114 作 DNS Server 的 ping 如下:

jiangzl@ubuntu:~$ ping www.baidu.com
PING www.a.shifen.com (220.181.38.150) 56(84) bytes of data.
64 bytes from 220.181.38.150 (220.181.38.150): icmp_seq=1 ttl=55 time=6.21 ms
64 bytes from 220.181.38.150 (220.181.38.150): icmp_seq=2 ttl=55 time=6.21 ms
64 bytes from 220.181.38.150 (220.181.38.150): icmp_seq=3 ttl=55 time=6.05 ms
64 bytes from 220.181.38.150 (220.181.38.150): icmp_seq=4 ttl=55 time=6.10 ms
^C
--- www.a.shifen.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 6.057/6.147/6.215/0.068 ms

使用 8.8.8.8 作为 DNS Server 的 ping 如下

jiangzl@ubuntu:~$ ping www.baidu.com
PING www.wshifen.com (104.193.88.123) 56(84) bytes of data.
64 bytes from 104.193.88.123 (104.193.88.123): icmp_seq=1 ttl=53 time=150 ms
64 bytes from 104.193.88.123 (104.193.88.123): icmp_seq=2 ttl=53 time=150 ms
64 bytes from 104.193.88.123 (104.193.88.123): icmp_seq=4 ttl=53 time=150 ms
64 bytes from 104.193.88.123 (104.193.88.123): icmp_seq=5 ttl=53 time=150 ms
^C
--- www.wshifen.com ping statistics ---
6 packets transmitted, 4 received, 33% packet loss, time 5011ms
rtt min/avg/max/mdev = 150.320/150.745/150.945/0.539 ms

可以看到使用 114.114.114.114 与 8.8.8.8 在解析延时(主要还是网络延时)上有比较大的差距,但都是在毫秒级别,所以使用体验上差别不大。

2、参考

https://github.com/hawtim/blog/issues/10

You may also like...

发表评论

电子邮件地址不会被公开。 必填项已用*标注

%d 博主赞过: