GitHub이 간간히 열리지 않을 때면, 나는 먼저 이걸 구분한다. 도메인 해석에 문제가 생긴 건지, 아니면 네트워크가 아예 닿지 않는 건지. hosts를 고치는 건 앞의 경우에만 도움이 될 수 있다. 이건 프록시가 아니고, 방화벽을 우회하지도, TLS 연결을 고쳐주지도 않는다.
hosts는 어디서 가져오나
나는 maxiaof/github-hosts를 쓴다. 이 프로젝트는 GitHub 및 관련 리소스 도메인의 해석 레코드를 제공하고, 업데이트 주소는 hosts 파일이다.
IP 주소는 바뀌기 때문에 고정된 목록을 그대로 베끼면 오히려 헷갈리기 쉽다. 프로젝트에 직접 가서 최신 파일을 확인하고, 도메인과 업데이트 날짜를 살핀 다음, 내가 추가한 부분만 교체하자.
설명 이미지: hosts가 바꾸는 건 해석이지, 네트워크 경로가 아니다
그림에서 hosts와 DNS는 해석 경로이고, 그 뒤의 네트워크 연결은 별개의 문제다. IP를 받았다고 해서 반드시 연결된다는 보장은 없다.
수정 전에 먼저 백업
Windows는 C:\Windows\System32\drivers\etc\hosts, macOS와 Linux는 /etc/hosts에 있다. 먼저 복사해서 백업해 두고, 관리자 권한으로 편집하자. 파일에 원래 있는 localhost, 개발 환경 도메인, 기타 업무 설정을 덮어쓰면 안 된다.
내가 추가한 내용에는 # GitHub hosts begin과 # GitHub hosts end처럼 명확한 주석 한 쌍을 남겨두자. 나중에 업데이트할 때 이 두 줄 사이의 레코드만 교체하고, 다운로드한 파일 전체를 매번 덧붙이지 않도록.
캐시 새로고침과 확인
Windows는 관리자 터미널에서 실행한다:
ipconfig /flushdns
macOS는 터미널에서 실행할 수 있다:
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
Linux에는 모든 배포판에 통하는 캐시 명령이 하나로 정해져 있지 않다. 시스템이 systemd-resolved를 쓴다면 실행하자:
sudo resolvectl flush-caches
nscd를 쓰는 시스템에서만 nscd를 재시작하면 된다. 이런 서비스를 켜두지 않았다면 그대로 따라 할 필요 없다. sudo nscd restart는 범용적인 서비스 관리 방식이 아니다.
그다음 브라우저를 다시 열고, GitHub 페이지, 이미지, 저장소 파일이 각각 로드되는지 확인하자. Linux에서는 getent hosts github.com으로 시스템 해석 결과를 볼 수도 있다. nslookup은 보통 DNS를 직접 조회하기 때문에, 이것만으로 hosts가 적용됐는지 판단할 수는 없다.
첫 페이지는 열리는데 raw 파일이나 아바타가 여전히 실패한다면, 해당 도메인이 프로젝트에서 관리하는 범위에 들어 있는지 확인하자. 연결이 계속 타임아웃되면 방금 추가한 레코드를 되돌리고, 네트워크, 프록시 정책, 방화벽을 계속 점검하자. 인증서 검증을 꺼서 문제를 덮으려 해서는 안 된다.
참고: 프로젝트 설명, systemd-resolved 문서.