Gemini 2.5 Pro 중국 사용법｜Clash 접속 설정 가이드

중국에서 Gemini 2.5 Pro가 연결되지 않는 이유

Gemini 2.5 Pro를 중국 네트워크에서 사용하려고 할 때 가장 흔한 오해는 “Gemini 도메인 하나만 프록시로 보내면 된다”는 생각입니다. 실제 연결 과정은 단순한 웹 페이지 접속보다 복잡합니다. 브라우저에서 열리는 Google AI 화면, 계정 로그인과 토큰 교환, 모델 목록 조회, 실제 프롬프트 전송, 스트리밍 응답이 서로 다른 호스트와 연결을 사용할 수 있기 때문입니다. 한 단계라도 DIRECT로 빠지거나 DNS 응답이 로컬 네트워크의 제한을 받으면 화면은 열리지만 모델 선택이 비어 있거나, 질문을 보낸 뒤 오래 기다리다가 오류가 발생할 수 있습니다.

특히 Gemini 2.5 Pro는 짧은 검색 요청보다 긴 문서 분석과 코드 생성에 자주 사용됩니다. 따라서 최초 페이지가 열리는지만으로 설정 성공 여부를 판단하면 안 됩니다. 모델 선택 메뉴가 정상적으로 표시되는지, 긴 응답이 중간에 끊기지 않는지, 새로 고침 뒤에도 로그인 세션이 유지되는지를 각각 확인해야 합니다. Clash에서는 이 과정을 연결 로그와 정책 그룹으로 나누어 관찰할 수 있습니다. 문제를 “인터넷이 느리다”로 묶지 말고 로그인, API 요청, 스트리밍 응답이라는 세 구간으로 분리하면 어떤 규칙을 고쳐야 하는지 훨씬 빨리 찾을 수 있습니다.

Clash 클라이언트와 구독 프로필 준비

Windows에서는 Clash Verge Rev나 Mihomo 코어를 사용하는 클라이언트, macOS에서는 Clash Verge 계열이나 다른 Mihomo 기반 앱을 사용할 수 있습니다. Android에서는 시스템 VPN 권한이 필요하고, iOS 환경은 클라이언트마다 프로필과 네트워크 확장 동작이 다르므로 같은 메뉴 이름을 그대로 찾기 어렵습니다. 어떤 앱을 쓰든 핵심은 UI의 명칭이 아니라 활성 프로필, 실행 중인 코어, 프록시 모드 세 가지가 실제로 연결되어 있는지 확인하는 것입니다.

구독 URL을 추가하기 전에 기존 설정을 백업하세요. 구독 업데이트가 전체 YAML을 덮어쓰는 방식이면 직접 추가한 Gemini 규칙이나 정책 그룹이 다음 갱신 때 사라질 수 있습니다. 구독 화면에서 “추가”, “가져오기”, “프로필 업데이트” 중 하나를 선택한 뒤 노드와 정책 그룹이 생성되는지 확인하고, 프로필이 활성화되었는지도 별도로 확인해야 합니다. 목록에 노드가 보인다고 해서 트래픽이 그 노드를 사용하는 것은 아닙니다. 활성 프로필과 현재 선택된 프록시 그룹이 서로 다른 경우가 많습니다.

구독을 추가한 뒤에는 다음 항목을 순서대로 점검하는 것이 좋습니다. 첫째, 코어 상태가 실행 중인지 확인합니다. 둘째, 노드 목록에서 지연 시간이 지나치게 높거나 반복적으로 실패하는 노드를 제외합니다. 셋째, 정책 그룹의 기본 선택이 실제 사용 가능한 노드인지 확인합니다. 넷째, 연결 모드를 처음부터 TUN으로 복잡하게 구성하지 말고 시스템 프록시 또는 혼합 포트 방식으로 기본 접속을 먼저 검증합니다. 이 순서를 지키면 권한 문제와 규칙 문제를 섞어서 조사하는 실수를 줄일 수 있습니다.

시스템 프록시·혼합 포트·TUN 모드 선택

Gemini 웹 화면만 시험할 때는 먼저 시스템 프록시 모드를 사용하는 편이 간단합니다. 브라우저가 운영체제의 HTTP 또는 SOCKS 프록시 설정을 상속받는지 확인하고, Clash 대시보드의 연결 로그에 브라우저 요청이 나타나는지 봅니다. 이 단계에서 페이지가 전혀 열리지 않는다면 Gemini 규칙을 추가하기 전에 포트가 열려 있는지, 선택한 노드가 살아 있는지, 브라우저에 별도의 프록시 확장이 설치되어 있지 않은지를 확인해야 합니다.

혼합 포트는 HTTP와 SOCKS 요청을 하나의 로컬 포트에서 처리할 수 있어 브라우저와 개발 도구를 함께 사용할 때 편리합니다. 다만 브라우저 확장 프로그램에 수동으로 프록시를 입력하면서 동시에 시스템 프록시도 켜면 요청이 두 번 변환되거나 서로 다른 포트로 흘러갈 수 있습니다. 테스트 초기에는 브라우저 확장을 끄고 한 가지 방식만 유지하세요. 로컬 포트 번호는 클라이언트 화면에 표시된 값을 사용하고, 다른 VPN이나 로컬 프록시가 같은 포트를 점유하지 않는지도 살펴봐야 합니다.

브라우저 외의 애플리케이션이나 터미널에서 Gemini 관련 요청을 처리해야 한다면 TUN 모드를 고려할 수 있습니다. TUN은 애플리케이션이 프록시를 지원하지 않아도 가상 네트워크 인터페이스를 통해 트래픽을 Clash로 넘기는 방식입니다. 대신 시스템 확장 권한, 관리자 권한, DNS 처리 방식, 다른 VPN과의 충돌이 함께 발생할 수 있습니다. 웹 브라우저 테스트가 성공한 뒤 TUN을 켜고, TUN 활성화 후에만 문제가 생기는지 비교하세요. 처음부터 TUN과 엄격한 DNS 설정을 동시에 바꾸면 어느 옵션이 원인인지 추적하기 어렵습니다.

1. Clash 코어를 시작하고 구독 프로필을 활성화합니다.
2. 정책 그룹에서 응답이 안정적인 노드를 수동으로 선택합니다.
3. 시스템 프록시 또는 혼합 포트 한 가지를 켭니다.
4. 브라우저를 완전히 다시 시작한 뒤 Gemini 로그인 화면을 엽니다.
5. 기본 접속이 확인된 다음에만 TUN과 세부 규칙을 추가합니다.

Gemini 트래픽을 위한 규칙과 정책 그룹

Gemini용 정책 그룹을 별도로 만들면 전체 인터넷 트래픽을 하나의 노드로 보내지 않고도 AI 요청만 관리할 수 있습니다. 그룹 이름은 GEMINI_AI처럼 알아보기 쉽게 정하고, 처음에는 select 방식으로 특정 노드를 직접 고르는 것이 좋습니다. 자동 선택 그룹은 편리하지만 프로브 대상과 실제 Gemini 경로가 다를 수 있어, 짧은 지연 시간이 곧 긴 스트리밍 응답의 안정성을 의미하지는 않습니다. 기본 연결을 확인한 후에만 url-test나 다른 자동 정책으로 바꾸세요.

규칙은 너무 넓게 잡지 않는 것이 중요합니다. Google 전체 도메인을 하나의 프록시 그룹으로 보내면 검색, 지도, 업무용 서비스까지 예상하지 않은 경로를 사용할 수 있습니다. 반대로 특정 호스트 하나만 등록하면 로그인이나 모델 API가 다른 이름으로 연결될 때 일부 요청이 DIRECT로 빠질 수 있습니다. 가장 안전한 출발점은 연결 로그에서 실제로 확인한 호스트를 기록하고, Gemini 화면·인증·모델 요청에 필요한 범위만 점진적으로 추가하는 방식입니다.

rules:
  - DOMAIN-SUFFIX,google.com,GEMINI_AI
  - DOMAIN-SUFFIX,googleapis.com,GEMINI_AI
  - DOMAIN-SUFFIX,gstatic.com,GEMINI_AI
  - MATCH,DIRECT

위 예시는 복사해서 그대로 확정하는 완성 규칙이 아니라 구조를 이해하기 위한 출발점입니다. google.com 전체를 프록시로 보낼 필요가 없는 환경이라면 실제 로그를 기준으로 더 좁혀야 합니다. 반대로 로그인 리다이렉트나 모델 요청이 다른 Google 계열 호스트를 사용한다면 해당 호스트를 추가해야 합니다. YAML을 수정한 뒤에는 들여쓰기와 그룹 이름을 확인하고, 프로필을 다시 로드한 다음 연결 로그에서 규칙명이 기대한 GEMINI_AI로 표시되는지 확인하세요.

규칙 순서도 반드시 확인해야 합니다. 상단에 더 넓은 DOMAIN-SUFFIX,google.com,DIRECT가 있으면 아래의 Gemini 규칙에 도달하기 전에 요청이 종료됩니다. 지역 규칙이나 광고 차단 규칙이 먼저 적용되는 구성에서도 같은 일이 생길 수 있습니다. 특정 도메인을 추가했는데 효과가 없다면 노드 품질보다 먼저 매칭 순서, 정책 이름 오타, 프로필 재로드 여부를 확인하는 것이 효율적입니다.

노드 선택과 연결 로그로 오류 좁히기

노드는 이름이나 국기보다 실제 세션 안정성으로 평가해야 합니다. Gemini 2.5 Pro는 긴 답변을 생성할 때 연결을 오래 유지하므로, 짧은 지연 시간만 좋은 노드보다 패킷 손실이 적고 스트리밍이 꾸준한 노드가 더 적합할 수 있습니다. 같은 그룹에 여러 노드를 넣고 자동 선택을 켜기 전에, 두세 개 노드를 수동으로 바꾸면서 로그인, 모델 목록 표시, 짧은 질문, 긴 응답을 각각 실행해 보세요. 한 노드에서만 응답 중간에 멈춘다면 규칙보다 해당 출구의 장시간 연결 품질을 의심할 수 있습니다.

Clash의 연결 로그는 오류 메시지보다 많은 정보를 제공합니다. Gemini 화면을 열기 직전 로그를 지우고, 로그인 시점과 프롬프트 전송 시점을 나누어 관찰하세요. 각 줄에서 요청 호스트, 사용된策略 그룹, 연결 상태, 종료 시점을 확인합니다. 로그인은 성공하지만 모델 응답만 멈춘다면 인증 트래픽과 API 또는 스트리밍 트래픽이 서로 다른 정책으로 분리되었을 가능성이 있습니다. 모든 줄이 프록시 그룹을 사용하지만 계속 실패한다면 노드의 TLS 처리, DNS 결과, 장시간 연결 제한을 비교해야 합니다.

DNS는 별도의 변수입니다. 도메인은 열리는데 특정 호스트만 연결되지 않거나, 노드를 바꿔도 같은 IP로만 실패한다면 로컬 DNS 캐시와 Clash의 DNS 모드를 비교하세요. 다만 DNS 설정, TUN, 규칙, 노드를 한 번에 모두 변경하지 마십시오. 먼저 시스템 프록시에서 기본 접속을 확인하고, 다음에 DNS 모드를 바꾸고, 마지막으로 TUN을 테스트하는 식으로 한 번에 하나의 변수만 조정해야 결과를 해석할 수 있습니다. 설정을 바꿀 때마다 시간과 변경 항목을 간단히 기록하면 같은 문제를 반복하지 않게 됩니다.

느린 응답과 로그인 실패를 해결하는 점검 순서

로그인 화면 자체가 열리지 않으면 노드 상태, 시스템 프록시 적용, 브라우저 캐시, 인증 관련 도메인의 규칙을 먼저 확인합니다. 로그인은 되지만 “모델을 불러오는 중”에서 멈추면 모델 목록 요청이 다른 정책으로 빠졌는지 살펴보세요. 질문을 보낸 뒤 즉시 오류가 나면 계정 세션이나 API 요청이 거부된 것일 수 있고, 오래 기다린 뒤 실패하면 노드의 스트리밍 연결과 패킷 손실을 비교하는 편이 맞습니다.

응답 속도가 느릴 때 무조건 가장 가까운 지역 노드를 고르는 것도 정답은 아닙니다. 노드의 초기 연결 시간, TLS 협상, 서버까지의 경로, 장시간 연결 유지 능력이 모두 다르기 때문입니다. 짧은 테스트 요청과 긴 코드 생성 요청을 나누고, 같은 프롬프트를 두 노드에서 비교하세요. 특정 노드만 긴 출력에서 끊기면 해당 노드를 주 그룹에서 제외하고, 자동 테스트 그룹을 사용하더라도 실제 사용량이 많은 시간대에 다시 확인해야 합니다.

• 페이지가 열리지 않음: 시스템 프록시, 로컬 포트, 선택 노드, 브라우저의 별도 프록시를 확인합니다.
• 로그인만 반복됨: 인증 리다이렉트와 쿠키 저장, 관련 호스트의 정책 일관성을 확인합니다.
• 모델 목록이 비어 있음: Google API 계열 요청이 DIRECT로 빠지는지 연결 로그를 확인합니다.
• 응답이 중간에 멈춤: 노드의 스트리밍 안정성, TLS 종료, TUN과 다른 VPN의 충돌을 확인합니다.
• 설정 후 갑자기 원래대로 돌아감: 구독 갱신이 로컬 YAML 변경을 덮어썼는지 확인합니다.

여러 기기에서 같은 구성을 사용한다면 모든 기기에 같은 규칙을 복사하기보다 클라이언트별 차이를 기록하세요. Android는 VPN 권한과 배터리 절전이 영향을 줄 수 있고, Windows는 시스템 프록시와 다른 네트워크 도구의 충돌이 잦으며, macOS는 네트워크 확장 승인 상태가 중요합니다. 동일한 구독이라도 DNS와 TUN 구현이 다르면 결과가 달라질 수 있습니다. 따라서 “한 기기에서 성공했으니 모든 기기도 동일해야 한다”고 판단하지 말고 운영체제별로 기본 접속과 긴 응답을 한 번씩 재검증하는 편이 안전합니다.

일부 브라우저 전용 프록시 확장은 Gemini 페이지는 열어 주지만 백그라운드 요청이나 스트리밍 연결을 완전히 처리하지 못할 수 있습니다. 반대로 오래된 Clash 포크는 최신 Mihomo 규칙이나 DNS 옵션을 일부 무시할 수 있습니다. 이때는 복잡한 설정을 계속 덧붙이기보다 최신 코어가 정상적으로 로드되는지, 프로필 구문 오류가 없는지, 시스템에 남은 다른 VPN이 없는지를 확인하세요. 단순한 시스템 프록시 구성에서 성공한 뒤 필요한 경우에만 고급 기능을 추가하는 방식이 가장 재현성이 높습니다.

브라우저 프록시 확장은 앱마다 설정을 따로 관리해야 하고 스트리밍 요청에서 예외가 생기기 쉬우며, 오래된 Clash 포크는 최신 Mihomo 코어 옵션과 DNS 동작이 맞지 않아 원인을 추적하기 어렵습니다. 반면 Clash V.CORE는 구독 프로필, 정책 그룹, 연결 로그, 시스템 프록시와 TUN 전환을 한 흐름에서 확인할 수 있어 Gemini 2.5 Pro처럼 로그인과 장시간 응답을 함께 점검해야 하는 상황에 더 적합합니다. 노드별 규칙을 직접 비교하고 설정 변경 결과를 기록하고 싶다면, 불필요하게 복잡한 도구를 여러 개 겹치기보다 Clash V.CORE를 내려받아 이 가이드의 순서대로 기본 접속부터 검증해 보세요.