Gemini CLI만 시간 초과되는 이유: 브라우저와 터미널의 경로 차이

Gemini 웹 화면은 열리는데 Gemini CLI만 실행되지 않거나, 명령을 입력할 때마다 request timeout이 발생한다면 먼저 계정이나 모델 자체를 의심하기보다 네트워크 경로를 나눠서 봐야 합니다. 브라우저는 운영체제의 시스템 프록시를 자동으로 상속하는 경우가 많지만, 터미널 프로그램은 셸 환경 변수와 애플리케이션 내부의 프록시 설정을 별도로 읽습니다. 따라서 같은 컴퓨터, 같은 Clash 노드라도 브라우저와 CLI가 서로 다른 출구를 사용할 수 있습니다.

Gemini CLI의 한 번의 요청에는 여러 연결이 포함될 수 있습니다. 패키지 설치와 업데이트는 npm 레지스트리 또는 릴리스 서버를 사용하고, 로그인 과정은 Google 계정과 인증 콜백을 거치며, 실제 모델 요청은 Google API 엔드포인트와 장시간 스트리밍 연결을 사용합니다. 이 중 하나만 DIRECT로 빠지거나 DNS가 다른 주소를 돌려주면 화면에는 단순한 “시간 초과”로 표시됩니다. 설치는 완료됐지만 로그인에서 멈추는 경우와, 로그인은 됐지만 모델 응답만 멈추는 경우는 원인이 다를 수 있습니다.

가장 먼저 할 일은 실패 직후 Clash의 연결 로그를 여는 것입니다. 로그 필터에 gemini, google, oauth, npm을 차례로 넣고 요청이 실제로 어떤 호스트에 연결됐는지 확인하세요. 같은 작업에서 프록시 정책과 DIRECT가 섞였다면 노드를 계속 바꾸기보다 규칙과 터미널 프록시 상속부터 정리하는 편이 빠릅니다. 로그를 처음 보는 사용자라면 연결 로그·TLS 시간 초과 점검법을 함께 참고하면 각 단계의 차이를 구분하기 쉽습니다.

ℹ 빠른 진단: 브라우저에서 Gemini가 열리는지만 확인하지 말고, 같은 터미널에서 프록시 환경 변수와 Clash 로그를 동시에 확인하세요. 브라우저 성공은 CLI의 프록시 설정이 정상이라는 증거가 아닙니다.

터미널에서 Clash 프록시를 확인하는 순서

Clash의 mixed-port는 일반적으로 HTTP와 SOCKS5 요청을 모두 받을 수 있지만, 운영체제와 클라이언트에 따라 포트 번호가 다를 수 있습니다. 먼저 Clash 대시보드 또는 설정 파일에서 실제 포트를 확인한 뒤, 터미널 프로세스가 그 주소를 사용하도록 지정해야 합니다. 로컬 포트가 7890이라고 가정하면 셸에서 다음처럼 환경 변수를 설정할 수 있습니다. 

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export ALL_PROXY=socks5://127.0.0.1:7890

위 명령은 현재 터미널 세션에만 적용됩니다. 새 창을 열 때마다 다시 설정해야 한다면 사용하는 셸의 프로필 파일에 넣을 수 있지만, 회사 네트워크나 다른 VPN을 함께 사용하는 컴퓨터에서는 전역 적용이 오히려 문제를 만들 수 있습니다. 우선 일회성으로 설정한 뒤 Gemini CLI가 정상 동작하는지 확인하고, 결과가 좋아졌을 때만 영구 설정을 고려하세요. 이미 HTTP_PROXY와 HTTPS_PROXY가 잡혀 있다면 값이 오래된 포트나 종료된 로컬 프록시를 가리키지 않는지도 확인해야 합니다.

Node 기반 CLI는 환경 변수 외에 npm 설정을 별도로 기억할 수 있습니다. 과거에 다른 프록시를 사용했다면 다음 명령으로 현재 값을 확인합니다. 

npm config get proxy
npm config get https-proxy
env | grep -i proxy

결과에 사용하지 않는 사내 프록시, VPN 주소 또는 예전 Clash 포트가 나오면 먼저 정리하세요. npm 설치는 성공하지만 실행 단계에서만 시간 초과가 난다면 npm 설정만 고치는 것으로는 부족합니다. 반대로 CLI 업데이트나 의존성 다운로드에서만 실패한다면 레지스트리와 CDN이 다른 규칙을 타는지 확인해야 합니다. 터미널과 Docker, IDE 통합 터미널은 환경 변수 상속 방식도 다르므로, 일반 터미널에서 성공한 설정이 VS Code 터미널에 자동으로 전달된다고 가정하지 않는 것이 좋습니다.

Google API 규칙과 DNS를 함께 점검하기

Gemini CLI 트래픽을 한 줄의 키워드로만 처리하면 규칙 누락을 찾기 어렵습니다. 로그인, API 요청, 업데이트, 인증서 확인에 사용되는 호스트가 항상 같은 접미를 가진다는 보장은 없기 때문입니다. 먼저 연결 로그에서 실제 호스트를 기록하고, 그 결과를 기준으로 좁은 범위의 DOMAIN 또는 DOMAIN-SUFFIX 규칙을 추가하세요. 무작정 모든 Google 트래픽을 프록시로 보내면 검색, 업무용 서비스, 내부 계정까지 같은 노드로 몰릴 수 있어 원인 파악이 더 어려워집니다.

DNS 모드도 시간 초과와 자주 연결됩니다. Clash가 도메인을 프록시 서버에서 해석하는지, 로컬 DNS에서 해석하는지에 따라 반환되는 IP와 접속 지역이 달라질 수 있습니다. DNS 설정을 바꿀 때는 여러 항목을 한꺼번에 수정하지 말고, 현재 모드와 가상 IP 사용 여부를 먼저 기록하세요. fake-ip 환경에서 특정 애플리케이션이 가상 주소를 제대로 처리하지 못한다면 해당 도메인만 예외 목록에 넣어 비교할 수 있습니다. 단, 예외를 넓게 추가하면 DNS 누출이나 규칙 불일치가 생길 수 있으므로 테스트가 끝난 뒤 필요한 범위만 남겨야 합니다.

규칙 순서도 중요합니다. 넓은 GEOIP, RULE-SET 또는 일반적인 DOMAIN-SUFFIX,google.com 규칙이 먼저 나오면 뒤에 추가한 Gemini 관련 규칙이 실행되지 않을 수 있습니다. Clash는 위에서 아래로 먼저 일치한 규칙을 적용하므로, 예외와 서비스 전용 규칙을 일반 규칙보다 앞에 배치하세요. 설정을 저장한 뒤에는 반드시 프로필을 다시 로드하고, 이전 연결 로그를 지운 다음 새 요청을 만들어야 변경 사항을 정확히 볼 수 있습니다.

노드 변경, TUN 모드, 스트리밍 연결 테스트

규칙이 올바른데도 응답이 멈춘다면 선택한 노드의 품질을 살펴볼 차례입니다. 단순한 지연 시간 테스트에서 가장 빠른 노드가 Gemini API에 가장 안정적인 것은 아닙니다. 짧은 HTTP 프로브는 통과해도 장시간 HTTPS 스트리밍에서 연결이 끊기거나, 특정 지역의 Google API 엣지와 궁합이 나쁜 노드가 있습니다. 따라서 자동 선택 그룹의 숫자 하나만 보지 말고 실제 Gemini CLI 요청을 짧게 반복하면서 첫 응답 시간, 스트리밍 지속 시간, 재연결 여부를 비교하세요.

노드를 바꿀 때는 세 가지 조건을 고정해야 합니다. 첫째, 같은 규칙과 같은 DNS 설정을 유지합니다. 둘째, 한 번에 한 노드만 바꿉니다. 셋째, 로그인·짧은 질의·긴 응답을 각각 테스트합니다. 모든 값을 동시에 바꾸면 어떤 설정이 문제를 해결했는지 알 수 없습니다. 특정 노드에서만 성공한다면 해당 노드를 임시로 고정하고, 이후 같은 제공자의 다른 노드와 비교해 지역·전송 방식·혼잡 시간대의 영향을 확인하세요.

일반 프록시 모드에서는 터미널 환경 변수만으로 충분할 수 있지만, 애플리케이션이 프록시 변수를 무시하거나 일부 연결을 직접 열면 TUN 모드가 도움이 될 수 있습니다. TUN은 운영체제 수준에서 더 많은 트래픽을 가상 인터페이스로 넘기므로 CLI가 프록시를 인식하지 못하는 상황을 보완할 수 있습니다. 그러나 TUN을 켠다고 모든 문제가 자동으로 해결되는 것은 아닙니다. 시스템 권한, 라우팅 충돌, 다른 VPN의 가상 인터페이스, DNS 가로채기가 함께 작동하기 때문입니다.

  1. Clash를 최신 상태로 실행하고, TUN 권한 또는 시스템 확장이 정상적으로 승인됐는지 확인합니다.
  2. 다른 VPN과 네트워크 필터를 잠시 끄고, 한 개의 터널만 활성화합니다.
  3. TUN을 켠 뒤 시스템 프록시와 환경 변수의 중복 설정을 기록하고, 필요하면 하나씩 비활성화합니다.
  4. Gemini CLI의 로그인, 짧은 요청, 긴 스트리밍 요청을 순서대로 테스트합니다.

TUN에서만 성공한다면 CLI가 환경 변수를 읽지 않았거나 일부 하위 프로세스가 프록시를 상속하지 않았을 가능성이 있습니다. 반대로 TUN에서만 실패하고 일반 모드에서는 성공한다면 가상 인터페이스의 DNS, MTU, 라우팅 우선순위를 의심해야 합니다. 문제를 확인한 뒤에는 “항상 TUN을 켜기”보다 자신이 실제로 필요한 애플리케이션과 도메인만 대상으로 삼는 방식이 유지보수에 유리합니다.

실패 단계별 복구 체크리스트

먼저 오류가 발생하는 위치를 기록하세요. 설치 전부터 명령이 인식되지 않는다면 PATH나 Node 버전 문제일 수 있고, 패키지 다운로드 중 멈춘다면 npm 레지스트리·CDN 연결을 봐야 합니다. 로그인 브라우저는 열리지만 CLI가 완료되지 않는다면 OAuth 리다이렉트와 로컬 콜백을 확인합니다. 인증 완료 후 모델 응답에서만 멈춘다면 Google API 규칙, 노드 품질, 스트리밍 연결 유지 시간을 우선 점검해야 합니다.

캐시와 토큰도 마지막에 정리할 수 있습니다. 설정을 여러 번 바꾼 뒤에는 이전 프로세스가 오래된 환경 변수를 붙잡고 있을 수 있으므로 CLI를 완전히 종료하고 새 터미널에서 재실행하세요. 인증 토큰을 반복해서 삭제하기 전에 먼저 시간대와 시스템 시계가 정확한지 확인하고, 계정 보안 정책상 로그아웃과 재인증이 필요한 경우에는 공식 안내에 따라 진행합니다. API 키나 OAuth 토큰을 연결 로그, 셸 기록, 공개 저장소에 남기지 않는 것도 중요합니다.

자주 묻는 질문

브라우저 Gemini는 되는데 Gemini CLI만 안 되는 이유는 무엇인가요?

브라우저는 시스템 프록시와 인증 세션을 자동으로 사용하지만 CLI는 셸 환경 변수, Node 런타임, 애플리케이션 내부 설정을 따로 사용할 수 있습니다. 따라서 브라우저 성공만으로 CLI 경로가 정상이라고 판단할 수 없습니다. CLI 실행 직후 Clash 로그와 env | grep -i proxy 결과를 비교하면 차이를 빠르게 찾을 수 있습니다.

TUN 모드를 반드시 사용해야 하나요?

반드시 그렇지는 않습니다. CLI가 HTTP_PROXY와 HTTPS_PROXY를 정상적으로 읽고 모든 요청이 Clash 로그에 나타난다면 일반 프록시 모드로 충분할 수 있습니다. 반대로 일부 하위 프로세스가 프록시를 무시하거나 시스템 전체 트래픽을 같은 규칙으로 관리해야 한다면 TUN을 테스트할 가치가 있습니다. TUN을 켠 뒤 문제가 늘어나면 DNS와 다른 VPN의 가상 인터페이스부터 확인하세요.

노드를 바꾸면 잠시 해결되지만 다시 시간 초과됩니다. 어떻게 해야 하나요?

노드 변경으로 잠시 좋아진다면 규칙보다 회선 혼잡, 지역별 API 경로, 장시간 스트리밍 안정성이 원인일 수 있습니다. 자동 지연 수치만 보지 말고 동일한 요청을 여러 노드에서 반복해 첫 응답과 연결 유지 시간을 기록하세요. 특정 노드군에서 공통으로 성공한다면 그 그룹을 별도 정책으로 만들고, 문제가 있는 노드는 자동 선택에서 제외하는 편이 안정적입니다.

다른 프록시 클라이언트는 브라우저용 시스템 설정에 의존하거나 터미널 환경 변수와 TUN 경로가 분리되어 있어 Gemini CLI에서 원인을 찾기 어렵고, 오래된 GUI는 최신 DNS·규칙 동작을 충분히 반영하지 못할 수 있습니다. Clash V.CORE는 연결 로그, 정책 그룹, DNS와 TUN 설정을 한 흐름에서 확인하면서 CLI 트래픽을 단계별로 좁혀 갈 수 있고, 노드 변경과 규칙 검증도 빠르게 반복할 수 있으므로 이 글의 점검 절차를 자주 수행한다면 다운로드 페이지에서 직접 설치해 보는 것이 가장 편한 다음 단계입니다.