구글 Gemini 안 열림: 웹·AI Studio Clash 스플릿

왜 지금 Gemini·AI Studio인가

2026년 현재, 일반 사용자의 검색·글쓰기 보조부터 개발자의 멀티모달 API 실험까지 Google Gemini에 대한 관심은 계속 커지고 있습니다. 웹 브라우저의 대화형 UI와 별도로, Google AI Studio(과거 MakerSuite 계열 워크플로를 흡수한 브라우저 도구)는 키 발급·모델 선택·프롬프트 테스트를 한 화면에서 처리하기 때문에, 국내 회선이나 캠퍼스망에서 간헐적으로 막히거나 로딩이 길어질 때 체감이 큽니다. 이 글은 이미 다룬 ChatGPT·OpenAI API나 Claude·SNI와 역할을 나누고, Google 계열 도메인·API 엔드포인트와 Clash 분류, DoH, SNI를 중심으로 원인을 분리하는 데 초점을 둡니다.

증상을 한 문장으로 줄이면 「DNS만 이상한가, 규칙이 빗나갔는가, 노드 품질인가, TLS가 깨졌는가」를 빠르게 가르는 일입니다. 감으로 노드만 바꾸면 같은 증상이 며칠 뒤에 되돌아오기 쉬우므로, 연결 로그로 규칙 적중·DNS·노드를 분리하는 법과 같은 절차를 전제로 설명합니다.

흔한 증상 패턴

첫째, 주소창의 gemini.google.com은 열리는데, 내부에서 API를 부르는 패널만 스피너에서 벗어나지 않는 경우입니다. 둘째, Google AI Studio의 프로젝트 목록은 보이는데 실행(Run) 단계에서만 타임아웃되는 경우입니다. 셋째, 터미널이나 서버 앱에서 generativelanguage.googleapis.com 등으로 REST·스트리밍 호출할 때만 간헐적으로 실패하는 경우입니다. 넷째, 특정 시간대에만 빈 페이지나 인증 루프가 생기는데, 동일 증상이 모바일 LTE에서는 줄어드는 패턴입니다. 이때 Gemini 접속 문제라고 한 번에 몰아부리기보다, 실패한 요청마다 목적지 호스트와 매칭된 정책 그룹을 로그로 확인하는 편이 안전합니다.

Google 서비스는 정적 자산·OAuth·추론 API·텔레메트리까지 호스트가 잘게 쪼개져 있습니다. 그중 일부만 Clash 분류에서 의도한 프록시 그룹으로 가고 나머지는 DIRECT나 다른 그룹으로 새면, 화면은 반쯤 뜨고 핵심 요청만 실패하는 형태가 됩니다. 반대로 브라우저의 Secure DNS와 Clash의 DNS 설정이 동시에 켜져 있으면, 규칙 엔진이 보는 이름과 실제 소켓이 어긋나 DNS 쪽 증상으로도 나타납니다.

Google 측으로 자주 붙는 호스트 묶음

실제 이름과 경로는 제품 업데이트에 따라 바뀔 수 있으므로 암기보다 로그 수집이 우선입니다. 다만 구성을 설계할 때는 대략 다음 범주를 머릿속에 두면 Clash 분류 YAML을 정리하기 쉽습니다. 사용자가 클릭하는 웹 앱(gemini.google.com 등), 개발자 콘솔 성격의 Google AI Studio 관련 호스트, Generative Language API로 불리는 gRPC·REST 엔드포인트, 그리고 계정·결제·정책 안내를 담는 google.com·gstatic.com·googleapis.com 계열이 동시에 등장한다는 점입니다. 여기서 실수하기 쉬운 것은 「google 전부를 한 그룹」으로 넓게 잡아 국내 서비스까지 느려지게 만드는 것과, 반대로 API 접두사만 좁게 잡아 스튜디오 UI가 쓰는 새 호스트를 놓치는 것입니다.

운영 팁으로는 Rule Provider가 오래되었으면 신규 호스트가 빠질 수 있으므로, 로그에 새로 보이는 이름을 주기적으로 규칙이나 프로바이더에 반영하는 습관이 중요합니다. 스플릿 라우팅의 뼈대는 분류 규칙 최적화 튜토리얼과 같으며, 여기서는 그 위에 「Google 생성형 AI 전용」 정책 그룹을 얹는다고 이해하면 됩니다.

웹 Gemini UI와 Google AI Studio를 스플릿으로 나누는 이유

사용자 입장에서는 둘 다 「구글 AI」로 느껴지지만, 브라우저가 붙는 이름은 성격별로 갈라집니다. 대화형 Gemini 웹은 gemini.google.com을 중심으로 하고, 키 발급·모델 테스트·빌더 UI에 가까운 Google AI Studio는 aistudio.google.com 계열과 그 안에서 불러오는 스크립트·API 호스트가 따로 붙습니다. 한쪽만 끊기면 「Gemini 접속은 되는데 스튜디오만 안 열린다」 혹은 그 반대 패턴이 되므로, Clash 스플릿을 설계할 때는 최소한 「소비자 웹 묶음」과 「개발자 콘솔·실행(Run) 묶음」을 YAML 상에서 구분해 두는 편이 진단이 빨라집니다.

실무에서는 정책 그룹을 둘로 쪼개되 실제 노드는 동일한 안정 출구를 가리키게 두는 방식이 흔합니다. 예를 들어 PROXY_GEMINI_WEB과 PROXY_AI_STUDIO를 만들고 둘 다 같은 YOUR_STABLE_NODE를 선택해 두면, 연결 로그에서 「어느 블록에 매칭됐는지」만으로도 증상을 웹 쪽 이슈인지 스튜디오·API 쪽 이슈인지 나눌 수 있습니다. OAuth·계정은 accounts.google.com 등 공통 호스트를 타므로, 이 레이어를 웹과 스튜디오 중 어느 그룹에 넣을지는 망 정책과 직결됩니다. 공통 호스트를 한쪽에만 묶어 두면 로그인 루프가 생길 수 있어, 로그로 실제 리다이렉트 체인을 한 번씩 확인하는 것이 안전합니다.

규칙 순서에서는 항상 더 구체적인 DOMAIN·DOMAIN-SUFFIX를 넓은 GEOSITE나 GEOIP보다 위에 두세요. googleapis.com처럼 범위가 큰 접미사는 AI뿐 아니라 다른 구글 API까지 실어 나르므로, 장기적으로는 generativelanguage.googleapis.com처럼 로그에서 확인된 이름을 우선 배치하고 나머지는 나중에 보강하는 식이 오탐을 줄입니다. ChatGPT·Claude 글과 마찬가지로 핵심은 「제품마다 다른 호스트 표」를 암기하는 것이 아니라, 재현한 요청마다 목적지를 규칙에 옮겨 적는 반복입니다. 공항 구독을 직접 고치기 어렵다면 Clash Meta 오버라이드로 스플릿 블록만 로컬에 덧붙이는 방법도 함께 쓰면 안전합니다.

Clash 분류와 정책 그룹에서 출구 고정하기

Clash 계열은 위에서 아래로 첫 매칭이 승리합니다. 넓은 GEOIP나 REGION 규칙이 Gemini 관련 도메인보다 위에 있으면, 의도와 다르게 직접 연결이나 다른 대륙 노드로 나갈 수 있습니다. 따라서 실제 로그에서 확인한 이름을 기준으로 블록을 만들고, 자동 전환·부하 분산형 정책 그룹을 쓰는 경우에는 세션 중간에 출구가 바뀌지 않는지까지 봐야 합니다. Clash 분류에서 말하는 고정은 반드시 특정 프로토콜 키워드를 쓰라는 뜻이 아니라, 해당 트래픽을 보내는 정책 그룹 안에서 사용자가 선택한 노드를 유지하는 실무 목표에 가깝습니다.

YAML 예시는 배포판·코어에 따라 키 이름이 조금씩 다르므로 구조 이해용이며, 주석은 영문으로 두었습니다.

# Split web vs studio for clearer rule-hit debugging; both may use the same node.
proxy-groups:
  - name: PROXY_GEMINI_WEB
    type: select
    proxies:
      - YOUR_STABLE_NODE
      - AUTO_FALLBACK
  - name: PROXY_AI_STUDIO
    type: select
    proxies:
      - YOUR_STABLE_NODE
      - AUTO_FALLBACK

rules:
  - DOMAIN-SUFFIX,gemini.google.com,PROXY_GEMINI_WEB
  - DOMAIN-SUFFIX,aistudio.google.com,PROXY_AI_STUDIO
  - DOMAIN-SUFFIX,generativelanguage.googleapis.com,PROXY_AI_STUDIO
  - DOMAIN-SUFFIX,google.dev,PROXY_AI_STUDIO
  # Prefer log-driven DOMAIN lines before broad DOMAIN-SUFFIX,googleapis.com
  # ... then broader rules

DOMAIN-SUFFIX,googleapis.com 한 줄로 끝내기보다, 위처럼 Google AI Studio·Generative Language API에 해당하는 접두사를 먼저 두고 범위를 좁혀 가는 편이 Clash 스플릿 관점에서 덜 위험합니다. 반대로 너무 쪼개만 놓고 한두 호스트를 빠뜨리면 증상이 바로 돌아오므로, 실행(Run) 직전에만 새로 등장하는 이름이 없는지 로그를 다시 한 번 훑으세요. 규칙과 GUI의 정책 그룹 이름이 일치하는지, 오버라이드나 Merge 순서에서 뒤늦게 덮어쓰이지 않는지도 함께 확인합니다.

DNS 오염과 DoH를 같이 보는 이유

프록시가 정상인데도 특정 도메인만 이상한 IP로 풀리면, 출구 문제가 아니라 DNS 오염이나 중간 캐시를 의심합니다. 운영체제가 ISP resolver를 쓰고, 브라우저는 Secure DNS를 켜 두고, Clash는 fake-ip 모드를 쓰는 식으로 경로가 세 갈래면, 같은 질의라도 응답이 달라질 수 있습니다. DoH(DNS over HTTPS)는 질의를 TLS로 감싸 중간에서 조작하기 어렵게 만드는 수단 중 하나이며, Clash Meta 계열에서는 nameserver에 DoH URL을 넣고, 필요하면 fallback과 위생 검사 옵션을 조합합니다.

다만 DoH를 켰다고 모든 증상이 사라지지는 않습니다. 프록시 체인 바깥에서 먼저 잘못된 IP를 받아 캐시해 두었거나, 애플리케이션이 자체 resolver를 쓰는 경우가 있기 때문입니다. 이때는 fake-ip와 redir-host 글에서 설명한 것처럼, DNS 모드·필터·캐시를 한 번에 하나만 바꿔 가며 변수를 분리하는 접근이 안전합니다. 목표는 「Clash가 보는 이름」과 「실제 TLS ClientHello의 SNI」가 같은 출발선에 서게 만드는 것입니다.

실무에서는 (1) 문제가 되는 도메인에 대해 OS와 브라우저의 Secure DNS를 잠시 끄거나 단일화하고, (2) Clash 프로필의 nameserver를 신뢰할 수 있는 DoH로 맞춘 뒤, (3) 동일 시점에 다시 로그를 찍어 비교하는 순서가 재현에 유리합니다. 회사망·학교망에서는 DoH 자체가 정책상 막혀 있을 수 있으니, 그 경우에도 원리는 같고 허용되는 resolver 경로 안에서 최선을 찾게 됩니다.

SNI와 TLS를 로그 관점에서 읽기

HTTPS에서 클라이언트는 ClientHello에 SNI를 실어 보내고, 서버는 이 이름을 기준으로 인증서를 고릅니다. 규칙 엔진이 도메인 규칙에 잘 맞더라도, 중간 장비가 SNI를 바꾸거나 잘못된 인증서를 끼워 넣으면 브라우저 한 종류만 살아 있고 API 클라이언트만 실패하는 차이가 납니다. Gemini 접속 이슈 중 일부는 노드 지연이 아니라 이런 TLS 계층 신호로 설명되는 경우가 있습니다.

확인 순서는 단순합니다. 연결 로그에 TLS 관련 오류 문자열이 있는지 먼저 보고, 없다면 규칙과 출구 전환 문제로 되돌아갑니다. 회사 SSL 가시화·다른 VPN과 동시에 켜 둔 경우에는 Clash 밖에서 이미 세션이 깨질 수 있으므로, 동일 PC에서 한 번에 활성화할 터널은 하나로 줄이는 것이 진단에도 운영에도 유리합니다. Claude 글에서 강조한 SNI 점검 흐름과 겹치지만, Google 쪽은 호스트 수가 더 많아 로그 샘플을 모으는 시간이 조금 더 걸릴 수 있습니다.

연결 로그로 규칙 적중을 검증하는 법

설정을 고치기 전에 반드시 한 번은 로그를 켜 두고 실패를 재현하세요. 성공한 줄보다 실패한 줄에 찍힌 목적지, 매칭된 규칙 이름, 선택된 정책 그룹, 실제 프록시 체인이 중요합니다. 여기서 규칙이 기대한 블록이 아니라면 YAML 순서나 Rule Provider 갱신을 고치고, 규칙은 맞는데 지연이 크면 노드 품질을 의심합니다. 규칙도 노드도 정상인데 DNS 질의만 이상하면 DoH와 fake-ip 설정으로 넘어갑니다.

GUI마다 로그 탭 이름이 다르지만, 필드를 읽는 관점은 동일합니다. 한 번 확인한 패턴을 템플릿으로 저장해 두면, 이후 Google AI Studio나 다른 Google 실험실 제품이 호스트를 추가해도 대응 속도가 빨라집니다. 스크린샷을 남길 때는 토큰이 섞이지 않도록 마스킹하는 습관을 함께 가져가면 좋습니다.

TUN·시스템 프록시와의 정합

브라우저만 시스템 프록시를 따르고, 터미널의 SDK는 환경 변수를 무시하는 경우가 있습니다. 이때 TUN 모드는 IP 레이어에서 트래픽을 Clash로 모아 동일한 Clash 분류를 CLI에도 적용하기 쉽게 합니다. TUN을 당장 쓰기 어렵다면, 해당 셸에서만 HTTPS_PROXY·ALL_PROXY를 로컬 Clash 포트에 맞추는 방법도 있지만, 다른 VPN과 겹치면 오히려 불안정해질 수 있습니다. 한 세션에서는 출구를 하나로 통일하는 편이 Gemini 접속 안정성에도 긍정적입니다.

점검 체크리스트(순서대로)

실패한 요청의 목적지 호스트를 연결 로그에서 확인합니다.
해당 호스트가 의도한 정책 그룹으로 매칭되는지, 넓은 DIRECT·GEOIP 규칙에 먼저 걸리지 않았는지 YAML과 대조합니다.
자동 전환 그룹을 쓰는 경우, 대화·실행 세션 중간에 노드 이름이 바뀌지 않는지 로그로 확인하고 필요하면 수동 고정을 검토합니다.
동일 도메인에 대해 OS·브라우저·Clash의 DNS 경로를 단순화하고, DoH와 fake-ip·redir-host 설정을 점검합니다.
TLS·SNI 관련 오류가 있으면 다른 VPN·SSL 검사와의 충돌을 제거한 뒤 다시 시험합니다.
변경은 한 번에 한 가지씩만 적용해, 다음날 같은 시간대에 증상이 재발하는지 비교합니다.

보안·정책에 대한 짧은 메모

회사 기기·교육망·국가별 규정 환경에서는 클라이언트 설치·TUN·프록시·DoH 자체가 정책 위반이 될 수 있습니다. 본문은 기술적 연결 안정성을 설명하기 위한 것이며, 특정 서비스 이용을 조장하거나 계약·법률 검토를 대신하지 않습니다. 각 서비스 약관과 로컬 법규를 우선하세요.

정리

Gemini 접속과 Google AI Studio 불안은 한 줄짜리 설정으로 끝나는 경우가 드뭅니다. 웹 UI와 스튜디오·API를 Clash 스플릿으로 나눈 뒤 정책 그룹에서 출구를 고정하고, DNS 오염 가능성을 DoH와 resolver 단일화로 줄인 다음, 연결 로그로 규칙 적중과 SNI·TLS 신호를 검증하는 순서를 밟으면 시행착오를 크게 줄일 수 있습니다. OpenAI·Anthropic 글과 역할을 나눈 이유도 호스트 표와 세션 특성이 다르기 때문입니다.

클라이언트 설치 파일이 여러 채널로 흩어져 있어 혼동하기 쉬운데, ClashFast 다운로드 페이지에서 플랫폼별 빌드를 모아 두었습니다. 환경을 맞춘 뒤에는 → Clash를 무료로 내려받아 분류 규칙과 DoH를 직접 조합해 보세요.