1 왜 Google·Gemini 전용 규칙을 두는가
«프록시만 켜면 되지 않나?»라고 생각하기 쉽지만, 실제로는 특정 SaaS만 간헐적으로 끊기는 패턴이 자주 나옵니다. Google 계열은 로그인·쿠키·OAuth·API 키가 여러 하위 도메인으로 흩어져 있고, 일부 경로는 직접 연결로 새었다가 TLS가 실패하거나, 반대로 불필요하게 글로벌 프록시만 타다 지연이 커지기도 합니다. Clash·Mihomo 계열은 규칙 분할로 호스트 단위 정책을 유지할 수 있어, «Google 관련은 이 프록시 그룹»처럼 묶어 두면 재현과 트러블슈팅이 쉬워집니다.
Gemini 2.5는 모델 세대 이름으로, 제품 UI나 문서에서는 Flash·Pro 등 상품명이 함께 붙습니다. Google AI Studio는 키 발급·프롬프트 실험·일부 관리 화면을 브라우저에서 다루고, 앱·스크립트에서는 API 프록시 경로로 같은 계정 정책을 공유합니다. 네트워크만 보면 둘 다 결국 Google 서비스 호스트군 위에서 돌아가므로, 규칙은 “모델 이름”보다 도메인·SNI 기준으로 잡는 편이 안전합니다.
목표는 속도 자랑이 아니라 세션 끊김·401·지역 정책 메시지를 줄이면서, 개발·실험 루프를 안정화하는 것입니다.
2 어떤 호스트가 동시에 도는가
실무에서 자주 겹치는 축은 다음과 비슷합니다. 첫째, 로그인·동의 화면·문서를 위한 google.com·gstatic.com·googleusercontent.com 계열. 둘째, API와 클라이언트 라이브러리가 붙는 googleapis.com·지역별 엔드포인트. 셋째, 개발자 문서·콘솔 안내에 쓰이는 google.dev·ai.google.dev·makersuite.google.com 등 과거·현재 명칭이 공존하는 호스트. 넷째, Colab·BigQuery·Cloud 콘솔을 열면 추가로 *.google.com 아래 경로와 cloud.google.com류가 겹칩니다.
Gemini API를 REST로 호출할 때는 보통 generativelanguage.googleapis.com 같은 호스트가 로그에 남습니다. gRPC를 쓰는 경우에도 근본적으로는 같은 Google API 인프라입니다. 따라서 규칙을 너무 좁게 «모델 이름 한 줄»만 넣으면 다음 주 업데이트에서 깨지기 쉽고, 반대로 MATCH 전체를 글로벌 프록시에만 보내면 국내 지연만 커질 수 있습니다. 중간 지점으로 Google 묶음 DOMAIN-SUFFIX·DOMAIN-KEYWORD를 쓰는 방식이 무난합니다.
3 프록시 그룹과 Rule 모드
GUI 클라이언트에서는 보통 Rule 모드를 기본으로 두고, proxy-groups에 선택형(예: select) 그룹을 하나 만든 뒤 그 이름을 규칙에서 참조합니다. 여기서 이름은 본인 프로파일에 맞게 바꿉니다. Google 전용으로 PROXY-GOOGLE 같은 그룹을 두면, 지연·안정성에 따라 노드를 바꿀 때 Gemini·Gmail·Drive가 함께 따라옵니다.
시스템 프록시만 켠 상태에서 브라우저는 잘 되는데 Python·curl만 실패한다면, 터미널이 프록시를 보지 않는 경우가 많습니다. 이때는 환경 변수나 TUN 모드로 하위 트래픽을 한 정책으로 묶는 편이 낫습니다. IDE에서 AI 확장을 쓰는 흐름은 Cursor·Clash 가이드와 겹치므로, 본 글은 Google 호스트 규칙에 초점을 맞춥니다.
구독이 Clash 호환 YAML이 아니면 먼저 구독 변환 튜토리얼로 형식을 맞춘 뒤 가져오기에 넣는 것이 좋습니다. 그렇지 않으면 규칙을 아무리 적어도 노드 풀이 비어 있거나 오래된 상태로 남습니다.
4 규칙 YAML 예시
아래는 개념 예시입니다. PROXY-GOOGLE·DIRECT 등 이름은 본인 proxy-groups 정의와 반드시 일치시켜야 하며, 상위 규칙 세트와 충돌하지 않게 순서를 조정하세요. 커뮤니티 Rule Provider에 Google 목록이 이미 있다면 중복·충돌을 피하기 위해 한쪽으로 통일하는 편이 낫습니다.
# Google bundle → dedicated proxy group (example)
- DOMAIN-SUFFIX,google.com,PROXY-GOOGLE
- DOMAIN-SUFFIX,googleapis.com,PROXY-GOOGLE
- DOMAIN-SUFFIX,gstatic.com,PROXY-GOOGLE
- DOMAIN-SUFFIX,googleusercontent.com,PROXY-GOOGLE
- DOMAIN-SUFFIX,google.dev,PROXY-GOOGLE
- DOMAIN-KEYWORD,generativelanguage,PROXY-GOOGLE
- DOMAIN-SUFFIX,makersuite.google.com,PROXY-GOOGLE
# Optional: send AI Studio doc host explicitly if logs show it
# - DOMAIN-SUFFIX,ai.google.dev,PROXY-GOOGLE
DOMAIN-KEYWORD는 오탐이 생기기 쉬우므로 로그로 필요성을 확인한 뒤 최소한만 쓰세요. GEOIP나 국내 대역 DIRECT 규칙이 앞에 있으면, 의도와 다르게 Google만 예외로 빠져나갈 수 있으니 전체 규칙 스택을 한 번 스크롤하며 검토하는 것이 좋습니다.
5 Google AI Studio·REST·SDK
Google AI Studio에서 키를 만들고 브라우저에서 프롬프트를 돌려 보는 시나리오는, 로그인 쿠키와 API 키가 섞이지 않도록 계정·프로젝트 경계를 명확히 하는 것이 중요합니다. 같은 키를 팀 서버에 두었다가 이슈가 나면 쿼터·지역·결제 메시지가 API 응답으로 돌아오는데, 이는 순수 프록시 문제가 아닐 때가 많습니다.
로컬에서 curl이나 공식 SDK로 호출할 때는 터미널이 시스템 프록시를 따르는지 확인하세요. TUN을 쓰면 대부분의 TCP가 같은 규칙을 타기 쉽습니다. 반대로 Docker 컨테이너 안에서만 실패한다면 컨테이너 네트워크·DNS가 호스트와 분리되어 있을 수 있어, 호스트 Clash와 별개로 봐야 합니다.
6 DNS·FakeIP 정렬
프록시는 켜졌는데 특정 호스트만 끊기면 DNS가 ISP로 새거나, FakeIP·DoH 설정이 앱과 어긋난 경우가 많습니다. Meta 커널 환경에서는 DNS 유출 방지 가이드의 원리를 참고해, OS 리졸버·Clash DNS·TUN을 한 줄로 맞추세요. Google 호스트는 지역별로 다른 IP를 돌려줄 수 있어, DNS만 바꿔도 응답 지연이 달라지는 체감이 날 수 있습니다.
브라우저의 «안전하지 않은 연결»류 메시지가 뜬다면 프록시 체인 중간의 인증서 검사·잘못된 스니핑을 의심하고, 가능하면 신뢰할 수 있는 노드와 클라이언트 설정을 유지하세요.
7 Gmail·Drive·Colab까지 같은 묶음으로
본 글의 규칙 묶음은 Gemini뿐 아니라 같은 Google 인프라를 쓰는 Gmail·Google Drive·Colab에도 이점이 있습니다. 다만 대용량 Drive 동기화를 프록시로만 밀면 쿼터·속도 이슈가 생길 수 있어, 업무 정책에 따라 Google 묶음을 둘로 나누거나 시간대별로 노드를 바꾸는 식의 운용도 고려할 수 있습니다. 중요한 것은 «한 번에 전부 글로벌»이 아니라 측정 가능한 그룹으로 나누는 것입니다.
YouTube·Play 스토어 등 미디어 트래픽은 CDN 패턴이 달라, 미디어 전용 Rule Provider를 이미 쓰고 있다면 Google 일반 묶음과 우선순위가 겹치지 않게 정리하세요. 스트리밍용 그룹과 개발용 그룹을 분리하면 디버깅이 쉬워집니다.
8 Cursor 글과의 차이
같은 사이트의 《Clash로 Cursor 안정 접속》은 IDE·확장 마켓·npm·Git 등 개발자 앱 트래픽에 초점을 둡니다. 반면 이 글은 Google 클라우드·AI Studio·Gemini API 호스트를 규칙으로 묶는 네트워크 관점이 중심입니다. 둘은 경쟁이 아니라, Cursor에서 Gemini 연동을 쓰는 경우 IDE 설정 + Google 규칙을 함께 맞추면 세션이 가장 안정적입니다.
9 문제 해결 체크리스트
- 브라우저만 되고 SDK만 실패: 터미널·런타임의 프록시 환경 변수와 TUN 적용 여부를 확인합니다.
- 간헐 403·quota: 노드 지역·Google 계정 정책·결제 상태를 확인합니다. 프록시만으로는 해결되지 않을 수 있습니다.
- 특정 서브도메인만 끊김: Connections 로그의 실제 호스트를 규칙에 추가합니다.
- 느리기만 함: Google 묶음을 더 가까운 노드 그룹으로 옮기거나, 불필요한 이중 홉을 줄입니다.
- IPv6 경로 불일치: IPv6가 직통으로 나가며 v4만 프록시일 때 증상이 납니다. 환경에 맞게 v6 정책을 정리합니다.
10 준수·보안
지역별 법규·서비스 약관·고용 계약을 지키는 것은 사용자 책임입니다. 본문은 가정·개발 환경의 네트워크 구성을 설명할 뿐, 통신사·학교·회사망 정책을 우회하라는 뜻이 아닙니다. 오픈 소스 클라이언트의 소스 코드·이슈 트래커를 보려면 GitHub 등을 참고할 수 있으나, 설치 패키지는 출처를 확인하고 가능하면 사이트 다운로드 페이지를 우선하는 편이 안전합니다.
11 정리
Gemini 2.5와 Google AI Studio를 안정적으로 쓰려면 모델 이름보다 실제 호스트·DNS·출구 노드를 함께 보는 것이 중요합니다. Clash 규칙 분할로 Google 묶음을 전용 프록시 그룹에 두면, 브라우저 실험과 API 프록시 기반 스크립트가 같은 레일을 타기 쉽고, Google 서비스 전반의 재현성도 좋아집니다. 규칙은 로그로 검증하고, DNS는 FakeIP·DoH 가이드와 맞추며, IDE까지 묶을 때는 Cursor 글과 병행하면 틈이 줄어듭니다.
클라이언트 패키지와 최신 릴리스는 Clash 다운로드 페이지에서 확인할 수 있습니다. 여러 후보를 비교해 본인 OS·워크플로에 맞는 것을 고르세요.
