2026 Clash로 Gemini·Google AI Studio 분기: Google 도메인 규칙과 연결 실패 점검

왜 Google AI만 따로 묶어야 하나요?

2026년 현재에도 생성형 AI 도구는 제품마다 인증·결제·지역 정책·API 한도가 다르고, 같은 회사 안에서도 웹 콘솔과 REST·SDK가 다른 인프라를 탑니다. Google 쪽은 accounts.google.com으로 이어지는 OAuth, aistudio.google.com·ai.google.dev 계열의 웹·문서, 그리고 실제 추론 호출이 붙는 generativelanguage.googleapis.com 등 googleapis.com 아래 호스트가 한꺼번에 등장합니다. 전역 프록시에만 의존하면 국내 서비스까지 불필요하게 우회하고, 반대로 국내 직결만 고정하면 UI는 열리는데 API만 끊기는 «반쯤만 되는» 상태가 나옵니다.

Clash에서는 분기 규칙으로 «이 접미사·이 정확한 호스트는 이 정책 그룹»이라고만 맞추면 되므로, Google AI 업무용 트래픽만 안정적인 노드로 보내기에 적합합니다. 핵심은 (1) 로그·개발자 도구에서 실제로 나가는 호스트 이름을 모으는 것, (2) 그 이름이 가리키는 proxy-groups 이름이 프로필 안에 존재하는지 확인하는 것, (3) GEOIP나 MATCH 같은 포괄 규칙보다 위쪽에 Google AI 예외 줄을 두는 것입니다.

이 글의 범위 여기서는 Clash 프로필의 라우팅·정책 그룹에 집중합니다. Google Cloud 콘솔의 API 활성화, 결제 프로필, 할당량, 서비스 약관은 별도 이슈이지만, 노드 지역이 엇나가거나 DNS가 직행을 고수하면 비슷한 타임아웃으로 보이므로 아래 체크리스트와 함께 보시면 됩니다.

Gemini·AI Studio·API에 자주 나오는 Google 도메인

DOMAIN-SUFFIX는 호스트 끝이 일치하면 매칭되고, DOMAIN은 정확한 호스트 한 줄에 쓰기 좋습니다. Google은 서비스 경계가 넓어 DOMAIN-SUFFIX,google.com 한 줄로 전부 덮으면 YouTube·검색까지 같이 프록시될 수 있어, 목적에 맞게 층을 나누는 편이 안전합니다. 아래는 실무에서 자주 보이는 묶음 예시이며, 클라이언트 로그에 찍힌 실제 호스트를 보며 추가·삭제하세요.

aistudio.google.com — Google AI Studio 웹 콘솔·시험용 호출 UI.
ai.google.dev — 개발자 문서·가이드·일부 리소스 로딩.
generativelanguage.googleapis.com — Gemini API의 대표 REST 호스트. SDK·샘플 코드가 이 이름으로 붙는 경우가 많습니다.
googleapis.com — DOMAIN-SUFFIX로 잡으면 Maps·GCP 등 다른 API까지 넓게 포함됩니다. Google AI만 노리면 우선 DOMAIN,generativelanguage.googleapis.com처럼 좁히고, 로그에 다른 *.googleapis.com가 보이면 그때 DOMAIN-SUFFIX나 DOMAIN 줄을 보태는 방식이 유지 보수에 유리합니다.
googleusercontent.com·gstatic.com — 첨부·정적 자원·폰트 등. 웹은 되는데 스크립트만 막히는 패턴에서 로그에 자주 뜹니다.
accounts.google.com·oauth2 관련 호스트 — 로그인·토큰 갱신이 직행·프록시에 갈리면 «한동안 되다가 갑자기 401·리다이렉트 루프»로 이어질 수 있습니다.

DOMAIN-KEYWORD는 Google에서 더욱 신중하게

DOMAIN-KEYWORD,google처럼 짧게 쓰면 편하지만, 의도와 무관한 사이트까지 매칭될 여지가 큽니다. 가능하면 DOMAIN·DOMAIN-SUFFIX로 서비스 경계를 맞추고, 정말 필요할 때만 키워드 규칙을 쓰는 것을 권장합니다.

rules 예시: Google AI 전용 정책 그룹으로 보내기

아래는 개념을 보여 주는 최소 예시입니다. 앞쪽에 LAN·국내 직결 규칙이 있다고 가정하고, Google 생성형 AI 관련 호스트만 GEMINI라는 정책 그룹으로 보냅니다. 프로필마다 그룹 이름·순서는 다르므로 자신의 YAML에 맞춰 통일하면 됩니다.

rules:
  - DOMAIN,generativelanguage.googleapis.com,GEMINI
  - DOMAIN-SUFFIX,aistudio.google.com,GEMINI
  - DOMAIN-SUFFIX,ai.google.dev,GEMINI
  - DOMAIN-SUFFIX,accounts.google.com,GEMINI
  - DOMAIN-SUFFIX,googleusercontent.com,GEMINI
  - DOMAIN-SUFFIX,gstatic.com,GEMINI
  # 필요 시 로그에서 확인한 추가 googleapis 호스트만 DOMAIN으로 한 줄씩
  # ... 기존 GEOIP·MATCH 등

GEMINI는 proxy-groups에 반드시 정의되어 있어야 합니다. type: select로 지역별 노드를 고르게 하거나, url-test로 지연·가용성을 보면서 자동 선택할 수 있습니다. 그룹 유형과 우선순위 개념은 YAML 규칙 분기 가이드의 정책 그룹 절을 참고하세요.

규칙 순서가 바뀌면 왜 API만 깨지나요?

Clash는 같은 요청에 여러 줄이 해당돼도 위에서 아래로 첫 매칭만 적용합니다. 넓은 GEOIP나 최종 MATCH가 Gemini 전용 줄보다 위에 있으면, 브라우저는 우연히 원하는 경로로 가도 터미널의 API 호출만 다른 아웃바운드로 나가 타임아웃처럼 보일 수 있습니다. 스트리밍·메신저·회사 사내망 예외를 쓰는 프로필일수록 서비스별 세부 줄을 포괄 규칙보다 위에 두는 습관이 필요합니다.

정책 그룹으로 «Google AI 전용» 경로 만들기

분기 규칙이 가리키는 것은 결국 어떤 노드 묶음으로 나갈지입니다. 일반 해외 프록시용 select와 별도로 GEMINI 그룹을 두면, 일상 브라우징은 가까운 지역·Gemini·Google AI Studio는 정책상 필요한 지역 노드로 나누기 쉽습니다. 자동 선택을 쓸 때는 테스트 URL이 특정 지역에서만 열리면 오탐이 나므로, 가벼운 공용 HTTP 응답을 쓰는 편이 안전합니다.

proxy-groups:
  - name: "GEMINI"
    type: select
    proxies:
      - "미국-저지연"
      - "백업-고정"
      - "DIRECT"
  - name: "미국-저지연"
    type: url-test
    proxies:
      - # 구독에서 받은 노드 이름들

GUI에서 그룹 이름을 바꿨다면 rules 인자도 동일한 문자열로 맞춰야 합니다. 오타로 코어 기동 실패나 해당 줄 무시가 나올 수 있으니, 편집 후에는 프로필 검증과 로그 확인을 권장합니다.

흔한 증상: 웹은 되는데 API·SDK만 실패·타임아웃

아래는 «프록시가 전부 틀렸다»만이 아니라 DNS·TLS·앱별 프록시·노드 품질이 겹칠 때도 비슷하게 보입니다. 순서대로 좁히면 원인 파악이 빨라집니다.

1) AI Studio 탭은 열리는데 터미널 curl·SDK만 멈춘다

브라우저는 시스템 프록시·확장·TUN을 타고 aistudio.google.com까지 가지만, 터미널은 HTTPS_PROXY 미설정이거나 Docker·CI가 별도 DNS를 쓰는 경우가 많습니다. 실패한 요청의 호스트가 generativelanguage.googleapis.com인지 먼저 확인하고, 해당 줄이 GEMINI 그룹을 가리키는지·그 그룹이 실제로 선택돼 있는지 로그에서 봅니다.

2) 간헐적 타임아웃·긴 응답 시간

생성형 모델 호출은 응답이 길어 타임아웃 한도에 걸리기 쉽습니다. 클라이언트·라이브러리의 read timeout을 늘리는 것과 별개로, 노드 혼잡·UDP/QUIC 정책·MTU 문제로 중간에서 끊기는 경우도 있습니다. 같은 규칙이라도 노드를 바꾸면 정상화되면 아웃바운드 품질 쪽을 의심합니다.

3) TLS·인증서·SNI 관련 메시지

중간 HTTPS 검사 제품과 충돌하거나, 일부 노드에서 SNI 처리가 어긋나면 브라우저와 CLI에서 다른 오류 문자열이 나올 수 있습니다. 회사 보안 스택을 잠시 분리해 테스트하거나, 동일 증상이 특정 노드에서만 나는지 비교해 보세요.

4) 403·«지역에서 사용할 수 없음»류

이는 순수 Clash 라우팅만의 문제가 아니라 Google 계정·결제·정책일 때가 많습니다. 경로를 맞춰도 계정 단에서 막히면 동일하게 보이므로, 공지·콘솔 상태와 함께 확인해야 합니다.

로그를 기준으로 «어느 규칙 줄이 선택됐는지»와 «실제 연결 호스트»를 함께 보면, googleapis.com을 과하게 넓히지 않고도 빈틈을 메울 수 있습니다. API 전용 호스트는 DOMAIN 한 줄로 명시하는 것이 디버깅에 유리합니다.

DNS와 함께 봐야 하는 이유

도메인 기준 규칙은 그 전에 어떤 IP로 해석되느냐에 영향을 받습니다. fake-ip 모드에서는 화면에 보이는 주소와 코어 내부 매칭이 달라 보여 «규칙을 넣었는데 DIRECT로 간다»는 혼란이 생기기도 합니다. enhanced-mode, nameserver 체인, 도메인별 DNS를 rules 변경과 같은 날 점검하는 것이 좋습니다.

문제가 반복되면 (1) 해당 호스트에 어떤 DNS가 쓰였는지, (2) 결과 IP가 IP-CIDR 규칙에 먼저 걸리지 않는지, (3) Rule Provider 캐시가 오래된지 순으로 확인해 보세요. 로컬·사내망 이름이 깨지는 경우는 fake-ip와 redir-host 점검 글이 도움이 됩니다.

다른 생성형 AI 분기 글과의 역할 나누기

본 글은 Gemini·Google AI Studio·generativelanguage.googleapis.com 중심으로 Google 도메인 분기와 정책 그룹을 묶었습니다. OpenAI·Anthropic·xAI 축은 각각 별도 도메인 집합을 쓰므로, 같은 프로필 안에서도 규칙 블록을 나누어 두면 장애 시 원인 구역을 빨리 가릴 수 있습니다. 범용 RULE-SET·Provider 갱신 등은 YAML 규칙 분기 완전 가이드를 기준으로 두고, 그 위에 Google AI 묶음만 얹는 구성이 읽기 쉽습니다.

코어 교체·프로토콜 활성화 절차는 미호모 코어 업그레이드 가이드와 연결해 읽으면 설정 흐름이 자연스럽습니다.

마무리

2026년에도 생성형 AI는 웹 콘솔·REST API·SDK·에이전트 도구가 동시에 돌아갑니다. Clash에서는 분기 규칙으로 Gemini와 Google AI Studio 관련 호스트를 명시적으로 묶고, 정책 그룹으로 그 묶음의 아웃바운드를 고정하면 «브라우저만 되고 API만 타임아웃» 같은 불균형을 줄이기 쉽습니다. 증상이 남으면 규칙만 의심하기보다 DNS·노드·앱별 프록시 설정을 함께 보는 것이 중요합니다.

같은 Clash 계열도 GUI와 프로필 머지 방식은 제품마다 다르지만, 최종적으로 코어가 읽는 YAML 한 장을 기준으로 생각하면 디버깅이 빨라집니다. 반복되는 수동 편집보다 검증된 클라이언트에서 프로필을 한 번 맞춰 두는 편이 장기적으로는 더 편한 경우가 많습니다.

→ Clash 무료 다운로드 — 여러 플랫폼용 클라이언트를 한곳에서 받고, 규칙·구독·코어를 한 화면에서 다루기 쉬운 구성으로 Google AI 분기까지 한 번에 정리해 보세요.

추가 설정이 필요하면 도움말과 기술 칼럼 목록을 참고해 주세요.