이 글이 맞는 GitHub 연결 증상

Clash에서 GitHub만 접속되지 않는 문제는 노드 자체가 완전히 죽었다는 뜻이 아닐 수 있습니다. 일반 웹사이트와 동영상 서비스는 정상인데 github.com, raw.githubusercontent.com, GitHub Releases 다운로드만 오래 기다리다 실패한다면, 규칙 분기·DNS 응답·터미널 프록시 환경이 서로 다르게 적용되고 있을 가능성이 큽니다. 특히 브라우저에서는 저장소가 열리는데 git clone이나 패키지 설치 명령만 Could not resolve host, Failed to connect, Operation timed out으로 끝나는 경우가 흔합니다.

GitHub 트래픽은 하나의 주소만 사용하지 않습니다. 저장소 화면은 github.com, 원본 파일과 Raw 링크는 raw.githubusercontent.com, 이미지·정적 리소스는 별도 CDN, 로그인과 API 작업은 api.github.com을 거칠 수 있습니다. Release의 대용량 파일은 다운로드가 시작되는 순간 다른 호스트로 리디렉션되기도 합니다. 따라서 메인 화면 하나가 열린다는 사실만으로 GitHub 전체 경로가 정상이라고 판단하면 안 됩니다.

이 글에서는 Clash Verge Rev와 Mihomo 계열 클라이언트를 기준으로, 활성 프로필과 프록시 그룹을 확인한 뒤 실제 로그의 호스트를 규칙에 연결하고, DNS와 Git 명령의 프록시 설정을 순서대로 맞추는 방법을 설명합니다. Clash Verge, Clash for Windows, ClashX, Clash for Android에서도 메뉴 이름만 다를 뿐 같은 원리로 적용할 수 있습니다.

먼저 노드 문제와 규칙 문제를 구분하기

가장 먼저 해야 할 일은 여러 설정을 한꺼번에 바꾸지 않고 실패 범위를 좁히는 것입니다. Clash의 연결 로그를 열어 둔 상태에서 브라우저로 GitHub 저장소, Raw 파일, API 주소를 각각 요청해 보세요. 로그에 호스트가 나타나지 않는다면 해당 앱의 트래픽이 Clash로 들어오지 않는 것이고, 호스트는 보이지만 DIRECT로 표시되면 규칙이 프록시를 우회시키는 상황일 수 있습니다. REJECT라면 차단 규칙이나 광고 차단 목록이 GitHub 주소를 잘못 잡았는지 확인해야 합니다.

증상 로그에서 볼 항목 우선 의심할 원인
GitHub 화면 자체가 열리지 않음 github.com:443의 정책과 연결 결과 DNS 실패, DIRECT 우회, 노드 또는 TLS 문제
저장소는 열리지만 Raw 링크만 시간 초과 raw.githubusercontent.com의 매칭 규칙 서브도메인 누락, CDN 규칙 충돌, 잘못된 DNS
브라우저는 되지만 git clone만 실패 터미널 요청이 Clash 로그에 기록되는지 여부 HTTPS_PROXY 미설정 또는 Git 별도 설정
작은 파일은 되지만 Release만 끊김 리디렉션 후 새로 나타나는 호스트 대용량 CDN 분기, 연결 유지, 노드 전송 안정성

가능하면 같은 노드 그룹에서 테스트하되, 첫 번째 그룹만 고집하지 말고 두세 개의 그룹을 비교하세요. 모든 그룹에서 동일한 호스트만 실패하면 규칙이나 DNS 쪽의 공통 설정을 의심할 수 있습니다. 반대로 특정 그룹에서만 실패하고 다른 그룹에서는 즉시 연결된다면, 노드의 출구 IP·TLS 처리·국제 회선 품질이 원인일 가능성이 높습니다. 이 구분을 먼저 해 두면 무작정 구독을 교체하거나 모든 트래픽을 글로벌 모드로 바꾸는 시행착오를 줄일 수 있습니다.

팁: 로그에서 호스트명·정책 결과·프록시 그룹·실패 시각을 함께 기록하세요. “GitHub가 안 된다”보다 “raw.githubusercontent.com이 DIRECT로 나간 뒤 30초 후 실패한다”는 정보가 규칙 수정에 훨씬 유용합니다.

Clash 프로필과 GitHub 규칙 점검하기

활성 프로필부터 확인합니다. 구독을 새로 갱신한 뒤 문제가 생겼다면, 규칙 프로바이더가 업데이트되면서 GitHub 도메인의 처리 방식이 바뀌었을 수 있습니다. Clash Verge Rev의 프로필 화면에서 현재 사용 중인 설정이 실제로 실행 중인지, 코어가 오류 없이 시작했는지, 프록시 그룹에 선택 가능한 노드가 남아 있는지 확인하세요. 설정 파일을 편집했는데도 이전 동작이 계속된다면 저장만 하고 적용 또는 코어 재시작을 하지 않은 경우도 있습니다.

GitHub 관련 규칙은 너무 좁거나 너무 넓게 작성하지 않는 것이 좋습니다. 메인 도메인만 넣으면 raw.githubusercontent.com과 API가 빠질 수 있고, 반대로 DOMAIN-KEYWORD,github처럼 무리하게 넓히면 조직 내부 주소나 전혀 관계없는 도메인까지 같은 그룹에 들어갈 수 있습니다. 일반적인 출발점은 실제로 로그에 나타난 호스트를 기준으로 DOMAIN 또는 DOMAIN-SUFFIX를 추가하고, 그 아래에 원하는 프록시 그룹을 배치하는 것입니다.

규칙의 순서도 중요합니다. 상단에 GEOSITE,cn,DIRECT, 대형 광고 차단 목록, 지역별 CDN 규칙이 있으면 GitHub 관련 요청이 명시적인 GitHub 규칙보다 먼저 처리될 수 있습니다. 규칙 편집이 가능한 환경이라면 구체적인 GitHub 호스트 규칙을 적절한 위치에 두고, 마지막의 일반 규칙보다 먼저 매칭되는지 확인하세요. 설정을 바꾼 뒤에는 브라우저 캐시가 아니라 Clash 로그에서 새 정책이 표시되는지 확인해야 합니다.

모드 선택은 진단 단계와 평상시 운영을 나누어 생각하면 됩니다. 글로벌 모드에서 GitHub가 정상이라면 현재 규칙 모드의 분기가 문제일 수 있지만, 글로벌 모드는 모든 국내 사이트와 패키지 저장소까지 같은 노드로 보내므로 장기 해결책으로는 적합하지 않을 수 있습니다. 원인을 찾은 다음에는 규칙 모드로 돌아와 GitHub 계열 호스트만 원하는 그룹에 고정하는 편이 트래픽과 속도를 함께 관리하기 좋습니다.

실전 점검 순서: DNS부터 git clone까지

아래 단계는 Windows·macOS·Linux의 공통적인 흐름입니다. 명령어를 실행하기 전에 Clash의 mixed port 또는 HTTP 포트 번호를 확인하세요. 예시에서는 로컬 HTTP 프록시 포트를 7890으로 가정하지만, 사용 중인 클라이언트 화면에 표시된 값으로 바꿔야 합니다.

  1. Clash 로그를 켭니다.

    브라우저에서 https://github.com, https://raw.githubusercontent.com, https://api.github.com을 차례로 엽니다. 세 요청이 모두 로그에 기록되는지 확인하고, 각각 같은 프록시 그룹을 타는지 비교합니다. 한 주소만 DIRECT 또는 REJECT라면 노드를 바꾸기 전에 규칙을 먼저 수정하세요.

  2. DNS 응답을 확인합니다.

    운영체제의 DNS 캐시나 공유기 DNS가 오래된 주소를 반환하면 Clash 규칙이 정상이어도 연결이 지연될 수 있습니다. Clash의 DNS 기능을 사용한다면 DNS 모드, 가상 IP 범위, 리스너 충돌 여부를 확인합니다. 브라우저에서 한 번 실패한 뒤 주소가 계속 바뀌지 않는다면 DNS 캐시를 비운 다음 다시 테스트하세요. 단, 설정을 바꾸기 전 현재 값을 기록해 두어 원상 복구할 수 있게 하세요.

  3. 터미널에 프록시를 임시 적용합니다.

    macOS·Linux 셸에서는 다음처럼 현재 세션에만 환경 변수를 넣을 수 있습니다.

    export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export ALL_PROXY=http://127.0.0.1:7890

    Windows PowerShell에서는 $env:HTTPS_PROXY="http://127.0.0.1:7890" 형식으로 적용합니다. 그 후 같은 터미널에서 GitHub 명령을 실행하세요. 새 터미널이나 IDE 통합 터미널은 환경 변수를 상속하지 않을 수 있으므로, IDE를 완전히 재시작한 뒤 다시 확인해야 합니다.

  4. Git 자체 설정을 확인합니다.

    환경 변수가 있어도 Git에 오래된 프록시가 별도로 저장되어 있으면 요청이 다른 주소로 나갈 수 있습니다. git config --global --get http.proxy와 git config --global --get https.proxy로 값을 확인하세요. 예전에 사용하던 포트나 종료된 로컬 프로그램이 표시되면 테스트를 위해 해당 값을 제거하거나 현재 포트로 맞춥니다. 사내 Git 서버처럼 프록시가 필요 없는 주소는 NO_PROXY 또는 Git의 예외 설정으로 분리하는 것이 안전합니다.

  5. 작은 요청부터 재시험합니다.

    처음부터 큰 저장소를 복제하지 말고 API 응답, Raw 파일, 작은 공개 저장소 순서로 확인합니다. 마지막으로 git clone을 실행하고, 실패한다면 리디렉션 주소와 Clash 로그의 마지막 호스트를 비교하세요. 인증 오류가 나타나면 네트워크 연결은 통과한 것이므로 토큰·권한 문제를 별도로 다루면 됩니다.

Git 명령이 여전히 실패한다면 GIT_CURL_VERBOSE=1을 임시로 사용해 연결 단계를 관찰할 수 있습니다. 출력에는 호스트와 프록시 연결 과정이 포함될 수 있으므로 액세스 토큰이나 인증 헤더가 노출된 로그는 공유하지 마세요. Windows에서는 같은 목적의 Git 상세 로그 옵션을 현재 설치된 Git 버전에 맞춰 사용하고, 테스트가 끝나면 환경 변수와 디버그 옵션을 정리하는 것이 좋습니다.

자주 하는 잘못된 수정과 안정화 방법

첫 번째 실수는 모든 문제를 노드 교체로 해결하려는 것입니다. 노드가 바뀌어도 raw.githubusercontent.com이 계속 DIRECT로 처리된다면 결과는 달라지지 않습니다. 두 번째는 규칙을 지나치게 넓히는 것입니다. GitHub 전체를 무조건 글로벌 프록시로 보내면 저장소 접근은 좋아질 수 있지만, 국내 미러·사내 Git·대용량 패키지 다운로드가 느려질 수 있습니다. 실제 로그에 나온 호스트를 기준으로 필요한 범위만 묶는 편이 관리하기 쉽습니다.

세 번째는 TUN과 시스템 프록시를 동시에 켜고 어느 경로가 사용되는지 확인하지 않는 경우입니다. TUN은 브라우저뿐 아니라 프록시 변수를 읽지 않는 프로그램까지 포괄할 수 있지만, 권한·DNS·라우팅 테이블의 영향을 받습니다. 시스템 프록시는 설정이 간단하지만 앱마다 따르지 않을 수 있습니다. 먼저 한 가지 방식으로 성공 여부를 확인한 다음, 필요한 경우에만 다른 방식을 추가하세요.

네 번째는 GitHub 로그인과 Git 전송을 같은 문제로 보는 것입니다. 브라우저 로그인은 쿠키와 OAuth 리디렉션을 사용하고, git clone은 HTTPS 인증 또는 SSH 연결을 사용합니다. HTTPS Git 주소가 정상인데 SSH 주소만 실패한다면 github.com:22의 처리와 SSH 프록시 설정을 별도로 점검해야 합니다. 조직 저장소의 SSO·토큰 권한 오류는 연결 시간 초과와 다르므로, HTTP 상태와 Git 오류 문구를 구분해 기록하세요.

결국 안정적인 구성은 활성 프로필 확인 → 실제 호스트 로그 수집 → 구체적인 규칙 적용 → DNS 확인 → 터미널 프록시 정렬 → 작은 요청과 clone 검증의 순서를 지키는 것입니다. 이 순서를 문서화해 두면 구독 갱신이나 코어 업데이트 후 같은 문제가 재발해도 원인을 빠르게 비교할 수 있습니다.

일반적인 시스템 프록시는 브라우저만 쉽게 처리하고, 단순 VPN 앱은 GitHub의 Raw·API·Release 경로를 세밀하게 나누기 어렵거나 플랫폼별 설정이 달라질 수 있습니다. 반면 Clash는 연결 로그에서 실제 호스트와 정책을 확인하고, 규칙 모드와 글로벌 모드를 비교하며, mixed port를 통해 Git·터미널까지 같은 기준으로 맞출 수 있다는 장점이 있습니다. GitHub 웹페이지와 git clone을 함께 안정화할 클라이언트를 찾고 있다면, 사용 중인 운영체제에 맞는 Clash를 내려받아 이 점검 순서를 그대로 적용해 보세요.

지금 Clash를 무료로 다운로드하고 자유로운 인터넷 경험을 시작하세요 →