왜 Gemini는 “한 서비스처럼 보이는데” 경로가 갈라질까?

Gemini와 Google AI Studio(및 관련 콘솔·API)는 사용자 입장에서는 하나의 제품군처럼 느껴지지만, 실제 HTTPS 트래픽은 웹 UI, OAuth·계정, 정적 자산 CDN, *.googleapis.com API, 개발자 문서·샘플 호스트로 쪼개집니다. 그중 일부만 프록시를 타고 나머지는 직회선(DIRECT)으로 가면, 로그인은 되는데 API 키 발급만 실패하거나, 스트리밍 응답이 중간에 끊기는 식의 “절반만 되는” 증상이 2026년에도 자주 제보됩니다. 이는 노드 품질만의 문제가 아니라, 분류 규칙이 특정 하위 도메인을 놓치거나, DNS가 애플리케이션마다 다른 해석 경로를 타기 때문인 경우가 많습니다.

본문은 OpenAI·Anthropic 중심으로 정리한 ChatGPT·Claude 라우팅 글과 제조사 스택이 다른 보완 관계입니다. 구독 갱신·TUN 개념 전체는 구독 관리·TUN 가이드에 맡기고, 여기서는 Google 계열 호스트·전략 그룹·DNS에만 집중합니다.

대표 도메인 묶음: 계정·콘솔·API를 한 번에 잡기

실무에서는 아래와 같은 상위 접미사를 우선 묶는 패턴이 많습니다. 서비스 정책과 엣지 구성은 시기별로 바뀔 수 있으므로, 목록은 “출발점”으로 두고 본인 환경에서 실제 SNI·호스트를 로그로 한 번 확인해 보강하는 것이 안전합니다.

  • 계정·로그인·동의 화면: accounts.google.com, oauth2.googleapis.com, ssl.gstatic.com 등
  • 웹 UI·문서·개발자 포털: google.com, ai.google.dev, developers.google.com, gstatic.com, googleusercontent.com
  • Gemini·Generative Language API: generativelanguage.googleapis.com, 넓게는 googleapis.com 묶음
  • AI Studio·관련 콘솔: aistudio.google.com, makersuite.google.com(레거시 호스트가 남아 있는 환경), 기타 콘솔 하위 도메인

googleapis.com을 한꺼번에 프록시에 태우면 다른 Google API까지 같이 움직이므로, 회사 정책·비용·감사 관점에서 부담이 될 수 있습니다. 반대로 너무 쪼개면 규칙이 길어지고 누락이 늘어납니다. 우선 Generative·AI Studio에 필요한 최소 묶음을 잡고, 로그에서 빠진 호스트만 덧붙이는 방식이 관리에 유리합니다.

분류 규칙 순서: 좁은 조건을 위, MATCH는 아래

분류 규칙의 기본은 단순합니다. Gemini·AI Studio 전용으로 쓸 DOMAIN·DOMAIN-SUFFIX 줄은 목록 상단에 두고, 지역·지름급 GEOIP나 맨 아래 MATCH는 그 다음입니다. 넓은 규칙이 먼저 매칭되면, 아래에 아무리 정교한 AI 전용 줄을 넣어도 도달하지 않습니다.

규칙에 적힌 이름과 실제 전략 그룹 이름이 한 글자라도 다르면 프로필이 로드되지 않거나 의도치 않은 그룹으로 떨어집니다. AI 트래픽만 모을 PROXY-GEMINI(이름은 예시)를 만들고, 그 위에 Google 관련 DOMAIN-SUFFIX를 연결하면 “일반 웹”과 역할이 겹치지 않게 나눌 수 있습니다. 문법·우선순위에 대한 전체 설명은 규칙 심화 가이드와 함께 읽으면 구조가 더 선명해집니다. 

# Conceptual fragment — names and order must match your profile
proxy-groups:
  - name: PROXY-GEMINI
    type: select
    proxies:
      - NODE-A
      - NODE-B
      - DIRECT

rules:
  - DOMAIN-SUFFIX,googleapis.com,PROXY-GEMINI
  - DOMAIN-SUFFIX,google.com,PROXY-GEMINI
  - DOMAIN-SUFFIX,gstatic.com,PROXY-GEMINI
  - DOMAIN-SUFFIX,googleusercontent.com,PROXY-GEMINI
  # ... broader rules below

위 예시는 이해를 돕기 위한 개념용입니다. googleapis.com을 통째로 넣을지, generativelanguage.googleapis.com만 좁힐지는 환경마다 다르며, 좁힐수록 다른 Google 서비스에 미치는 영향은 줄지만 누락 호스트 위험은 커집니다. 본인이 쓰는 클라이언트(SDK, 브라우저, 플러그인)가 어떤 호스트를 여는지 한 번씩 대조하는 것이 좋습니다.

전략 그룹: select 고정과 url-test·fallback의 트레이드오프

긴 스트리밍 응답이나 콘솔의 다단계 요청은 한 노드의 순간 끊김에도 체감이 큽니다. select는 사용자가 지정한 노드를 안정적으로 유지하기 좋고, url-test·fallback은 지연·실패에 따라 후보를 바꿉니다. 다만 측정 URL이 Google AI와 무관한 글로벌 사이트라면, “측정은 빠른데 실제 Gemini 호스트만 막히는” 착시가 생길 수 있으므로, 측정 대상과 실제 사용 경로가 비슷한지 점검하는 것이 좋습니다.

Google AI Studio와 일반 Gemini 웹을 같은 그룹에 둘지 나눌지는 노드 정책과 취향의 문제입니다. 한쪽만 불안정하면 그룹을 분리해 원인을 좁히고, 동일 업스트림이면 하나의 PROXY-GEMINI로 단순화하는 편이 장기 운영에 유리한 경우가 많습니다. 중요한 것은 이름만 전용이고 우선순위상 사실상 DIRECT에 가깝게 동작하지 않게 하는 것입니다.

DNS·fake-ip·redir-host: 해석이 규칙보다 먼저 깨지는 경우

DNS는 규칙 엔진에 앞서 “어디로 붙을지”의 전제를 만듭니다. fake-ip 모드를 쓰면 도메인 질의가 Clash 내부에서 처리되기 쉬워지고, 도메인 기준 분류 규칙과 맞물리기 좋습니다. 반대로 실제 IP가 먼저 로컬 스텁 리졸버·OS 캐시에 고정되면, 일부 연결은 IP 기준 규칙으로만 판단되어 도메인 규칙이 빗나가는 패턴이 나올 수 있습니다. 그래서 AI·Google용 호스트를 fake-ip-filter에 둘지, 특정 API만 redir-host 쪽 동작에 맞출지 등, DNS 모드와 규칙 세트를 한 세트로 설계하는 것이 중요합니다.

redir-host 계열에서는 “실제 IP가 더 일찍 보인다”는 성격이 강해, GEOIP·IP-CIDR와의 상호작용을 더 의식해야 합니다. 한편 fake-ip에서는 필터 목록과 앱의 DNS 우회(자체 DoH 등)가 어긋나면 증상이 갈립니다. 증상이 “앱만 이상하고 브라우저는 정상”일 때는 앱이 시스템 DNS가 아닌 자체 경로를 쓰는지도 함께 의심합니다.

nameserver와 fallback 체인도 살펴보세요. 업스트림 DNS가 지역·네트워크에 따라 다른 응답을 주면, 같은 *.googleapis.com이라도 세션마다 다른 엣지로 붙어 간헐적 403·429·TLS 오류가 번갈아 나올 수 있습니다. “가능한 한 일관된 해석”에 가깝게 가져가되, 프라이버시·회사망 정책 안에서 선택합니다. 기능 개요는 문서 허브와 예시 프로필을 함께 참고하면 좋습니다.

팁: 노드를 바꿔도 즉시 나아지지 않으면 DNS 캐시·기존 TCP·HTTP/2 연결 때문일 수 있습니다. 클라이언트에서 DNS 캐시 초기화 또는 프로필 재적용 후, 브라우저 탭·IDE·CLI를 완전히 종료했다가 다시 열어 비교해 보세요.

분할 관점: Google 전체가 아니라 “필요한 호스트만”

모든 트래픽을 한꺼번에 글로벌 프록시에 태우면 배터리·지연·정책 충돌이 커질 수 있습니다. 분할(split)을 Clash로 구현한다는 것은 곧 규칙으로 “이 도메인만 프록시”를 명시하는 일과 같습니다. Gemini·Google AI Studio·관련 API 호스트만 PROXY-GEMINI로 보내고 나머지는 DIRECT나 국내 전용 그룹에 두면, 불필요한 홉이 줄어 체감 안정성이 좋아지는 경우가 많습니다.

데스크톱 앱이나 SDK가 시스템 프록시를 무시하면, 브라우저만으로는 재현되지 않는 증상이 납니다. 이때는 TUN이 필요한지 여부가 갈리므로, 전체 개념은 TUN 가이드를 참고하되, 우선 “해당 호스트가 분류 규칙에 잡혔는지·DNS가 같은 경로인지”를 확인하는 순서가 효율적입니다.

자가 점검 체크리스트

  • Gemini·AI Studio·API에 해당하는 DOMAIN·DOMAIN-SUFFIX가 MATCH보다 위에 있는가.
  • 전략 그룹 이름이 규칙과 정확히 일치하고, 의도한 노드·백업이 들어 있는가.
  • DNS 모드(fake-ip / redir-host)와 fake-ip-filter가 스트리밍·장시간 연결과 충돌하지 않는가.
  • 브라우저와 달리 실패하는 앱·CLI가 자체 DoH·고정 IP를 쓰지 않는가.
Clash는 로컬 프록시 엔진일 뿐이며, 타인의 서비스 약관·저작권·수출 규정을 우회하도록 안내하지 않습니다. 항상 법령과 계약 관계를 준수하고, 회사·학교 기기에서는 정책을 확인하세요.

정리: 분류 규칙·전략 그룹·DNS를 한 줄기로 맞추기

Clash로 Gemini와 Google AI Studio를 안정적으로 쓰려면, 노드만 바꿔치기하기 전에 Google 계열 호스트 묶음이 규칙에 빠짐없이 덮이는지, 전략 그룹이 실제로 그 경로를 타는지, DNS가 같은 도메인을 일관되게 해석하는지를 세트로 점검하는 것이 효과적입니다. OpenAI·Anthropic 스택과 달리 googleapis.com·계정·CDN이 한꺼번에 얽히는 편이라, “한 번 맞춰 두면 끝”보다 로그로 SNI·호스트를 확인하는 습관이 더 큰 자산입니다. 같은 조건에서도 프로필 편집과 전환이 수월한 클라이언트면 시행착오 시간이 줄어듭니다.

다른 도구들과 비교했을 때 Clash·mihomo 계열은 표현력 있는 분류 규칙과 공개된 설정 예시 덕분에, Google처럼 트래픽이 잘게 쪼개진 스택을 다루기에도 균형이 잘 잡힌 편입니다.

→ Clash 공식 클라이언트 무료 다운로드 — 분류 규칙·DNS·프로필을 한 화면에서 다루며 Gemini 웹과 API·콘솔을 동시에 맞춰 보고 싶다면, 최신 빌드를 받아 직접 구성해 보는 것이 가장 빠릅니다.