Remember a solution experience that github.io can't open
I remember that there was a solution that github.com couldn't open or opened very slowly, now it's github.io's turn, haha. My github.io couldn't be opened for a long time. At that time, I tried several methods from the Internet and gave up without success. Today, I need to open github.io to check the information. It takes a little time, so I mainly solved this problem. From this article, you can learn:
- How to troubleshoot this kind of dns problem?
- How to solve the problem of not opening github.io?
Use ping
The ping command is actually very powerful, not only can you know whether you can connect and what the delay is, but you can also know the ip address resolved by dns . For example ping www.baidu,com, the command line displays as follows:
PING www.baidu.com (14.215.177.38): 56 data bytes
64 bytes from 14.215.177.38: icmp_seq=0 ttl=56 time=9.461 ms
64 bytes from 14.215.177.38: icmp_seq=1 ttl=56 time=12.325 ms
64 bytes from 14.215.177.38: icmp_seq=2 ttl=56 time=15.366 ms
As you can see, 14.215.177.38 in the parentheses is the ip address.
Then we go ping github.io, the display is as follows:
PING github.io (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.030 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.105 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.084 ms
Local hosts file
The ip address shown above is 127.0.0.1, this is the local address, and then I went /etc/hostsinside to check whether the hosts file has been accidentally modified, and did not see 127.0.0.1the record of github.io being resolved , which means that the dns resolution on the computer is intact Yes, but the remote dns resolution is likely to be polluted by the network operator , which causes the resolution to be reached during the resolution 127.0.0.1.
Modify the local dns
So we went to modify the dns of the machine, and added 114.114.144.114and 8.8.8.8. These two dns are non-commercial dns , with a high resolution success rate, and they are pure and without ads. The former is the DNS commonly used by China Mobile, China Telecom and China Unicom, which is commonly used by domestic users to access the Internet; the latter is the DNS provided by GOOGLE, which is universal.
Take mac as an example, open System Preferences->Network->Advanced->dns in turn, and then join. After joining, you need to refresh the mac cache, the command is as follows ( remember to bring sudo, otherwise it will not take effect ):
sudo killall -HUP mDNSResponder
Then we come again ping github.io, the display is as follows:
PING github.io (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=64 time=36.350 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=64 time=23.312 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=64 time=24.262 ms
As you can see, the local dns modification has taken effect and the resolution has 8.8.8.8been reached.
By the wall
Then we opened it with interest https://octokit.github.io/rest.js/v18, and found that it still couldn't open. So we thought about pinging this url to try? The results are as follows:
PING https://octokit.github.io/rest.js/v18 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=116 time=25.442 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=116 time=28.669 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=116 time=22.312 ms
We found that it can be pinged, but the browser still can't open it means that this website may be walled! ! !
So is there a solution?
In fact, it does. Before, my shadowxsocks has always been in PAC automatic mode . I turned on the global mode with a clever idea , and then I was pleasantly surprised to find that https://octokit.github.io/rest.js/v18it was able to open it! ! !
to sum up
- In the future, if you encounter this kind of dns problem, you can check it step by step in the above order. (When appropriate, you can open and
chrome://net-internals/#dnsrefresh the dns of the google browser) - In this case of being walled, just turn on the global mode of the Science x Internet tool.
- There is a small question in the middle, that is, why can the walled website be opened in PAC mode, while other walled websites need to be opened in the global mode? (My idea is that some URLs are contaminated by the DNS of the network operator, so the DNS of the network operator is used instead of the DNS of the scientific x Internet tool, so it is necessary to turn on the global mode and not use the DNS of the network operator. OK . And some other websites have not been resolved by the DNS of the network operator, so use the DNS of the scientific x Internet tool, so they can be opened normally in PAC mode.)
Author: bread plus pears
welcome any form of reprint, but please be sure to indicate the source.
Limited to my own level, please feel free to enlighten me if there is any inappropriate expression in the article and code.