1 왜 Copilot 전용 튜토리얼과 다른가
GitHub Copilot 글은 VS Code 확장·api.github.com 백그라운드·쿠키 세션을 한데 묶어 «에디터 안에서 모델을 쓰는 경험»을 안정화하는 데 초점을 둡니다. 반면 GitHub Models를 Inference API로 직접 부르는 흐름은, 공개 문서 기준으로 https://models.github.ai 아래 chat/completions류 엔드포인트와 카탈로그 조회가 중심이며, 인증은 GitHub가 발급한 토큰(OAuth 세션에서 얻거나, Fine-grained PAT에 models: read 등)으로 Authorization: Bearer 헤더를 실는 패턴이 일반적입니다. 즉 Clash 분할을 설계할 때 «추론 전용 호스트»와 «계정·키·조직 정책 호스트»를 나누어 생각하지 않으면, 프록시 규칙은 맞는데 401·리디렉션 루프만 반복하는 상황이 생깁니다.
본문의 목표는 속도 경쟁이 아니라, Mihomo Connections 로그에 찍힌 실제 FQDN이 팀이 정한 프록시 그룹으로 일관되게 나가게 만드는 것입니다. 클라이언트가 없다면 다운로드 페이지에서 OS에 맞는 GUI를 고른 뒤 Rule 모드 프로파일을 켜세요.
호스트 목록은 기능 플래그·지역·조직 설정에 따라 달라질 수 있습니다. 아래는 출발점이며, 실패 직후의 SNI·호스트를 한 번 확인하는 것이 가장 안전합니다.
2 Inference API 트래픽: models.github.ai
공식 REST 문서에서 강조하는 현행 Inference API 베이스는 models.github.ai입니다. 예를 들어 OpenAI 호환 스타일의 chat completions 요청은 이 호스트 트리 아래에서 이루어지며, 모델 카탈로그·조직 단위 경로가 붙는 변형도 같은 접미사 안에서 움직이는 경우가 많습니다. 따라서 첫 단계에서는 DOMAIN-SUFFIX,models.github.ai를 전용 PROXY-GH-MODELS 그룹(이름은 예시)에 매핑해 두고, 스트리밍 응답이 길게 유지되는지·노드가 중간에 바뀌지 않는지를 확인하는 편이 재현성에 유리합니다.
여기서 중요한 점은 Inference API가 성공해도, 토큰이 만료되었거나 스코프가 부족하면 여전히 401·403이 난다는 것입니다. 네트워크 규칙만으로는 해결되지 않으므로, 동일 증상이면 먼저 토큰 종류와 권한을 점검하고 그다음에 Clash 규칙을 의심하세요.
3 OAuth·토큰·브라우저: github.com·api.github.com
GitHub Models를 쓰려면 결국 GitHub 계정 맥락에서 토큰을 준비해야 합니다. 브라우저로 github.com/login·설정·조직 승인 화면을 열 때는 github.com과 함께 githubusercontent.com·정적 자산 호스트가 붙는 일이 흔합니다. REST 클라이언트·CLI·일부 SDK는 메타데이터나 부가 호출에 api.github.com을 사용하므로, «추론 호스트만 프록시하고 나머지는 직행»처럼 과감하게 갈라 두면 쿠키·리디렉션이 꼬여 로그인만 실패할 수 있습니다.
실무에서는 (1) 계정·키·조직 정책과 연관된 GitHub 코어 호스트 묶음, (2) models.github.ai 추론 묶음을 나란히 두고, (3) 회사망 HTTP 프록시와 Clash 시스템 프록시가 이중으로 겹치지 않게 한 층만 남기는 식으로 정렬합니다. 터미널의 curl이 환경 변수 없이 DIRECT로만 나가면 IDE는 성공하고 CLI만 실패하는 패턴이 나오므로, 필요하면 TUN 모드로 프로세스 경로를 통일하세요.
직접 연결을 유지해야 할 때
팀 정책상 특정 GitHub 호스트만 사내 직링으로 두고 나머지만 해외 노드로 보내야 한다면, DOMAIN-SUFFIX 블록을 정책 순서에 맞게 쪼개되, OAuth 리디렉션 체인이 끊기지 않게 브라우저 실패 시점의 호스트를 로그로 남기는 것이 안전합니다. 반대로 전 구간을 한 그룹으로 묶어도 지연 차이가 크지 않다면 운영이 단순해집니다.
4 레거시 Azure 엔드포인트 이전
과거 문서·샘플에는 models.inference.ai.azure.com 같은 Azure 측 호스트가 등장했습니다. 공지에 따라 이 경로는 단계적으로 폐지·지원 종료가 진행되었고, 신규 통합은 models.github.ai 쪽 Inference API로 옮기는 것이 맞습니다. 오래된 스크립트·환경 변수가 여전히 Azure URL을 가리키면 DNS는 성공해도 응답이 비거나 리다이렉트만 반복할 수 있으니, 레포의 베이스 URL·SDK 기본값을 2026년 기준으로 한 번씩 점검하세요.
5 DOMAIN-SUFFIX와 규칙 우선순위
Clash 분할에서 규칙은 위에서 아래로 매칭됩니다. 거대한 GEOSITE 묶음이나 범용 Rule Provider가 구체 호스트보다 위에 있으면, 의도한 GitHub Models 전용 그룹에 도달하기 전에 흡수됩니다. PROXY-GH-MODELS를 만들었다면 (1) models.github.ai, (2) 팀에서 합의한 github.com·api.github.com 접미사 블록을 중간쯤에 두고, (3) 그 아래에 더 일반적인 규칙을 두는 식으로 읽기 쉽게 정렬하세요.
이미 OpenRouter·OpenAI 전용 그룹을 쓰고 있다면, GitHub 축 규칙이 서로 덮어쓰지 않는지 순서를 확인합니다. 지나치게 넓은 DOMAIN-KEYWORD는 오탐이 나기 쉬우니, 장기 운영에서는 접미사·정규식 규칙을 조합하는 편이 낫습니다.
6 Rule Provider로 목록을 버전 관리하기
호스트가 늘어날수록 YAML에 직접 붙여 넣기보다, 사내 Git 저장소에 텍스트 목록을 두고 Rule Provider로 끌어오는 방식이 유지보수에 유리합니다. behavior: classical 목록을 올려 두고 RULE-SET,github-models-2026,PROXY-GH-MODELS처럼 참조하면, 긴급 한 줄 패치는 수동 규칙으로, 주간 동기화는 Provider로 나눌 수 있습니다. 릴리스 주기가 빠른 Inference API 시즌에는 이 패턴이 특히 편합니다.
개인 보강만 분리하고 싶다면 mixin·구독 덮어쓰기로 팀 베이스 위에 로컬 오버레이를 얹는 방법도 있습니다. 구독 YAML 형식이 다르면 구독 변환 가이드로 맞춘 뒤 규칙을 얹으세요.
7 YAML 예시 (개념 스니펫)
아래는 병합용 예시입니다. PROXY-GH-MODELS는 본인의 proxy-groups 정의와 이름을 맞추고, 상위 규칙과 충돌하지 않게 순서를 조정하세요. 실제 배포 전에는 반드시 Connections 로그로 검증합니다.
# GitHub Models inference (current documented host family)
- DOMAIN-SUFFIX,models.github.ai,PROXY-GH-MODELS
# Account, REST metadata, OAuth-related GitHub core (often same exit as above)
- DOMAIN-SUFFIX,github.com,PROXY-GH-MODELS
- DOMAIN-SUFFIX,api.github.com,PROXY-GH-MODELS
- DOMAIN-SUFFIX,githubusercontent.com,PROXY-GH-MODELS
# If your org policy requires splitting, duplicate blocks with DIRECT vs PROXY.
# Keep this block above overly broad GEO / catch-all rules.스트리밍 응답은 긴 세션을 유지하므로, 노드를 자주 바꾸지 말고 한 요청을 끝까지 같은 출구로 보내는 것이 재현성에 유리합니다. 필요하면 url-test·fallback 그룹 전략을 함께 검토하세요.
8 SDK·CLI·환경 변수 정렬
공식·커뮤니티 SDK는 baseURL을 models.github.ai 트리에 맞추고 apiKey 자리에 PAT를 넣는 예제가 많습니다. 로컬에서는 HTTPS_PROXY·NO_PROXY를 수동으로 맞추기보다, Clash 시스템 프록시 또는 TUN으로 프로세스 경로를 통일하는 편이 덜 헷갈립니다. CI에서는 러너가 프록시를 모를 수 있으니, 조직 표준에 맞게 에이전트 환경 변수를 명시하세요.
curl로 최소 요청을 재현할 때는 호스트·TLS SNI·프록시 레이어를 한 번에 의심합니다. 성공하는 최소 샘플을 만든 뒤 IDE·에이전트로 확장하면 디버깅이 빨라집니다. 관련해 IDE 확장 전반은 Cursor·Clash 글의 프록시 체인 점검과도 맞물립니다.
9 DNS·TUN·시스템 프록시
규칙이 맞아도 DNS가 ISP 쪽으로 새면 지역 응답이 엇나가 매칭 전에 실패하는 것처럼 보입니다. DoH·FakeIP 가이드에 맞춰 Clash DNS·OS 리졸버·TUN을 정렬하세요. WSL·Docker 안에서 호출하면 호스트 OS의 프록시 설정과 또 다른 격리망이 생기므로, 동일 머신에서 브라우저·컨테이너·네이티브 바이너리의 기본 라우트를 한 번에 그려 보세요.
10 트러블슈팅 체크리스트
- 추론은 되는데 토큰만 401: PAT 스코프·만료·Fine-grained 저장소 범위를 먼저 확인합니다.
- 브라우저 로그인만 실패:
github.com과 자산 호스트가 서로 다른 출구로 갈라졌는지 Connections 로그로 확인합니다. - 레거시 Azure URL을 가리킴: 베이스 URL을
models.github.ai계열로 교체합니다. - IDE는 되고 터미널만 실패: 프록시 환경 변수·TUN 적용 여부를 확인합니다.
- 간헐적 호스트 추가: 로그를 캡처해 Rule Provider PR에 반영합니다.
11 약관·키 보안·망 정책
연결이 안정되어도 GitHub Models·GitHub 이용약관·조직 보안 정책은 그대로 적용됩니다. 본문은 합법적인 개발 환경에서의 Clash 분할 구성을 설명할 뿐, 통제된 네트워크를 우회하라는 뜻이 아닙니다. API 키는 저장소에 올리지 말고 비밀 관리 도구에 두세요. 클라이언트 소스는 공개 저장소에서 확인할 수 있으나, 설치 패키지는 사이트 다운로드 페이지를 우선하는 편이 출처 관리에 유리합니다.
12 정리
2026년 GitHub Models와 Inference API는 터미널·에이전트·CI에서 «해외 API를 안정적으로 부른다»는 관점에서 Clash·Mihomo와 잘 맞습니다. 네트워크 측면에서는 models.github.ai 추론 축과 OAuth·토큰·REST 메타데이터가 쓰는 GitHub 코어 축을 한 규칙 세트로 정렬하고, 레거시 Azure 호스트를 걷어 내며, DOMAIN-SUFFIX·Rule Provider로 팀이 재현 가능한 출구를 유지하는 것이 핵심입니다. 에디터 플러그인 중심 시나리오는 Copilot 글, 패키지·MCP 축은 MCP 글을 참고하면 주제가 겹치지 않습니다.
동급 GUI에서 규칙을 저장해 두면 팀원이 같은 Clash 분할로 Inference API 경로를 재현하기 쉽습니다. Rule 편집기·로그 뷰가 잘 보이는 제품을 고르면 운영 스트레스가 줄어듭니다.
→ Clash를 무료로 내려받아 GitHub Models·Inference API 경로를 한 규칙으로 맞춰 보세요
