이 글이 맞는 증상

2026년 현재 터미널에서 GitHub Copilot CLI나 에디터 내 터미널 에이전트(Copilot 채팅 확장보다 더 하위 레이어의 CLI·도구 실행)를 쓸 때, 웹 브라우저로는 GitHub 본 페이지와 Copilot 패널이 열리는데 CLI만 timeout·connection reset·무한 로딩처럼 느린 뒤 실패한다면 이 글의 순서대로 좁히는 것이 효과적입니다. 때로는 microsoft.com 계열 로그인 한 단계까지만 간단히 깨져서 토큰이 비어 에이전트가 멈춘 것처럼 보이기도 합니다.

전제 클라이언트는 Clash Verge Rev(이하 CVR) 또는 동일 Mihomo 계열 규칙 엔진을 쓴다고 두고, 호스트별 분기 규칙과 HTTPS_PROXY 같은 환경 변수, 선택적 시스템 프록시·TUN을 한 흐름으로 정렬하는 실무 순서입니다. 특정 서브 이름이나 장기 변경될 수 있는 엔드포인트 문자열에는 완전히 의존하지 않고 로그 기반 검증 패턴을 적어 두었습니다.

왜 브라우저는 되는데 Copilot CLI와 GitHub API 터미널만 더 자주 깨질까

브라우저는 OS가 제공하는 시스템 프록시를 잘 따르고 확장마다 라우팅이 갈립니다. 반면 로컬 터미널에서 돌아가는 GitHub Copilot CLI(및 같은 프로세스 트리의 보조 라이브러리)는 별도 표준 라이브러리로 직접 TLS를 열거나, 명시적인 프록시 환경 변수가 없으면 회사망·국경 구간처럼 회선 차단 레이어를 그대로 박아 타임아웃으로 보입니다.

또 다른 대표 패턴은 분기 규칙 오판입니다. 구독의 GEOSITE 또는 커스텀 목록 때문에 api.github.com이 DIRECT로 떨어져 회사 방화벽에 걸리거나, 불안정한 업스트림으로만 묶이는 경우가 있습니다. 브라우저는 사용자가 선택한 다른 출구 확장 때문에 된다로 보였는데, CLI는 순수 회선 경로만 탄다면 동일 증상이 아닌 것처럼 느껴져 디버깅이 헷갈립니다.

Microsoft 로그인 디바이스 코드·브라우저 연동 과정에서는 짧게 뜨는 브라우저 창은 성공해도, 이후 CLI가 교환해야 하는 호스트가 프록시를 타지 못하면 두 번째 홉에서만 깨지는 패턴도 자주 있습니다. 따라서 증상이 처음부터 안 된다보다 로그인 거의 다 됐을 때 멈춘다에 가까우면 Microsoft ID·OAuth 관련 문자열까지 규칙과 환경 변수 범위에 함께 넣어야 재현 가능한 안정 상태가 나옵니다.

먼저 머리에 둘 도메인·API 범주(목록 고정 금지)

공개 문서·커뮤니티에서 자주 거론되는 축으로는 다음이 있습니다만, 버전 업이나 엔터프라이즈 SSO가 붙으면 변합니다.

  • Git 본 저장소·메타 — 예: github.com
  • REST 계열 호출 자리 — 예: api.github.com (GitHub API 문서 및 Copilot 에이전트 연동 호출이 많이 거쳐감)
  • Microsoft 인증·그래프 — 예: login.microsoftonline.com, graph.microsoft.com 계열 등 (Microsoft 로그인·조직 테넌트가 있으면 증가)
  • 부가 기능 — 예: 패키지·telemetry·향후 새 호스트 추가

여기까지는 검색 흐름에 맞춘 키워드 앵커이고, 설정 YAML을 손보기 전에는 반드시 CVR 접속 패널이나 Mihomo 로그에서 실제로 깨졌던 호스트 문자열을 한 줄 확보해야 합니다. 그 문자열은 곧 규칙 줄의 신뢰도가 됩니다.

규칙 분기 중심과 TUN: 무엇을 먼저 맞출까

글로벌 TUN 한 방은 모든 앱 트래픽을 한 번에 같은 인터페이스로 빼내 좋지만, 회사 노트북의 Always-On VPN, 백신·SSL 검사 프록시, 혹은 MDM 정책과 레이어만 겹쳐도 핸드셰이크 문자열만 달라지고 원인 역추적이 어려워질 수 있습니다. 반대로 규칙 모드·mixed-port 조합은 어떤 호스트가 어느 정책 그룹을 탔는지 로그 한 줄 한 줄 따라가며 터미널 에이전트만 비교 테스트하기 좋습니다.

브라우저에는 시스템 프록시로 같은 mixed-port를 향하게 맞추고, CLI에는 HTTPS_PROXY=http://127.0.0.1:<포트>처럼 동일 로컬 입구를 쓰게 하면 웹만 됨 현상 대부분은 바로 줄어듭니다. TUN 추가는 회선 규격상 정말 전역 가로채기가 필요해진 뒤에 넣어도 늦지 않습니다.

팁: Windows·macOS 업데이트 직후 프록시 환경 변수가 IDE가 띄운 통합 터미널에만 초기값으로 빠지는 버그 패턴을 본 적이 있습니다. 새 창까지 열지 말고, 변수 수정 후 해당 터미널 탭 세션 종료 후 재실행으로 같은 부모 트리를 유지했는지 확인하세요.

1단계: Clash Verge Rev 코어와 mixed-port 기록

활성 프로필이 올바른 구독·로컬 보정 규칙을 읽었는지, 코어 업데이터가 장애 상태는 아닌지 먼저 봅니다. 구독 갱신으로 규칙 우선순위가 바뀌면 예전에 통과하던 줄이 새로 들어오며 GitHub API만 다른 그룹으로 튀기도 해서 업데이트 시각 메모가 재발 분석에 유용합니다.

mixed-port 번호를 메모합니다. 다른 앱이 그 포트를 선점했다가 자동 증분된 번호 위에 고정 문자열 프록시 URL을 놓아 두었다면 증상이 그대로인 함정이 되기 때문입니다.

2단계: GitHub Copilot CLI 관련 호스트 규칙 분기 검사

앞 장의 예시 문자열을 모두 신빙하지 말고, 실패 직후 CVR 접속 목록에서 SNI 또는 Host 헤더 문자열과 일치하게 규칙을 새로 깔거나 기존 그룹 이름을 교정합니다.

  • 우선 순위 확인 — 사용자 정의 줄이 목록 더 위쪽에서 DIRECT로 잘라먹고 있지 않은지 검사합니다.
  • 정책 그룹 — 지연안정이 필요한 업스트림(체인 포함) 하나로 묶어두었다면 SLA가 깨져도 동일 줄로 다시 테스트하기 쉽습니다.
  • GEO 충돌 — GITHUB류 태그를 기대했는데 같은 호스트명이 다른 MATCH 줄아래로 가는 패턴입니다.

기업 사용자는 SSO·테넌트 프록시 때문에 Microsoft 로그인용 호스트가 공개 블로그 목록보다 많을 수 있습니다. 새 호스트 문자열은 팀 규칙 레포 README에 한 줄 근거 메모까지 남기면 온보딩 속도가 오릅니다.

3단계: 터미널 환경 변수 — HTTPS_PROXY와 NO_PROXY

HTTPS_PROXY 및 HTTP_PROXY, 일부 스택이 읽는 ALL_PROXY, 그리고 NO_PROXY(또는 no_proxy)까지 한 세트로 다룹니다.

# Example-only: adjust port to your mixed-port value
export HTTPS_PROXY=http://127.0.0.1:7890
export HTTP_PROXY=http://127.0.0.1:7890
export NO_PROXY=localhost,127.0.0.1,::1,*.local

예시 변수만 복사해 쓰지 말고 실제 회사망이라면 레지스트리·내부 API 문자열까지 NO_PROXY 목록으로 빼거나, 회사 허브 전용 줄을 규칙에서 DIRECT 처리하는 이중 패턴 중 하나와 맞물리게 작성합니다.

경로 선택은 사용자마다 다릅니다만, 계정 전역에 항상 켠 export보다 조건문이 있는 셸 스니펫, 혹은 direnv, 혹은 GitHub Copilot CLI만 띄우는 별도 터미널 프로파일에만 넣어 프록시 흔적을 줄이면 조직 정보 보안 측에서도 받아들이기 쉽습니다.

에디터 에이전트·서브 프로세스 상속까지 확인

VS Code·Cursor·JetBrains 계열 통합 터미널은 IDE가 시작될 때의 환경 스냅샷을 아이에게 넘길 때가 많습니다. HTTPS_PROXY를 고친 다음에만 열린 윈도우에서는 옛값이 계속 타는 줄만 보고 헛고생하기 쉬우므로 IDE 재실행 또는 터미널 패널 전체 재생성 순서까지 문서에 적어 두면 팀 채널 질문이 줄어듭니다.

일부 플러그인이 호스트 이름을 새로 불러 오면 초기 테스트 때는 규칙이 맞았는데 에이전트 업데이트 직후 새 서브도메인을 만나 다시 깨지는 경우도 있습니다. 그때에는 동일 순서를 반복하면서 새 문자열만 규칙에 append합니다.

Microsoft 로그인 문자열 불일치 줄이기

Microsoft 로그인 흔적을 프록시 로그 타임라인 상에서 GitHub 줄과 교차 검증하면 어느 홉부터 느려졌나가 바로 분리됩니다. 브라우저 팝업은 회사 디바이스 인증 브라우저 프로파일을 따르지만, 교환 라이브러리 호출은 순수 회선이라면 간격이 발생합니다.

대시보드 링크 변경·리다이렉트 체인이 길 경우 중간 호스트 이름이 순간적으로 새로 깔리기도 하는데 이때 규칙 엔진이 캐시와 타이밍 경쟁을 벌여 DNS만 실패처럼 보이는 순간적 현상도 있습니다. 따라서 증명은 항상 두 번 연속 같은 호스트 줄로 확인합니다.

DNS 누설·필터와 GitHub HTTP API 지연 분리하기

터미널에서 들어오는 이름 해석 결과가 회사 재귀 또는 공용 재귀로 갈린다 시점에만 패킷 라우팅이 달라지는 패턴입니다. 브라우저는 DoH를 켠 사용자 프로파일이 있고 CLI는 순수 재귀로만 간다 같은 상황이면 증상이 달라집니다.

CVR 또는 Mihomo 설정에서 이름 해석을 코어 블록 어디에 두었는지(시스템·도트·패턴)와 회사 정책이 허용하는지 같이 검토해야 합니다. 위반 위험이 있거나 법 규제가 있는 회선에서는 회사 IT가 승인한 프록시·DNS만 따라야 한다는 자기 제한 노트까지 남길 필요가 있습니다.

4단계: 시스템 프록시·TUN과의 교차 검증

macOS와 Windows에서는 CVR 연동 후 OS 프록시가 가리키는 포트 번호와 127.0.0.1:<mixed-port> 문자열 일치부터 다시 봅니다. TUN을 동시에 켠 상태라면 두 경로 동시 존재 때문에 한쪽 레이어만 느린 MTU 패턴까지 생길 수 있어 이중 우회에서는 한 줄씩 끄며 비교하는 것이 가장 빠릅니다.

주의: HTTPS_PROXY를 넓게 퍼뜨리면 패키지 인덱스·컨테이너 이미지·내부 REST까지 같은 출구 문자열을 강제하게 됩니다. NO_PROXY와 조직 허브 네임스페이스 예외 규칙을 동시 관리해야 사고 줄어듭니다.

5단계: 여전히 타임아웃일 때 좁히기 순서

  1. 동일 시간대 브라우저로 같은 호스트에 HTTPS가 즉시 열리는지 확인합니다.
  2. CVR 접속 패널에서 문제 호스트 줄이 어떤 정책 그룹에 찍히는지 봅니다.
  3. 터미널에서 의도하지 않게 남아 있는 과거 변수를 추출·제거 후 세션 교체합니다.
  4. DNS 문자열 교차 테스트로 누설·필터를 배제했는지 봅니다.
  5. 노드 품질 문제가 아닌 순수 MTU·패킷 로스·이중 VPN 패턴으로 축약합니다.

팀 레포 규격으로 문서화할 때 유용한 항목

여러 개발자가 같은 GitHub Copilot CLI 버전 줄을 타면 변수명은 같아도 회선 상태가 조금씩 달라 채널 질문이 반복되기 마련입니다. 루트 README에 선택적 블록으로 mihomo 패턴 줄 요약표와 변수 키 목록만 올려 두고 값은 각자 로컬에 두는 방식을 권장합니다. 접두사를 레포 이름에서 따와 CI와 동일 문자열 충돌을 피하는 것도 깔끔합니다.

자주 묻는 질문

Q. Copilot 라이선스에 따른 차이는 무엇이 있나요?
A. 과금 플랜·조직 정책에 따라 허용 API 범위가 달라질 수 있어 프록시만으로 해결 불가능한 403 계열 줄이 존재합니다. 회선 문자열 에러 전에 상태 코드 줄을 우선 확인하세요.

Q. WSL 안에서 같은 설정을 썼는데 접속 거부 같은데요?
A. WSL 네임스페이스에서 127.0.0.1 해석 값이 호스트와 다르게 전달되어 Windows 측 한 포트에 붙지 못하는 패턴입니다. 해당 환경의 가이드를 따라 주소 줄을 교정합니다.

Q. 회사 규정이 터미널 우회 금지일 때 어떻게 하나요?
A. 이 문서를 정책 위반 근거로 쓸 수 없으며, 허용된 표준 egress·인증형 프록시 스펙을 IT에 요청하는 것만이 적법한 경로입니다.

정리: 단일 종합 VPN 대신 규칙 스택과 터미널 변수를 함께 쓸 이유

상용 종합 VPN 하나만 장시간 연결해 두면 체감 속도 우선에는 편하지만, 어떤 프로세스가 어떤 인터페이스를 탔는지 가시화가 줄어 들어 디버깅 문장 표면이 달라지기만 하고 속 원인 규격을 못 고치는 상태가 장기 반복되는 경우가 있습니다. 반면 Mihomo 호환 스택에서는 호스트 줄 단위로 로그 후보와 정책 그룹을 동시 확인할 수 있고, 필요 세션만 HTTPS_PROXY로 덮어 GitHub API·Microsoft 로그인 호스트를 선택적으로 안정시키기 쉬워 2026 개발자 핫스팟 트래픽 대응에도 유연합니다.

스플릿 터널 UI가 크게 부족하거나 패키지 다운로드와 AI API 줄을 한 묶음으로만 몰면 터미널 레이턴시만 따라붙었다 떠나는 순간 디버깅이 길어집니다. 분기 규칙을 유지하면서 회사 허브·로컬 루프백을 NO_PROXY로 빼 놓으면 회선 문자열처럼 보이던 시간 낭비를 경로 문자열 디버깅으로 바꿀 수 있습니다. 이미 OpenAI Codex·다른 에이전트 CLI용으로 패턴 줄을 운영 중이라면, 동일 패널 안에 호스트 줄만 증설해 팀 레포 레이턴시를 줄이는 편입니다.

여행 회선처럼 무조건 전부 우회만 중요하면 단순 종합 VPN 편지만, 회사 노트북처럼 브라우저·레지스트리·퍼블릭 API가 한꺼번에 깔린 개발 세션에서는 출구 문자열별 레이블이 없는 종합 우회 한 겹만 두면 디버깅이 길어질 수 있습니다. 호스트 줄과 HTTPS_PROXY·NO_PROXY까지 같이 들고 가면 회선 문자열처럼 보이던 시간 낭비를 경로 단위 디버깅으로 줄이고, 기능 대비 라우팅 가시화가 높은 Mihomo 엔진 계열과 Clash 호환 클라이언트가 유지보수 속도 면에서 합리적입니다.

Copilot CLI와 같은 터미널 에이전트용 Clash 호환 클라 받아 규칙 맞추기 →