Google Gemini·API 오류? Clash 규칙으로 도메인·노드 고정

1. 어떤 증상부터 네트워크를 의심할까

Google Gemini 웹에서 채팅 입력창이 뜨지 않거나, 응답 스트림이 중간에 끊기면 브라우저 콘솔·네트워크 탭에 실패한 호스트가 남습니다. Google API를 쓰는 스크립트·앱은 generativelanguage.googleapis.com 등에 REST나 스트리밍 요청을 보내는데, 여기서 TLS 핸드셰이크 타임아웃·DNS 조회 지연이 길어지면 애플리케이션은 프록시 이전에 이미 실패합니다. 반대로 “다른 사이트는 빠른데 Gemini만 불안정하다”면 규칙 분류에서 Google 관련 이름이 서로 다른 정책으로 매칭되었을 가능성을 먼저 봅니다.

본문은 계정 정책·결제·지역 제한을 우회하는 방법이 아니라, 사용자가 구성할 수 있는 범위에서 한 세션 안에서 경로를 일관되게 유지하는 데 초점을 둡니다. 클라이언트 UI 차이는 Windows용 클라이언트 비교를, 공통 문법은 설정 가이드와 함께 보시면 설정 흐름이 빨라집니다.

2. Google 트래픽과 OpenAI 트래픽은 도메인이 다르다

저장소 안의 ChatGPT·OpenAI·Clash 글은 openai.com·chatgpt.com·정적 자원 호스트를 예로 듭니다. Google Gemini와 Google API는 대부분 google.com·googleapis.com·gstatic.com·계정·OAuth 관련 호스트로 갈라집니다. 즉 “OpenAI용으로 잘 써 둔 규칙 세트”를 그대로 복사한다고 해서 Gemini 트래픽이 자동으로 같은 그룹에 들어가지 않습니다. 반대로 Google 전체를 한꺼번에 넓은 키워드로 묶으면, 검색·YouTube·드라이브 등 다른 서비스까지 같은 출구로 몰릴 수 있어 비용과 지연을 키울 수 있습니다.

실무에서는 (1) Gemini 웹 UI에 필요한 최소 집합, (2) API 클라이언트가 붙는 호스트, (3) 로그인·토큰 갱신에 쓰이는 accounts.google.com 계열을 구분해 생각하는 편이 낫습니다. 세 갈래가 서로 다른 정책이나 다른 노드로 나가면 브라우저에서는 되는데 API만 실패하는 식의 불일치가 생기기 쉽습니다.

팁: 문제가 날 때마다 실패한 요청의 정확한 호스트 문자열을 메모해 두고 규칙에 반영하면, 서비스가 서브도메인을 추가해도 대응이 빨라집니다. 공개 목록을 그대로 붙여 넣기보다 본인 환경에서 관측한 이름을 우선하세요.

3. Gemini 웹·Google API가 자주 쓰는 호스트(개념)

브라우저에서 gemini.google.com을 열면 HTML·JS·폰트·이미지가 여러 호스트로 흩어질 수 있고, 실시간 응답은 wss 등 스트림 연결을 추가로 씁니다. Generative Language API를 호출하는 코드는 보통 generativelanguage.googleapis.com 같은 Google API 엔드포인트를 박스로 지정합니다. Google Cloud의 다른 제품과 공유되는 *.googleapis.com 패밀리가 함께 등장할 수 있으므로, “API 한 줄만 열면 된다”고 단정하기 어렵습니다.

로그인 세션·동의 화면·토큰 갱신에는 accounts.google.com·oauth2.googleapis.com 등이 등장할 수 있습니다. 이 경로가 DIRECT인데 Gemini 본문만 프록시를 타면 쿠키·리다이렉트 체인이 꼬일 여지가 있어, 규칙 순서와 동일 정책 그룹을 맞추는 것이 중요합니다. 정적 자원용 gstatic.com·폰트 CDN은 지연이 커지면 화면이 반쯤만 그려지는 느낌이 날 수 있어, 웹 UI를 쓸 때는 이들도 같은 터널 정책에 포함하는지 로그로 확인하는 것이 좋습니다.

공식 문서와 실제 트래픽

문서에 적힌 베이스 URL과 브라우저·SDK가 실제로 여는 호스트가 항상 1:1은 아닙니다. 업데이트 후 하위 도메인이 늘어날 수 있으므로, 개발자 도구·앱 로그에 찍힌 이름을 기준으로 규칙을 보강하는 방식이 유지보수에 유리합니다.

4. Clash 규칙 분류로 도메인 묶기

Clash(Mihomo 계열)에서는 RULE 모드에서 위에서 아래로 첫 매칭이 적용됩니다. Google Gemini·Google API 관련 호스트를 한 그룹(예: GOOGLE-AI)으로 보내려면 구체적인 규칙을 위에 두고, 광범한 규칙은 아래에 두는 순서가 안전합니다. 아래는 이해를 돕기 위한 예시 스켈레톤이며, 실제 서비스명·하위 도메인은 시점마다 달라질 수 있으니 반드시 본인이 관측한 이름으로 바꾸세요.

rules:
  - DOMAIN-SUFFIX,gemini.google.com,GOOGLE-AI
  - DOMAIN-SUFFIX,generativelanguage.googleapis.com,GOOGLE-AI
  - DOMAIN-SUFFIX,googleapis.com,GOOGLE-AI
  - DOMAIN-SUFFIX,accounts.google.com,GOOGLE-AI
  - DOMAIN-SUFFIX,gstatic.com,GOOGLE-AI
  - DOMAIN-KEYWORD,google,GOOGLE-AI
  - MATCH,Others

DOMAIN-KEYWORD,google는 편하지만 오탐 범위가 넓어질 수 있습니다. 검색만 직접 연결하고 AI만 터널에 태우고 싶다면 키워드 대신 DOMAIN-SUFFIX를 쪼개 넣는 편이 낫습니다. 구독으로 받은 대형 규칙 분류 세트를 쓰는 경우에도 “공통 규칙”과 “개인이 덧붙인 Gemini 전용 줄”의 순서를 한 번은 직접 확인하세요. 상위에서 이미 DIRECT나 다른 그룹으로 빠져 버리면 아래 줄은 실행되지 않습니다.

5. 노드 선택과 정책 그룹

노드 선택은 “가장 낮은 ping”만이 정답이 아닙니다. Google API는 엣지·쿼터·지역 정책과 맞물려 동일 구독 안에서도 서버마다 체감이 다를 수 있습니다. url-test처럼 지연에 따라 출구가 자주 바뀌는 그룹을 쓰면 짧은 시간 안에 관측 IP가 바뀌는 일이 생겨, 스트리밍 응답이나 장시간 호출에서 불안정해 보일 수 있습니다. 그럴 때는 fallback이나 수동 select로 바꿔 실험해 보세요.

브라우저만 시스템 프록시를 쓰는 구성과, TUN으로 전체를 덮는 구성은 실패 양상이 다릅니다. TUN 사용 시 로컬 망 예외·시스템 DNS·다른 VPN과의 충돌을 함께 봐야 하므로 TUN 관련 문서의 예외 목록과 겹치지 않는지 확인하세요. Windows에서 TUN 후 단절을 다룬 글도 증상 구분에 도움이 됩니다.

주의: 신뢰할 수 없는 무료 노드는 트래픽이 노출될 수 있습니다. API 키·로그인 세션이 오가는 연결에는 검증된 출구와 최신 클라이언트를 쓰는 것이 안전합니다. 본문은 어떤 서비스의 보안 조치를 무력화하는 방법을 다루지 않습니다.

6. DNS·fake-ip

규칙이 정확해도 DNS가 먼저 틀어지면 “프록시를 탔는데도 이상하다”는 상태가 됩니다. fake-ip를 쓰는 구성에서는 도메인별 매핑 타이밍이 민감하고, 의도와 다른 리졸버만 쓰면 엣지 IP가 달라져 지연이 커질 수 있습니다. 타임아웃이 DNS 조회 단계에서 길어지면 애플리케이션은 프록시 이전에 이미 실패합니다.

점검할 때는 (1) Clash 클라이언트의 DNS 설정, (2) 운영체제 DNS 캐시, (3) 브라우저의 DNS over HTTPS 설정이 서로 충돌하지 않는지 순서대로 봅니다. 직접 연결(DIRECT)로 빠져야 할 호스트가 규칙 오탐으로 프록시에 탔을 때도 이상 증상이 나므로, 연결 로그에서 실제 매칭 결과를 확인하는 습관이 중요합니다.

7. 브라우저·OAuth 측면(합법적 범위)

동일 브라우저 프로필에서 Gemini를 쓸 때, 다른 확장 프로그램·광고 차단·엄격한 추적 방지 설정이 쿠키·스토리지·리다이렉트와 충돌하면 로그인 흐름이 꼬일 수 있습니다. 시크릿 창과 일반 창을 섞어 쓰거나, 여러 VPN·프록시 앱을 동시에 켜 두면 경로가 겹치는 경우도 있습니다. 가능하면 한 번에 하나의 터널 경로만 쓰고, 불필요한 레이어를 줄이는 것이 디버깅에 유리합니다.

서비스 이용약관과 보안 정책을 준수하는 범위에서, “같은 세션 동안 출구와 DNS가 일관되는가”를 확인하는 것은 합리적인 자가 점검입니다. 계정 제한·결제·지역 정책은 네트워크 설정만으로 해결되지 않는 경우가 많으므로, 증상을 네트워크 레이어와 계정·제품 정책 레이어로 나누어 생각하는 것이 좋습니다. 입문 흐름은 튜토리얼과 함께 보면 모드 전환 실험이 수월합니다.

8. 증상별 자가 점검

아래 표는 Clash를 쓰는 환경에서 무엇을 먼저 볼지 정리한 것입니다.

증상	의심 지점	조치
웹 UI만 비고 콘솔에 호스트 오류	정적 자원·스트림 호스트 규칙 누락	네트워크 탭에서 실패 호스트 확인 후 규칙 추가
브라우저는 되는데 API·SDK만 실패	`googleapis.com` 계열이 다른 정책으로 매칭	앱 로그의 호스트명을 규칙에 반영
간헐적 타임아웃·끊김	혼잡한 출구, DNS 흔들림, url-test 전환	`fallback`·수동 선택, DNS 고정
로그인만 반복·세션 풀림	accounts 경로와 본문이 다른 노드	계정·Gemini 트래픽을 같은 그룹으로 정렬

LAN에서 Mixed Port를 열어 둔 경우 방화벽·포트 설정과 충돌하지 않는지도 함께 확인하세요.

9. 요약

Google Gemini와 Google API는 gemini.google.com·googleapis.com·계정·정적 자원 호스트가 한꺼번에 얽혀 있어, 한 줄짜리 프록시 설정보다 도메인 기준 규칙 분류와 노드 그룹 실험이 체감 안정성을 좌우합니다. 웹이 안 열리거나 API가 오류를 낼 때도 네트워크 측에서는 경로 일관성·DNS·출구 전환을 먼저 의심해 볼 수 있습니다. Grok·xAI 글은 또 다른 AI 제공자 도메인을 다루므로, 여러 서비스를 같이 쓰면 서비스별로 proxy-groups를 나누고 규칙 순서를 정리하는 편이 장기적으로 안정적입니다.

규칙 세트를 공유받았더라도 본인 환경의 매칭 순서는 직접 확인하는 것이 안전합니다. 규칙 테스트와 연결 기록이 읽기 쉬운 최신 Mihomo 계열 클라이언트를 쓰면, 호스트가 늘어나는 서비스에 맞춰 프로필을 자주 고치기에도 유리합니다.

설치 패키지는 공식 다운로드 페이지에서 받는 것이 혼선이 적고, 오픈 소스 저장소는 빌드·이슈 확인용으로 참고하면 됩니다.

→ Clash를 무료로 내려받아 Google Gemini·Google API용 규칙 분류와 노드 정책을 직접 맞춰 보세요