깃허브 clone·Actions 시간 초과? raw.githubusercontent.com 포함 Clash 분할 규칙 실측

왜 깃허브 clone 타임아웃과 GitHub Actions 실패가 같이 보이나

개발자가 자주 겪는 패턴은 이렇습니다. 터미널에서 git clone·git fetch가 중간에 멈추거나 RPC failed류 메시지가 나오고, 같은 날 셀프 호스티드 러너나 사내 CI에서 GitHub Actions 작업이 아티팩트 다운로드·캐시 복원 단계에서 반복 실패합니다. 원인이 항상 “깃허브가 다운됐다”는 뜻은 아닙니다. 저장소 메타데이터용 API 트래픽, 대용량 객체를 실어 나르는 CDN 이름, 그리고 구형 스크립트가 curl로 가져오는 raw.githubusercontent.com 같은 정적 호스트가 서로 다른 경로·다른 품질의 출구로 나가면, 한쪽만 지연돼 전체 파이프라인이 끊기는 일이 흔합니다.

이 글은 Clash·Mihomo 계열에서 Clash 규칙과 분할을 이용해 깃허브 관련 호스트를 한 덩어리로 묶고, 노드 선택·DNS·규칙 순서를 맞추는 절차에 초점을 맞춥니다. 직장·학교 정책과 서비스 약관·현지 법규를 지키는 범위에서, 이미 합법적으로 프록시를 쓸 수 있는 환경을 전제로 기술적으로 정리합니다.

참고: 깃허브는 인프라를 자주 조정합니다. 아래 도메인 목록은 출발점이며, 실패한 요청의 실제 호스트명을 로그로 확인한 뒤 DOMAIN 또는 DOMAIN-SUFFIX 한 줄씩 보강하는 방식이 가장 정확합니다.

패키지·컨테이너 글과의 관계 (npm 타임아웃·Docker)

레지스트리나 컨테이너 허브는 보통 특정 패키지 관리 호스트 묶음이 전부입니다. 반면 깃허브는 브라우저로 보는 웹(github.com)과, 패킷 레벨로는 전혀 다른 이름의 CDN 라인(*.githubusercontent.com)이 동시에 등장합니다. 그래서 npm 설치 장애 분할 글에서처럼 “레지스트리 접미사만” 덮으면 패키지는 살아도 raw.githubusercontent.com 스크립트는 여전히 DIRECT로 나가거나 반대로 느린 프록시에만 걸리는 불일치가 생깁니다. 본문에서는 깃 허브 전용 전략 그룹을 두고, 메인 도메인과 usercontent 축을 같은 그룹에 넣거나, 증상에 따라 두 그룹으로 쪼개는 패턴을 함께 다룹니다.

Clash 분할에 두기 좋은 깃허브 후보 호스트

실측된 FQDN을 최우선으로 하되, 초기 프로필에 올리기 좋은 후보는 다음과 같습니다.

  • 웹·API 얼굴: github.com — 브라우저와 REST·그래프QL 클라이언트가 함께 거칩니다. 넓게는 DOMAIN-SUFFIX,github.com 한 줄이지만, 사내 정책상 일부 경로만 우회해야 한다면 로그를 보며 좁히세요.
  • 원시 파일·스크립트: raw.githubusercontent.com — 설치 스크립트·작은 바이너리·구성 스니펫을 끌어올 때 자주 보입니다. 여기만 끊기면 웹 UI는 정상인데 CI만 실패하는 전형적인 케이스가 됩니다.
  • 사용자 콘텐츠·아바타·에셋: githubusercontent.com 및 그 하위 — 이 접미사로 DOMAIN-SUFFIX,githubusercontent.com을 두면 raw.를 포함한 여러 하위 이름을 한꺼번에 덮기 쉽습니다. 다만 다른 서비스 트래픽과 겹치지 않는지 구독 템플릿을 함께 확인하세요.
  • 대용량 객체: objects.githubusercontent.com, codeload.github.com — 큰 저장소 git clone에서 자주 마주칩니다.
  • 패키지·레지스트리 연계: pkg.github.com 등 조직 패키지 흐름이 켜진 경우 해당 호스트가 로그에 별도로 찍히면 같은 그룹에 편입합니다.

분할의 목적은 이름마다 다른 출구와 지연 패턴을 강제로 한 줄 정책에 맞추는 것입니다. 과도하게 넓은 접미사(특정 퍼블릭 클라우드 전체 등)는 다른 업무까지 끌어올 수 있으므로, 관측부터 시작해 최소 확장을 권장합니다.

본인 노트북과 GitHub Actions 러너, 어디부터 보나

로컬에서는 OS의 시스템 프록시·환경 변수·TUN 적용 여부에 따라 깃 명령이 Clash 바깥으로 새는 경우가 있습니다. 증상이 “브라우저의 깃허브만 빠르다”면 우선 CLI가 어떤 인터페이스로 나가는지부터 맞춥니다.

GitHub Actions 호스티드 러너는 고객이 설치한 Clash와 무관하게 마이크로소프트 쪽 네트워크에서 실행됩니다. 따라서 장애가 호스티드 러너에서만 난다면 본 글의 Clash 규칙이 아니라 런타임 측 레이트 리밋·서비스 장애·방화벽·아티팩트 저장소 접근 제한을 우선 의심해야 합니다. 반대로 셀프 호스티드 러너나 사내에 설치된 작업 에이전트가 인터넷으로 직접 나가며 특정 깃 허브 CDN만 막히는 환경이라면, 해당 머신에 Clash·HTTP 프록시를 두고 규칙을 동일하게 싣는 것이 실질적인 해결책이 됩니다.

팁: 워크플로에서 재현하려면 실패 단계 바로 위에 호스트 이름을 출력하는 작은 진단 단계(curl -v 등)를 잠깐 두고 로그만 수집한 뒤, 상시로 두지 마세요. 시크릿 노출 위험을 줄입니다.

전략 그룹과 rules: 예시

개념용 축약 YAML입니다. 그룹 이름·프록시 목록은 구독에 맞게 바꾸고, 실제 환경에서 관측한 호스트를 아래 블록에 덧붙이세요. 광범위한 GEOIP·MATCH·거대 RULE-SET보다 위에 두는 것이 핵심입니다. 일반 원리는 규칙 분할 가이드와 같습니다.

YAMLproxy-groups:
  - name: "GitHub-Stable"
    type: url-test
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50
    proxies:
      - DIRECT
      # ... 지연·손실이 낮은 해외 노드 ...

  - name: "Proxy"
    type: select
    proxies:
      - GitHub-Stable
      - DIRECT
      # ... 일반 구독 노드 ...

rules:
  - DOMAIN-SUFFIX,github.com,GitHub-Stable
  - DOMAIN-SUFFIX,githubusercontent.com,GitHub-Stable
  - DOMAIN,raw.githubusercontent.com,GitHub-Stable
  - DOMAIN-SUFFIX,githubassets.com,GitHub-Stable
  # 관측으로 추가: objects.githubusercontent.com, codeload.github.com ...
  # GEOIP·MATCH보다 위에 유지

url-test용 헬스 URL은 구독 제공자 권장 주소로 바꿀 수 있습니다. 다만 짧은 헬스가 통과해도 대용량 git fetch는 다른 특성을 가질 수 있으니, GitHub-Stable 안에서 노드만 바꿔 실제 클론 시간을 재는 것이 중요합니다. GitHub Actions 단발 요청보다 레포 전체 미러링에 가까운 작업이라면 같은 그룹이라도 레이턴시보다 장기 TCP 안정성을 우선합니다.

DNS·fake-ip가 DOMAIN-SUFFIX과 어긋날 때

enhanced-mode: fake-ip를 쓰면 대부분의 경우 도메인 기반 규칙이 소켓 열리기 전에 매칭되지만, 앱이 Clash 바깥에서 이미 IP로 붙거나 OS DNS만 쓰면 Clash 규칙이 적용되지 않습니다. 터미널 깃 명령만 실패하고 브라우저만 정상이면 프록시 환경과 TUN 포함 여부를 함께 점검하세요.

DoH·시스템 레졸버가 동시에 돌아가면 “규칙은 맞는데 실제 질의 주체가 다르다”는 혼선이 나올 수 있습니다. 한 번에 한 축만 바꿔 가며 테스트하고, fake-ip-filter는 증상이 있을 때만 최소 추가합니다.

RULE-SET이 깃 허브 줄을 덮어쓸 때

구독 템플릿의 원격 규칙 묶음이 특정 접미사를 다른 정책으로 보내면, 로컬에 적어 둔 raw.githubusercontent.com 줄이 영원히 실행되지 않을 수 있습니다. 대시보드 로그에서 첫 매칭이 무엇인지 확인하고, 로컬 예외를 위로 올리거나 provider 로딩 순서를 조정하세요. rule provider 갱신 주기가 길면 오래된 세트가 상단을 오래 잡는 경우도 있으니, 충돌이 의심될 때는 스냅샷을 내려받아 텍스트로 한 번 훑는 것이 빠릅니다.

실측 점검: 로그·연결·노드 전환

아래 순서는 깃허브 clone 타임아웃을 겪을 때 그대로 밟을 수 있는 체크리스트입니다.

  1. 실패한 시점의 정확한 호스트를 터미널·CI 로그·프록시 연결 목록에서 적습니다. raw.githubusercontent.com인지 objects.githubusercontent.com인지에 따라 규칙 폭이 달라집니다.
  2. Clash 로그에서 해당 연결이 GitHub-Stable(또는 본인이 지정한 이름)으로 매칭됐는지 확인합니다. 다른 그룹이면 규칙 순서를 고칩니다.
  3. 동일한 git clone URL로 노드만 전환해 반복합니다. 모든 노드에서만 실패하면 저장소 측·DNS·MTU 등 비프록시 요인을 의심합니다.
  4. 터미널에서 프록시를 강제한 채 curl -vI https://raw.githubusercontent.com/...처럼 TLS 핸드셰이크 단계까지 도달하는지 봅니다. 여기서 멈추면 SNI·중간 장비·인증서 문제를 따로 봅니다.
  5. GitHub Actions가 대상이라면, 동일 워크플로를 호스티드 러너와 셀프 호스티드에 각각 한 번씩 돌려 어느 쪽 네트워크에서만 실패하는지 분리합니다.

주의: 출처가 불분명한 원격 rule-set은 악성 규칙이 섞일 수 있습니다. 조직 리포지토리·토큰이 오가는 프로필일수록 신뢰할 수 있는 소스만 사용하세요.

자주 묻는 질문

Q. raw.githubusercontent.com만 느리면 어떤 규칙이 맞나요?
A. 단일 호스트라면 DOMAIN,raw.githubusercontent.com,GitHub-Stable 형태가 가장 분명합니다. 주변 이름까지 함께 느리다면 DOMAIN-SUFFIX,githubusercontent.com을 검토하되, 목록 상단의 광역 규칙에 가리지 않도록 배치하세요.

Q. GitHub Actions 실패도 Clash로 해결되나요?
A. 러너가 외부망을 쓰며 특정 깃 허브 CDN에만 막히는 경우에 한합니다. 호스티드 러너라면 먼저 깃허브 상태 페이지·레이트 리밋·방화벽 아웃바운드를 보고, 셀프 호스티드라면 그 머신의 프록시·DNS를 다룹니다.

마무리

깃허브 clone 타임아웃은 한 줄짜리 MATCH로 덮었다가가 아니라, 메타데이터·객체·정적 파일이 서로 다른 이름으로 흩어져 있기 때문에 Clash 분할에서 호스트 축을 의식적으로 묶어야 안정적으로 잡힙니다. raw.githubusercontent.com은 스크립트 한 줄이 전체 설치를 막는 핀포인트가 되기 쉬우니, 로그에 보이는 즉시 Clash 규칙에 반영하는 습관이 가장 큰 개선을 가져옵니다.

일체형 VPN은 설정은 단순하지만 개발 트래픽을 호스트 단위로 나누기 어렵고, 로그로 첫 매칭을 확인하기도 불편한 경우가 많습니다. 반면 Clash·Mihomo 계열은 DOMAIN-SUFFIX와 전략 그룹으로 레이어를 쌓을 수 있어 API·CDN·정적 호스트를 분리하기에 적합합니다. 동시에 규칙 순서와 provider 신뢰도를 사용자가 책임져야 한다는 부담도 함께 따라옵니다.

ClashSource는 이런 실무 패턴을 문서화해 두었다가 그대로 프로필에 옮길 수 있게 정리하고, 설치·구독 반영 과정도 한 흐름으로 따라갈 수 있게 맞춰 두었습니다. 비슷한 “개발 도구만 타임아웃” 주제로는 앞서 인용한 npm 글·Docker 가이드와 겹치지 않도록 깃허브 호스트 세트만 따로 묶었습니다. 설치부터 다시 보고 싶다면 문서 허브의 튜토리얼 모음을 참고하시고, 프로필을 바로 받아 적용하고 싶다면 아래에서 Clash 클라이언트를 무료로 다운로드해 보세요. 브라우저와 터미널을 같은 규칙으로 맞춰 두면 같은 증상이 다시 나와도 로그 한 줄에서 원인을 좁히기가 훨씬 빨라집니다.