Gemini가 안 열릴 때: Clash로 Google AI 도메인을 분기하고 QUIC·HTTP/3를 끄는 실측 점검 (2026)

1. 왜 Google AI만 유독 「들쭉날쭉」해 보일까

Google 검색·YouTube처럼 이미 익숙한 도메인이라도, Gemini UI와 백엔드는 gemini.google.com, ai.google.dev, generativelanguage.googleapis.com 등으로 나뉘어 요청이 흩어집니다. 일부는 gstatic·googleusercontent 계열 정적 자원을 동시에 당기기도 합니다. 이 상태에서 메인 프록시 그룹이 url-test처럼 자주 바뀌거나, 특정 호스트만 직접 연결로 빠지면 브라우저 입장에서는 「같은 탭인데 어떤 리소스만 실패한다」처럼 보입니다.

또 한 가지는 전송 계층입니다. 최신 Chromium 계열 브라우저는 기본적으로 HTTP/3(QUIC), 즉 UDP 기반 연결을 시도합니다. 프록시 체인이나 방화벽이 UDP 443을 다르게 취급하거나, 노드 쪽에서 QUIC 핸드셰이크만 불안정하면 TCP로는 문제없는데 QUIC만 간헐적으로 실패하는 패턴이 나올 수 있습니다. 그래서 「도메인만 맞게 보냈다」는데도 증상이 남는 경우, QUIC을 잠시 끄고 같은 시나리오를 다시 재현해 보는 것이 비용 대비 효과가 큽니다.

2. OpenAI·Anthropic 글과 겹치지 않게 쓰는 법

이 블로그의 ChatGPT 전용 라우팅 글은 세션 간 IP 드리프트와 OpenAI 측 리스크를 줄이는 데 초점이 있습니다. Claude·Anthropic 글은 지역 메시지와 DNS·fake-ip 조합을 다룹니다. 반면 본문은 Google 도메인 묶음과 QUIC·HTTP/3라는 전송 층 변수를 함께 다루므로, 같은 「AI 코너」라도 문제의 축이 다릅니다. 설정을 옮겨 붙일 때는 호스트 목록과 증상 유형을 섞지 않도록 하는 것이 좋습니다.

3. 규칙에 넣어둘 Google AI 관련 도메인

서비스는 수시로 바뀌므로 아래는 출발점입니다. 개발자 도구 네트워크 탭에서 실패한 요청의 호스트를 확인해 목록을 늘리세요. 웹 UI는 gemini.google.com, 개발자 문서·키 발급은 ai.google.dev, REST·스트리밍 API는 generativelanguage.googleapis.com 등이 자주 등장합니다. Google Cloud 전체를 한 번에 잡는 googleapis.com 접미는 범위가 넓어 다른 API까지 끌고 올 수 있으니, 로그로 오탐을 본 뒤 조정하는 편이 안전합니다.

4. mihomo(Clash Meta) 규칙 스니펫

전용 정책 그룹 이름을 예시로 🔷 Google-AI라고 하면, rules 상단 쪽(넓은 MATCH보다 앞)에 도메인 규칙을 두는 형태가 일반적입니다. 실제 그룹 이름·노드 이름은 구독에 맞게 바꿉니다. 고급 라우팅 가이드에서 규칙 우선순위 개념을 함께 보면 이해가 빨라집니다.

rules:
  # Google AI / Gemini — keep above broad MATCH / GEOIP
  - DOMAIN-SUFFIX,gemini.google.com,🔷 Google-AI
  - DOMAIN-SUFFIX,ai.google.dev,🔷 Google-AI
  - DOMAIN-SUFFIX,generativelanguage.googleapis.com,🔷 Google-AI
  - DOMAIN-SUFFIX,makersuite.google.com,🔷 Google-AI
  # Add DOMAIN-SUFFIX for gstatic / googleusercontent hosts seen in DevTools

  # ... LAN, CN, then MATCH
  - GEOIP,PRIVATE,DIRECT
  - MATCH,🔰 Proxy

DOMAIN-KEYWORD,google처럼 너무 넓은 키워드는 검색·지도 등 전체 트래픽을 끌어올 수 있어 비추천입니다. 대신 로그에 찍힌 호스트를 DOMAIN-SUFFIX로 쪼개 넣는 방식이 안전합니다. 구독 갱신 후 덮어쓰이지 않게 하려면 구독 가져오기 설정과 머지 파일 우선순위를 확인하세요.

5. QUIC·HTTP/3 끄기 (브라우저·클라이언트)

실측에서는 다음 순서가 단순합니다. Chromium 기반(Chrome, Edge, Brave 등)에서 주소창에 chrome://flags(Edge는 edge://flags)를 열고 「Experimental QUIC protocol」 또는 QUIC 관련 항목을 Disabled로 바꾼 뒤 브라우저를 재시작합니다. 그다음 같은 페이지를 새로고침해 Gemini 로딩·스트리밍이 안정되는지 비교합니다. 이 차이가 분명하면 원인 후보에 HTTP/3 경로를 올려 둘 수 있습니다.

앱 내장 웹뷰나 별도 클라이언트를 쓰는 경우에는 해당 앱 설정에 HTTP/3 스위치가 있는지, 또는 시스템 방화벽이 UDP를 다르게 다루는지도 함께 봅니다. 프록시 코어가 TUN 모드일 때와 시스템 프록시만 켰을 때 증상이 달라지는지 비교하면, 문제가 애플리케이션인지 스택·드라이버 쪽인지 나누기 쉽습니다.

6. 실측 점검 순서와 로그 확인

권장 순서는 다음과 같습니다. 먼저 Clash 로그에서 해당 요청이 의도한 규칙 줄에 매칭되었는지 확인합니다. 그다음 Proxies 화면에서 Google-AI 그룹에 묶인 노드의 지역·지연이 기대와 맞는지 봅니다. 세 번째로 브라우저에서 QUIC을 끈 상태와 켠 상태를 번갈아 재현합니다. 네 번째로 DNS가 Clash 밖으로 새지 않는지, VPN·다른 필터와 TUN이 충돌하지 않는지 점검합니다.

7. DNS·fake-ip와 함께 볼 때

Clash Meta(mihomo)에서 fake-ip를 쓰면 규칙 엔진이 도메인 기준으로 트래픽을 나누기 쉬워지지만, 시스템·브라우저 DoH가 강하면 해석 경로가 어긋날 수 있습니다. Google 호스트를 전용 리졸버에 묶고 싶다면 nameserver-policy로 특정 접미만 지정 업스트림에 연결하는 방식도 고려할 수 있습니다. 다만 이 글의 핵심은 DNS 이론보다 실패한 호스트 이름을 로그로 확정하고, 그 이름을 mihomo 규칙에 반영하는 루프입니다.

# Optional — shape only; replace resolvers with yours
dns:
  nameserver-policy:
    "+.googleapis.com":
      - https://dns.google/dns-query
    "+.google.dev":
      - https://dns.google/dns-query

전체 그림은 Clash 개요와 DNS 문서를 함께 보면 정리하기 쉽습니다. 정책·약관·지역 제한은 사용자 환경마다 다르므로, 본문은 네트워크 경로와 전송 계층을 기술적으로 좁히는 데만 초점을 맞추었습니다.