Gemini·AI Studio 불안정? Clash Google AI 분기(2026)

증상부터 짚기: 웹은 되는데 Gemini만 끊기거나 API만 실패할 때

2026년 현재 Google Gemini와 Google AI Studio(구 MakerSuite 계열 워크플로), 그리고 Generative Language API·클라이언트 SDK는 생성형 AI 도구군에서 동시에 쓰이는 경우가 많습니다. 그런데 프록시를 켠 뒤에도 증상이 이렇게 갈라지는 사례가 반복됩니다. 첫째, 검색·Gmail 등 일반 Google 서비스는 괜찮은데 Gemini 채팅 스트림이 중간에 멈추거나 재시도만 반복된다. 둘째, AI Studio 편집기는 열리는데 미리보기·모델 선택 패널만 로딩에서 멈춘다. 셋째, 브라우저는 되는데 터미널·Python·Node에서 generativelanguage.googleapis.com 등 Google AI API 경로만 간헐 타임아웃한다. 넷째, 로그인·결제·문서 페이지는 되는데 정적 자원·CDN 호스트만 느리거나 연결 패널 규칙 열에 다른 그룹 이름이 찍힌다.

이 패턴은 단순히 「노드가 나쁘다」만으로는 설명되지 않습니다. Google 생성형 스택은 웹 앱, OAuth, API 게이트웨이, 정적 자원, 계측·분석 엔드포인트를 여러 호스트로 나누고, 클라이언트는 짧은 시간에 다수의 TLS 연결을 동시에 엽니다. 그중 일부만 직접 연결(DIRECT)로 새거나, 과도하게 넓은 DOMAIN-KEYWORD 규칙에 걸려 원치 않는 출구로 나가면, 체감상 「가끔만」 실패하는 것처럼 보입니다. 따라서 Clash 분류 규칙으로 Gemini·AI Studio·Generative Language API 관련 호스트를 한 프록시 그룹에 고정하고, DNS·연결 로그로 기대한 노드가 맞는지 확인하는 흐름이 필요합니다.

이미 정리된 ChatGPT·OpenAI API 분기, Claude·Anthropic API 분기, Grok·xAI API 분기와 브랜드는 다르지만 Clash 측에서는 같은 원리입니다. 여기서는 Google 계열 도메인과 Gemini·AI Studio·API 엔드포인트에 초점을 맞춥니다. 호스트 목록은 제품 업데이트로 늘 수 있으니, 아래 예시는 출발점일 뿐이고 본인 클라이언트의 최근 연결 목록을 기준으로 룰셋을 유지보수하세요.

⚠️

준수 안내: 프록시 사용과 Google AI 서비스 이용은 거주 지역 법령과 Google 이용약관·API 정책을 따라야 합니다. 본문은 네트워크 경로와 Clash 설정 기술만 다루며, 규제 회피나 약관 위반을 조장하지 않습니다.

어떤 호스트를 묶어야 하나: Gemini·AI Studio·API

실무에서 자주 등장하는 축은 다음과 같습니다. 소비자·개발자 웹은 gemini.google.com, ai.google.dev, aistudio.google.com 등으로 퍼지고, Generative Language API는 generativelanguage.googleapis.com을 중심으로 SDK·REST 예제가 맞춰집니다. OAuth·계정·결제·일반 Google API와 겹치는 영역은 accounts.google.com, oauth2.googleapis.com, 넓게는 *.googleapis.com까지 이어질 수 있습니다. 즉 「해외 프록시 한 방」만으로는 일부 호스트만 다른 출구로 나가는 상황이 생기기 쉽습니다.

그래서 도메인 접미사를 기준으로 묶는 편이 재현성이 높습니다. DOMAIN-KEYWORD,google처럼 지나치게 넓게 잡으면 검색·YouTube 등 불필요한 트래픽까지 같은 그룹으로 갈 수 있으니, 우선은 DOMAIN-SUFFIX,google.dev, DOMAIN,aistudio.google.com, DOMAIN,generativelanguage.googleapis.com 등 연결 패널에서 반복 확인되는 접미사를 rule-providers YAML로 모아 두고 한 줄씩 추가하는 방식이 안전합니다. 팀 단위로 쓰면 변경 이력을 남기기도 쉽습니다. Google 전역을 한꺼번에 묶어야 한다면 별도의 넓은 룰셋과 충돌하지 않게 우선순위를 설계해야 합니다.

규칙 순서가 핵심: GEOIP·거대 룰셋보다 앞에 둘 것

분류 규칙에서 가장 흔한 실수는 순서입니다. GEOIP,CN,DIRECT나 거대한 RULE-SET이 Google AI 호스트를 먼저 직결이나 다른 그룹으로 보내버리면, 아래에 정교한 규칙을 아무리 추가해도 도달하지 못합니다. 중국 본토 직결과 해외 프록시를 함께 쓰는 패턴은 규칙 분류 실무 글과 함께 읽으면 전체 그림이 잡힙니다. 구독을 막 넣었다면 구독 가져오기에서 노드·그룹 이름이 실제로 로드됐는지도 먼저 확인하세요.

Google AI 전용 그룹 이름(예: AI-GOOGLE)을 규칙에 쓸 때는, YAML 전체에서 오타 없이 동일한 문자열인지 확인합니다. 존재하지 않는 그룹을 가리키면 프로필 자체가 로드되지 않습니다. 또한 MATCH 직전까지 Google AI 규칙이 올라와 있는지 한 번 더 훑는 습관이 안정적 접속에 도움이 됩니다.

전략 그룹: 지연과 세션 끊김 사이에서 고르기

분류 규칙의 끝점은 항상 proxy-groups에 정의된 이름입니다. Gemini·Generative Language API에는 다음이 자주 쓰입니다. (1) select로 지금 쓸 회선을 수동 고정해 재현성을 확보한다. (2) 여러 노드를 두었다면 url-test로 자동 선택하되, 너무 짧은 간격은 세션을 흔들 수 있으니 값은 보수적으로 잡는다. (3) 장애 대비용 fallback을 쓸 때도, 서비스 측 rate limit과 겹치면 오히려 호출이 더 불안정해질 수 있으니 페일오버 조건을 과하게 공격적으로 두지 않는다.

그룹 안에 DIRECT를 남겨 두면 비교 실험에는 유용하지만, 「API만 불안정하다」는 신고만 있고 실제로는 직행이 섞인 경우를 가리기 어렵습니다. 진단 단계에서는 한동안 DIRECT를 빼고 동일 시나리오를 반복해 보는 것도 방법입니다.

프로세스 단위 고정: SDK·CLI가 규칙을 안 탈 때

브라우저는 시스템 프록시를 따르는데, 터미널의 특정 바이너리만 프록시를 타지 않고 나가면 증상이 더 미묘해집니다. Mihomo 계열에서는 PROCESS-NAME 규칙으로 특정 실행 파일 이름을 전용 그룹에 매핑할 수 있습니다. 예를 들어 Python 스크립트만 Google AI 전용 그룹으로 보내고 싶다면, 운영체제에 맞는 프로세스 이름을 연결 로그와 대조해 넣습니다. 다만 프로세스 이름은 빌드·가상환경마다 달라질 수 있으니, 실측 로그를 기준으로 유지보수하는 것이 안전합니다.

앱 전체를 Clash 터널에 넣고 싶다면 TUN 모드로 전체 트래픽을 코어에 넣는 방법도 있습니다. 규칙은 존재하는데 적용이 안 되는 대부분의 사례가 시스템 프록시·TUN·환경 변수 계층에서 갈립니다.

YAML 스케치(이름·접미사는 실측으로 교체)

아래는 구조를 보여 주는 예시입니다. AI-GOOGLE, 멤버 프록시 이름, 접미사는 반드시 본인 프로필과 연결 로그에 맞게 바꿔야 합니다.

# Example only — replace names and suffixes with your profile and logs
proxy-groups:
  - name: AI-GOOGLE
    type: select
    proxies:
      - Proxy
      - AUTO
      - DIRECT

rules:
  - DOMAIN,gemini.google.com,AI-GOOGLE
  - DOMAIN-SUFFIX,google.dev,AI-GOOGLE
  - DOMAIN,aistudio.google.com,AI-GOOGLE
  - DOMAIN,generativelanguage.googleapis.com,AI-GOOGLE
  # Optional: narrow further if logs show additional hosts
  # - DOMAIN-SUFFIX,googleapis.com,AI-GOOGLE
  # Optional: pin a CLI binary when system proxy is ignored
  # - PROCESS-NAME,python3,AI-GOOGLE
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

실제 환경에서는 accounts.google.com 등 인증 흐름이 같은 그룹을 타야 하는지, 아니면 기본 프록시로 두어도 되는지 연결 패널로 확인하세요. 룰셋을 외부에서 가져온다면 rule-providers의 갱신 주기와 우선순위도 함께 점검합니다. googleapis.com 전체를 넓게 잡으면 다른 GCP API와 겹치므로, 가능하면 로그에 찍힌 FQDN부터 좁히는 것이 안전합니다.

DNS·fake-ip: 간헐 실패의 숨은 원인

fake-ip 모드에서는 규칙 매칭은 빠르지만, 특정 호스트에서 해석·캐시가 어긋나면 클라이언트가 보기에도 「가끔만」 실패합니다. Generative Language API는 TLS와 SNI 조합이 민감한 편이라, DNS만 고쳤는데 규칙이 갑자기 맞아떨어지는 사례가 많습니다. 반복되는 호스트는 fake-ip-filter에 넣거나, nameserver와 fallback 체인을 재검토하세요. 자세한 절차는 Fake-IP·DNS 실측 가이드와 함께 보는 것이 좋습니다.

터미널에서 API만 문제일 때는, 앱이 시스템 프록시를 타지 않고 직접 나가는 경우도 있습니다. macOS·Linux에서는 HTTPS_PROXY 등 환경 변수를 맞추는 편이 실무에서 자주 쓰입니다. 흐름 전체는 터미널·Homebrew 프록시 환경 변수 글과 짝을 이루도록 읽을 수 있습니다.

연결·DNS 자가 점검 절차

브라우저에서 Gemini·AI Studio 세션을 끝까지 돌리며 최근 연결에 뜬 호스트를 메모합니다.
동일 시점에 curl 또는 SDK로 짧은 Generative Language API 호출을 한 번 보내, generativelanguage.googleapis.com이 어떤 규칙·그룹으로 잡히는지 비교합니다.
규칙 열에 기대한 그룹 이름(예: AI-GOOGLE)이 찍히는지, 다른 요청과 섞이지 않는지 확인합니다.
지연이 큰 노드로 바꿔 보고 오류 패턴이 따라오는지 봅니다. 변하지 않으면 규칙·DNS 쪽을 우선 의심합니다.
기업 VPN·보안 에이전트와 경로가 겹치지 않는지 확인합니다.

보안·운영 메모

프록시 노드는 트래픽을 중계할 수 있으므로 신뢰할 수 있는 구독을 전제로 합니다. 회사 장비에서는 정책 위반이 될 수 있으니 사내 가이드를 우선합니다. API 키는 클라이언트에 노출되지 않게 관리하고, 팀과 룰셋을 공유할 때는 변경 이력을 남기세요. Google Cloud 콘솔에서 API 사용량·쿼터를 함께 보면 네트워크 문제와 서비스 측 제한을 구분하기 쉽습니다.

체크리스트

Gemini·AI Studio·Generative Language API 관련 DOMAIN-SUFFIX 규칙이 넓은 GEOIP·MATCH보다 앞에 있는가.
generativelanguage.googleapis.com 등 API 호스트가 의도한 그룹으로 매칭되는가.
프록시 그룹 이름이 YAML 전체에서 일관되는가.
DNS 모드·fake-ip-filter가 최근 로그와 모순되지 않는가.
TUN·시스템 프록시·프로세스 규칙·터미널 환경 변수 중 무엇을 쓰는지 일치하는가.

정리

Google Gemini, AI Studio, Generative Language API는 같은 생태계라도 호스트와 프로토콜 패턴이 다릅니다. 도메인 분류로 출구를 고정하고, 필요하면 PROCESS-NAME으로 CLI까지 묶으며, 연결 로그와 DNS로 기대한 경로인지 검증하면, 웹은 되는데 API만 끊기는 식의 간헐 증상을 줄이기 쉽습니다. 목록은 한 번에 완벽할 필요가 없고, 클라이언트가 알려 주는 새 호스트를 주기적으로 룰셋에 반영하는 방식이 장기적으로 가장 덜 깨집니다.

클라이언트를 최신 Mihomo 계열로 맞추는 일도 체감에 영향을 줍니다. 플랫폼별 패키지는 공식 다운로드 페이지에서 고를 수 있습니다. 기본 개념은 문서 섹션과 함께 보시면 설정 속도가 빨라집니다. → Clash를 무료로 내려받아 규칙을 적용한 뒤, 브라우저와 터미널에서 Google AI 호출을 다시 시험해 보세요.