Google Gemini CLI·AI Studio가 번갈아 타임아웃될 때: 2026년 Clash로 명령줄·웹·API를 동시에 안정화

왜 CLI와 웹·API가 동시에 흔들려 보이는가

사용자 입장에서는 “Google AI 도구” 한 덩어리지만, 네트워크 레이어에서는 서로 다른 호스트 이름으로 TLS가 열립니다. aistudio.google.com에서 키를 만들고 프롬프트를 돌리는 흐름과, 터미널의 Gemini CLI가 붙는 API 엔드포인트, 문서·OAuth·정적 자원이 끌어오는 *.googleapis.com·*.google.com 계열이 같은 정책 그룹이 아닌 채 일부만 느린 회선으로 새면, 증상은 “타임아웃이 랜덤하게 난다”로 수렴합니다.

특히 장시간 스트리밍이나 큰 출력이 있는 호출은 TCP 세션이 오래 유지되어야 하므로, 짧은 핑 테스트에만 강한 노드가 곤란하기 쉽습니다. 브라우저는 시스템·보안 DNS(DoH)까지 끼어 들고, CLI는 환경 변수나 기본 직행 경로를 탈 수 있어 표면이 같아도 출구가 다릅니다—이때 Clash 로그 없이 “API가 불량”이라고만 단정하기 어렵습니다.

• 웹만 흔들림: SPA가 추가로 부르는 호스트·WebSocket·OAuth 리다이렉트 경로를 의심.
• CLI만 흔들림: 터미널 HTTP(S) 프록시 미적용·인증서 번들·API 베이스 URL 차이.
• 둘 다 간헐: 규칙 순서·DNS·노드 idle 타임아웃이 같은 재현에 겹치는지 확인.

거시 “국내 모델 vs Gemini” 글과의 차이

블로그의 DeepSeek+Gemini 글은 국내형과 Google 생태를 큰 덩어리로 나누는 레시피에 가깝습니다. 실무에서 그 다음 단계로 필요한 것이 바로 이 글의 주제입니다. 즉, “Gemini 쪽으로 보냈다”고 해결되지 않는 이유는 Gemini 내부에서도 호스트가 갈리기 때문입니다.

따라서 여기서는 DOMAIN-SUFFIX,aistudio.google.com 한 줄에 기대기보다 개발자 진입(ai.google.dev 등)·콘솔·API·공통 인증이 실패 로그에 같이 찍히는지 먼저 보고, 그 묶음을 PROXY_GEMINI_DEV 같은 의미 있는 정책 그룹 이름으로 고정하는 방식을 권합니다. 이름은 구독 안에서 유일하게만 유지하면 됩니다.

호스트 묶음: 콘솔·API·개발자 문서

아래는 교육용 예시입니다. 실제 사용 중인 클라이언트 버전·리전·엔드포인트에 따라 호스트가 달라지므로, 반드시 코어 로그나 브라우저 개발자 도구의 네트워크 탭에서 실측 호스트를 복사해 목록을 다듬어야 합니다.

역할	흔한 후보(예시)	메모
웹 콘솔	aistudio.google.com	UI·실험 플로우의 첫 화면
Generative Language API	generativelanguage.googleapis.com 등	CLI·SDK가 붙는 REST/gRPC 축
개발자 진입·문서	ai.google.dev, developers.google.com	설치 안내·샘플·리다이렉트
공통 Google 인프라	*.google.com, OAuth 콜백 경로	과도한 넓은 규칙은 신중히—다른 서비스까지 태울 수 있음

Vertex AI나 조직 정책으로 *.googleapis.com 안의 다른 호스트까지 쓰는 경우가 있으면, 그 행은 이번 목적 범위를 넘어서므로 로그로 별도 항목을 추가하는 편이 안전합니다. “Google 전체를 프록시”로 끝내면 예상 밖의 트래픽까지 한 노드에 몰립니다.

Clash 분류 규칙 순서

Rule 모드에서 이 묶음이 GEOIP나 느슨한 MATCH에 먼저 잡히지 않도록, 확인된 개발자 스택 호스트를 위쪽에 둡니다. 원격 규칙 제공자(remote rule-provider)를 여러 겹 쓰는 구독에서는 mixin·병합 순서 실수로 로컬 행이 아래로 밀리는 일이 흔합니다—GUI 미리보기나 로그의 “matched rule” 한 줄을 신뢰하세요.

# Illustrative rules — rename PROXY_GEMINI_DEV; extend from your logs
rules:
  - DOMAIN-SUFFIX,aistudio.google.com,PROXY_GEMINI_DEV
  - DOMAIN-SUFFIX,generativelanguage.googleapis.com,PROXY_GEMINI_DEV
  - DOMAIN-SUFFIX,ai.google.dev,PROXY_GEMINI_DEV
  - DOMAIN-SUFFIX,developers.google.com,PROXY_GEMINI_DEV
  - GEOIP,cn,DIRECT
  - MATCH,PROXY

DOMAIN-KEYWORD,google처럼 지나치게 넓은 키워드는 다른 합법 서비스까지 삼킬 수 있으므로 피하고, 실패한 호스트가 로그에 찍히면 DOMAIN-SUFFIX로 좁히는 습관이 장기적으로 덜 깨집니다.

DNS·fake-ip 정렬

브라우저가 DoH로만 해석하고 OS는 다른 리졸버를 쓰면, 같은 호스트라도 앱마다 서로 다른 IP로 보이는 일이 생깁니다. Clash가 fake-ip를 쓰는 프로파일이라면 《DNS·fake-ip 점검》 순서로 경로를 단일화한 뒤 Gemini 스택을 재현하세요.

CLI가 “이미 IP로 붙는” 경로가 섞이면 규칙 엔진이 기대한 대로 매칭하지 않을 수 있습니다. 디버깅 때는 한 번에 변수 하나만 바꾸는 것이 중요합니다—노드 교체와 DNS 변경을 동시에 하면 원인 추적이 어렵습니다.

터미널과 브라우저 출구 맞추기

Gemini CLI는 종종 터미널 세션의 HTTP(S)_PROXY를 따르지 않거나, 반대로 시스템 프록시만 따릅니다. 절차는 《터미널·Git·환경변수 프록시》와 맞춰 보고, 필요하면 TUN 모드로 캡처 지점을 올립니다. 다른 AI CLI 패턴은 Claude Code·MCP 글과 교차해 “IDE/에이전트가 어떤 스택을 무시하는지”를 비교하면 빠릅니다.

브라우저에서 AI Studio만 문제라면 확장 프로그램 차단·쿠키·서드파티 쿠키 설정까지 잠시 끄고 동일 호스트를 curl로 재현해 보세요. CLI와 동일 호스트에서 한쪽만 실패하면 출구·인증서·SNI 쪽, 둘 다 실패하면 상위 규칙·DNS 쪽 가능성이 큽니다.

노드 선택과 장기 연결

Gemini API 호출은 짧은 명령이 아니라 긴 응답 스트림으로 이어질 수 있어, url-test 우승 노드가 항상 최선은 아닙니다. fallback·tolerance 설정이 장기 세션과 충돌하지 않는지, idle 타임아웃이 짧은 상용 노드가 섞이지 않았는지 확인하세요.

동일 스크립트가 “짧은 프롬프트만 성공하고 긴 출력만 실패”하면 노드 한도·중간 장비 TTL·무선 환경의 재연결을 함께 의심합니다. 정책 그룹 안에서 지터가 적은 소수 출구만 남기고 나머지는 다른 용도로 분리하면 운영이 단순해집니다.

FAQ

aistudio만 열리고 CLI만 실패합니다

CLI의 실제 연결 호스트를 로그에서 복사해 규칙 목록에 없는 SNI가 없는지 확인하세요. 환경 변수 프록시 누락이 가장 흔합니다.

규칙을 올렸는데 증상이 같습니다

해당 요청이 어떤 규칙에 매칭됐는지 코어 로그 한 줄을 캡처하세요. 병합된 원격 규칙이 로컬 행보다 위에 있지 않은지도 봅니다.

스트림이 중간에 끊깁니다

네트워크 타임아웃과 애플리케이션 레벨 스트림 종료를 나누고, 동일 노드·동일 모델로 길이만 바꿔 교차 테스트합니다.

실무 체크리스트

한 축으로 잡고 반복 튜닝 줄이기

2026년 개발자용 Gemini 스택은 CLI와 웹 콘솔이 같이 쓰이면서도 네트워크 면에서는 여전히 여러 호스트·여러 출구 변수를 품습니다. Clash에서 그 축을 명시적으로 묶으면 “도구 전체가 불안정하다”는 체감이 상당 부분 줄어듭니다.

Clash를 무료로 내려받고 분류·로그 검증부터 맞춰 보세요