Gemini CLI가 계속 타임아웃·OAuth 실패? 2026년 Clash 분류·DNS로 터미널부터 나누기

① 웹 Gemini와 Gemini CLI가 Clash 규칙에서 왜 다른가

크롬에서 gemini.google.com을 열면 콘텐츠·폰트·계정까지 수십 개 호스트가 동시에 붙지만, 사용자는 한 화면으로만 결과를 받습니다. 반면 Gemini CLI는 터미널 안에서 실행되며 보통 다음 경로들이 순서대로 또는 병렬로 나갑니다. 첫 번째 블록이 막히면 뒤 단계까지 가지 않아 증상만 보면 「전체 타임아웃」으로 보일 수 있습니다.

• 브라우저 기반 로그인: 로컬 호스트 혹은 루프백으로 돌아오는 OAuth 콜백과 accounts.google.com·ssl.gstatic.com 등 인증 세트가 같이 필요합니다.
• API 호출 본류: 터미널에서 Gemini 기능을 쓰면 generativelanguage.googleapis.com 및 주변의 *.googleapis.com 트래픽 비중이 상대적으로 큽니다. 문서 참고용이라면 ai.google.dev가 같이 불릴 수도 있습니다.
• 앱 업데이트·바이너리: 설치 방법에 따라 패키지 인덱스나 릴리스 호스트까지 붙으며, 여기까지 한 턴에 실패 원인 분석이 들어오면 디버깅이 산만해집니다. 그래서 이 글에서는 먼저 Gemini CLI 본 기능에 해당하는 이름 해석과 매칭 경로부터 고립합니다.

브라우저에는 잘 적용되는 시스템 프록시가 터미널 셸·일부 바이너리에는 아예 무시되는 경우도 있습니다. Windows와 리눅스는 예외 패턴이 달라, 동일 규칙 파일이라도 시스템 프록시만 켠 상태와 TUN을 켠 상태에서 증상이 갈립니다. 이 차이만 이해하면 “Clash 분명 켜 뒀는데” 하는 체감이 설명 가능해집니다.

② Clash 규칙에 넣을 도메인 후보: Google Generative Language API 중심

서비스 측 호스트 이름은 업데이트될 수 있으므로 아래 표는 「규칙 후보 세트」이지 완전한 화이트리스트가 아닙니다. 진짜로 필요한 이름은 반드시 실패 직후 Clash 로그에 붙여 확인하는 것을 권장합니다. Gemini 웹 전용 규칙만 있고 터미널 라인이 빠져 있었다면 증상이 그대로 재현됩니다. 웹 쪽 패턴과의 차이는 기존 Google Gemini 분류 글과 비교하면 이해하기 쉽습니다.

• Generative Language API: DOMAIN-SUFFIX,generativelanguage.googleapis.com,PROXY처럼 먼저 좁히는 편이 일반 사용자에게 디버깅이 쉽습니다.
• 더 넓은 Google API 패밀리: 로그에서 반복된다면 DOMAIN-SUFFIX,googleapis.com,PROXY까지 확장 가능합니다만, 같은 서픽스를 쓰는 다른 구글 서비스까지 같은 출구로 가므로 업무 패턴과 충돌하지 않을지 검토해야 합니다.
• OAuth·계정: accounts.google.com, oauth2.googleapis.com, 필요 시 people.googleapis.com 같은 조각이 따라올 수 있습니다.
• 공통 정적 리소스: 브라우저 OAuth 창까지 하나의 흐름으로 검증 중이라면 gstatic.com·일부 googleusercontent.com이 로그에서 같이 매칭되는지 확인합니다.

③ YAML 예시: 터미널 Gemini를 위한 최소 분류 순서 개념

아래 블록은 개념 스케치입니다. PROXY 자리에는 본인 프로필의 프록시 그룹 이름을 넣어야 하고, 국내에 반드시 DIRECT로 둘 Google 서브도메인이 있다면 그 규칙을 위쪽에 같은 서픽스보다 우선 또는 예외 처리합니다. 순서 해석 규칙이 낯설다면 사용자 정의 규칙 튜토리얼 문법과 순서부터 맞추는 것을 추천합니다.

# rules excerpt — Gemini CLI oriented; rename PROXY to your group
rules:
  - DOMAIN-SUFFIX,generativelanguage.googleapis.com,PROXY
  - DOMAIN-SUFFIX,ai.google.dev,PROXY
  - DOMAIN-SUFFIX,oauth2.googleapis.com,PROXY
  - DOMAIN-SUFFIX,accounts.google.com,PROXY
  - DOMAIN-SUFFIX,gstatic.com,PROXY
  # widen only when logs repeatedly show other *.googleapis.com
  - DOMAIN-SUFFIX,googleapis.com,PROXY
  - MATCH,DIRECT

맨 마지막을 DIRECT로 꽉 두는 패턴은 국내 사이트·사내 업무 라인까지 프록시에 넣지 않으려 할 때 많이 씁니다. 반대로 아무 증거 없이 무조건 MATCH를 바꿔 전체 트래픽을 우회하게 두면 테스트는 빨라질 수 있지만, 업무 패턴과 대역폭 면에서는 비추입니다. 최소 구성에서 막히는 도메인이 보이면 그때 로그 줄 하나를 추가식으로 규칙에 더하는 접근이 누적 가독성이 좋습니다.

④ DNS 레이어: fake-ip와 DoH 이중 처리, 조회 소스 불일치

Gemini CLI 관련 증상 중 상당 부분은 패킷이 빠져서가 아니라 이름이 잘못 풀렸거나 OS와 Clash 코어가 보는 결과가 다른 경우입니다. fake-ip를 쓰는 프로필에서는 브라우저 플러그인이나 다른 VPN이 같은 시점에 DoH를 강제할 때 간헐적 실패 패턴이 납니다. 먼저 한 경로만 남겨 테스트하는 것이 중요합니다. 심층 순서나 TUN 안에서 이름이 어디로 새는지는 TUN 모드와 DNS 글의 체크리스트와 맞물립니다.

리눅스 데스크톱은 systemd-resolved, macOS도 스텁 리졸버를 통하는 경우가 있어 단순히 dig generativelanguage.googleapis.com @8.8.8.8 결과만 보고 “DNS 맞네” 하기 어렵습니다. 터미널 셸이 실제 어떤 리졸버 설정을 받는지, Clash 로그에는 어떤 DOMAIN 줄이 같은 타이밍에 찍히는지 교차해야 합니다. IPv6 레코드 우선이라면서 실제 패킷은 네 노드 구간에서 떨어지는 상황도 있으므로, 한동안이라도 같은 조건으로 IPv6를 맞춰 보거나 끊어 보고 비교하는 것이 디버깅에 도움이 됩니다.

⑤ Rule과 Global으로 원인 빠르게 가르기

진단 순서에서는 잠깐 Global(또는 사실상 전체 출구 선택) 상태를 켠 뒤 동일 명령을 다시 실행해 보고, 증상이 사라지면 규칙 누락·GEOIP 순서 역전·잘못된 DIRECT 우선 매칭 같은 쪽을 의심합니다. Global에서도 시간 초과만 반복된다면 노드 레이턴시·패킷 드랍·방화벽·TLS 차단 줄을 따라가야 합니다. 규모가 큰 proxy-groups 설계는 프록시 그룹 가이드 형태로 정리되어 있으므로 테스트용 간단 프로필을 따로 두고 비교하면 혼선이 줄어듭니다.

Windows에서는 WSL 안의 터미널이 호스트 Clash 포트만 보거나 아예 다른 테이블로 나가 분리되는 경우도 있습니다. WSL 안에서 패키지·CLI를 도는 패턴이라면 WSL2와 Clash 분리 글의 순서를 같이 놓고 보면 좋습니다. 즉 Gemini CLI 같은 터미널 문제는 DNS 결과 한 줄만 맞춰 보려는 것보다 레이어망을 순서대로 벗겨 내는 편이 빠르게 결과를 줍니다.

⑥ 단계별 실측 순서 요약 — 터미널 AI 워크플로에 적용하기

1. 프로필 백업 후 동일 테스트를 반복할 수 있도록 터미널 명령을 메모합니다.
2. 실패 직후 Clash 로그에서 방금 실패 세션 안의 모든 RULE 대상 호스트를 옮겨 적습니다.
3. 로그 호스트별로 규칙에 없던 이름을 DOMAIN-SUFFIX 또는 DOMAIN-KEYWORD로 추가합니다. OAuth 전용 줄은 순서 상단쪽에 두는 편이 덜 헷갈립니다.
4. fake-ip 해제 테스트 또는 DoH 하나만 두는 테스트로 DNS 경로 차이가 있는지 비교합니다.
5. 시스템 프록시 대 TUN을 교체해 같은 명령이 일관되는지 확인합니다.
6. 여전히 막히면 회사 장비 여부와 TLS 차단 가능성까지 넓히고 정책 범위를 조정합니다.

처음이라면 플래그 줄마다 긴 도움말을 두기보다, 위 순서처럼 로그 증거—규칙 한 줄 추가—재현 루프를 돌며 체계를 잡는 방식을 추천합니다. 초기 입문에는 Clash 입문 튜토리얼 개념을 익힌 뒤 이 글이 훨씬 수월해집니다.

⑦ 자주 묻는 형태와 오해 하나씩 줄이기

검색 엔진에서 모이는 패턴 중 하나는 브라우저 OAuth 화면이 잠깐 떴는데 즉시 끊긴 경우입니다. 이 때는 종종 규칙이 아니라 콜백 포트를 다른 보안 프로그램이 막거나, 로컬 루프백 처리가 간섭 받는 줄을 같이 확인해야 합니다. 또 다른 패턴은 모델 목록 API만 간헐적으로 실패하면서 채팅 본 기능은 된다처럼 말하는 보고입니다. 같은 API 호스트더라도 엔드포인트별로 속도 차가 커져 보일 수 있으니 로그 줄을 나누어 보관하는 버릇을 들이세요.

일부 사용자는 Gemini CLI 이름을 따라 “항상 새로 깔았다 재시작”만 반복하면서 증명 없이 교체하지만 재현 속도 면에서는 오히려 느려집니다. 한 세션에서는 한 변인만 고친 결과를 확인하는 접근을 권합니다. 브라우저와 터미널 사용자 경험이 전혀 달라서, 웹 Gemini 문서 하나만 따라와서는 같은 만족이 나오기 어렵다는 걸 사용자 입장에서는 모를 수 있습니다. 그 간극을 이 글이 메우도록 구성했습니다.

⑧ 지역 규약·약관 준수

Gemini 또는 Google 클라우드 제품 이용 지역 조건과 조직 내부 정책은 제품 업데이트와 함께 바뀔 수 있습니다. 이 글은 합법적 범위에서의 연결 신뢰성·네트워크 분류 표현을 다룹니다. 개인이라도 과금·토큰·데이터 처리 정책은 공식 안내와 맞춰야 하며 회사에서는 IT 허용 범위가 우선입니다.

⑨ 선택 정리 도구 관점과 Clash 쪽 선택지

일반적으로 말해서, 전 구간 하나의 고정 터널 방식 도구들은 간단하게 쓰기 좋지만, 터미널 패키지·브라우저·VPN·메신저까지 모두 같은 경로를 태우면서 속도 표면상으로만 깔끔해졌을 뿐 스플릿 라우팅이 어렵습니다. Clash처럼 목적 도메인을 분리해 프로필별로 패턴 재사용하면, 웹 접속 패턴과 Gemini CLI 테스트 패턴을 다른 YAML로 깔아 두고 교체 테스트하는 속도 차이도 체감됩니다. 반복 테스트마다 새로 인스턴스를 띄워야 하는 흐름보다 규칙 한 줄 교체 재시작이 시간을 덜 들이니 개발 업무 패턴에는 이런 접근을 선호하기도 하죠. 설치 패키지만 자주 새로 깐다면 설정 자체의 원인 검증 순서까지 같이 깨져 복귀 시간이 더 길어질 수 있습니다. 패턴을 깔아 두고 이름 해석 증거를 남긴 뒤 조정했다면 결과가 같은 실패에서도 학습 속도가 달라집니다.

→ Clash를 내려받아 프로필에 위 후보 라인부터 반영하면서 터미널 Gemini 흐름을 다시 잡아 보세요.