Gemini 3를 국내에서 이용할 때는 브라우저 자체의 문제가 아니라 DNS 응답, 프록시 노드의 지역, TLS 연결, Google 계정 인증 흐름이 서로 맞지 않아 접속이 불안정해지는 경우가 많습니다. 특히 Gemini 3 화면은 열리지만 로그인 단계에서 반복적으로 실패하거나, 응답 생성 중 연결이 끊기거나, 특정 노드에서만 “서비스를 사용할 수 없음”과 같은 메시지가 나타날 수 있습니다. 이 글에서는 Clash 또는 Mihomo를 기준으로 구독을 추가하고, Gemini 관련 트래픽만 별도 프록시 그룹으로 보내며, 노드와 DNS를 점검하는 실전 설정 방법을 소개합니다. 서비스 이용 가능 여부는 Google 계정, 공식 지원 지역, 요금제와 정책에 따라 달라질 수 있으므로 설정 전에 해당 서비스의 최신 이용 조건도 확인하세요.

Gemini 3 접속 문제를 먼저 분류하기

Clash 설정을 바꾸기 전에 문제가 어느 단계에서 발생하는지 구분해야 합니다. 단순히 모든 트래픽을 프록시로 보내면 원인은 가려지고, 국내 서비스까지 불필요하게 우회되어 속도와 로그인 안정성이 오히려 낮아질 수 있습니다. 먼저 같은 기기에서 일반 웹사이트가 정상적으로 열리는지 확인하고, 그다음 Gemini 접속 단계별로 증상을 기록하세요.

  • 페이지 자체가 열리지 않음: DNS 해석 실패, 노드 연결 실패, SNI 또는 TLS 오류를 먼저 의심합니다.
  • 페이지는 열리지만 로그인 화면에서 멈춤: Google 인증 도메인이 서로 다른 경로를 사용하거나 쿠키, 리디렉션, 시간 설정에 문제가 있을 수 있습니다.
  • 로그인 후 빈 화면 또는 반복 리디렉션: 브라우저 확장 프로그램, 오래된 쿠키, 계정 보안 확인, 노드의 지역 정보가 영향을 줄 수 있습니다.
  • 응답 생성 중 중단: 노드의 순간적인 패킷 손실, WebSocket 연결 불안정, 과도한 연결 수 또는 프록시 서버의 대역폭 부족이 원인일 수 있습니다.
  • 특정 노드에서만 실패: 해당 노드의 IP 평판이나 Google 측의 자동화·위험 감지 결과가 원인일 가능성이 높습니다.

Clash 대시보드의 Connections 또는 연결 목록에서 실제 목적지 도메인과 매칭된 규칙을 확인하는 것도 중요합니다. Gemini 화면을 열었는데 연결 목록에 예상한 Google 관련 도메인이 하나도 보이지 않는다면 규칙 순서나 DNS 모드가 잘못되었을 수 있습니다. 반대로 모든 Google 트래픽이 프록시로 전송되면 로그인과 일반 검색까지 같은 노드에 묶이므로, 필요한 도메인만 분리하는 편이 진단에 유리합니다.

Clash는 네트워크 경로를 제어하는 도구일 뿐 계정의 서비스 자격이나 공식 지원 지역을 변경하지 않습니다. 계정 정책을 우회하거나 비정상적인 자동화를 시도하지 말고, 로그인 보안 확인이 표시되면 공식 안내에 따라 처리하세요.

구독 추가와 기본 프록시 그룹 구성

Clash Verge Rev, Clash Verge, Mihomo 계열 클라이언트에서는 일반적으로 설정 또는 프로필 화면에서 구독 URL을 추가합니다. 제공받은 구독 주소를 정확히 입력한 뒤 업데이트를 실행하고, 노드 목록이 실제로 생성되었는지 확인하세요. 구독 업데이트가 실패한다면 URL 만료, 인증 토큰 누락, 시스템 시간 오류, TLS 인증서 검증 실패를 순서대로 점검하는 것이 좋습니다.

  1. 클라이언트의 프로필 화면에서 새 구독을 추가합니다.
  2. 구독을 업데이트한 뒤 노드 이름과 서버 지역이 표시되는지 확인합니다.
  3. 프록시 그룹에서 노드 하나를 수동으로 선택해 기본 연결을 테스트합니다.
  4. 대시보드의 지연 시간 테스트를 실행하고, 지나치게 낮은 수치만 보지 말고 실제 웹 페이지 로딩도 확인합니다.
  5. 정상 노드와 예비 노드를 각각 하나 이상 확보한 뒤 Gemini 전용 그룹을 만듭니다.

자동 선택 그룹은 편리하지만 테스트 URL에 따라 결과가 달라집니다. 일반적인 204 응답 테스트가 빠르더라도 Google 관련 서비스와의 실제 연결 품질까지 보장하지는 않습니다. 따라서 처음에는 select 그룹으로 노드를 직접 비교하고, 안정적인 후보가 정해진 뒤 url-test 또는 fallback을 추가하는 방식이 안전합니다.

Gemini용 프록시 그룹 예제
proxy-groups:
  - name: Gemini-AI
    type: select
    proxies:
      - Auto-Select
      - node-us-01
      - node-jp-01
      - DIRECT

  - name: Auto-Select
    type: url-test
    proxies:
      - node-us-01
      - node-jp-01
      - node-sg-01
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80

위 예제의 노드 이름은 구독에 실제로 존재하는 이름으로 바꿔야 합니다. YAML의 들여쓰기는 공백 두 칸을 기준으로 일관되게 유지하고, 그룹 이름에 한글을 사용할 때는 규칙에서 동일한 문자열을 정확히 입력하세요. 설정을 저장한 뒤 오류가 발생하면 복사한 구독 전체를 수정하기보다 먼저 프록시 그룹 부분만 별도 확인하는 것이 빠릅니다.

Gemini 트래픽만 분리하는 라우팅 규칙

핵심은 Gemini 화면을 구성하는 도메인을 하나의 그룹으로 보내되, 국내 웹사이트와 계정에 필요한 일반 트래픽은 기존 정책을 유지하는 것입니다. 도메인 목록은 서비스 구조나 시점에 따라 변경될 수 있으므로 아래 예제를 절대적인 목록으로 보지 말고, 연결 로그에 실제로 나타나는 호스트를 기준으로 보완하세요. Google 로그인 과정에서는 Gemini 본체 외에 계정, 인증, 정적 리소스 도메인이 함께 사용될 수 있습니다.

Gemini 관련 도메인 라우팅 예제
rules:
  - DOMAIN-SUFFIX,gemini.google.com,Gemini-AI
  - DOMAIN-SUFFIX,ai.google,Gemini-AI
  - DOMAIN-SUFFIX,accounts.google.com,Gemini-AI
  - DOMAIN-SUFFIX,googleusercontent.com,Gemini-AI
  - DOMAIN-SUFFIX,gstatic.com,Gemini-AI
  - MATCH,DIRECT

이 방식의 장점은 문제 발생 시 어느 규칙이 연결을 처리했는지 쉽게 확인할 수 있다는 점입니다. 다만 accounts.google.com이나 gstatic.com을 전체적으로 프록시하면 다른 Google 서비스도 같은 그룹을 사용할 수 있습니다. 개인정보 보호와 로그인 안정성 사이의 균형이 필요하다면 먼저 Gemini 접속에 필요한 최소 도메인만 적용하고, 연결 로그에서 누락된 요청이 확인될 때 하나씩 추가하세요.

규칙의 순서도 매우 중요합니다. 더 구체적인 DOMAIN-SUFFIX 규칙은 일반적인 Google 규칙이나 국가별 직접 연결 규칙보다 위에 있어야 합니다. GEOIP, IP-CIDR, MATCH가 먼저 나오면 도메인 규칙에 도달하지 못할 수 있습니다. 또한 규칙을 수정한 뒤에는 프로필을 다시 로드하고 기존 연결을 정리해야 새 정책이 적용됩니다.

DNS, TLS와 노드 안정성 점검

도메인 기반 라우팅을 사용할 때는 DNS가 규칙 매칭보다 먼저 안정적으로 동작해야 합니다. Mihomo에서는 fake-ip 모드가 도메인 규칙과 잘 맞지만, 일부 앱이나 보안 소프트웨어가 가상 IP를 처리하지 못하는 경우도 있습니다. 데스크톱 브라우저에서만 테스트한다면 fake-ip을 우선 사용하고, 문제가 생길 때 해당 도메인을 fake-ip-filter에 추가하는 방식으로 범위를 좁히세요.

권장 DNS 기본 설정
dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  fake-ip-filter:
    - '*.lan'
    - '*.local'
    - 'time.*.com'

DNS 설정을 바꾼 뒤에는 브라우저의 DNS 캐시와 기존 연결을 함께 초기화해야 합니다. 브라우저를 완전히 종료했다가 다시 실행하고, Clash 대시보드에서 활성 연결을 종료하세요. 운영체제의 보안 DNS, 브라우저의 “보안 DNS 사용” 기능, 다른 VPN 또는 광고 차단 앱이 별도의 DNS 경로를 만들고 있지는 않은지도 확인해야 합니다.

TLS 관련 오류가 발생하면 skip-cert-verify: true로 해결하려 하지 마세요. 이 옵션은 인증서 검증을 약화시키며, 로그인 정보를 다루는 서비스에서는 특히 위험합니다. 대신 시스템 날짜와 시간, 노드의 SNI, 서버 인증서, 클라이언트 버전을 확인하세요. 노드가 443 포트를 사용하더라도 실제 전송 방식과 TLS 설정이 일치하지 않으면 연결이 간헐적으로 끊길 수 있습니다.

  • 첫 번째 노드에서 로그인 페이지가 열리는지 확인합니다.
  • 같은 노드로 일반 Google 계정 페이지와 정적 리소스가 로드되는지 확인합니다.
  • 두 번째 노드로 바꾸어 같은 과정을 반복합니다.
  • 한 노드만 실패하면 DNS보다 노드 IP 평판과 서버 상태를 우선 의심합니다.
  • 모든 노드에서 실패하면 규칙, 계정 상태, 브라우저 캐시, 공식 서비스 제한을 함께 확인합니다.

로그인 오류와 속도 문제 해결 순서

로그인 오류가 발생했을 때 여러 항목을 동시에 변경하면 원인을 찾기 어렵습니다. 다음 순서로 한 번에 한 가지씩 변경하세요. 먼저 시크릿 모드에서 Gemini에 접속해 확장 프로그램과 기존 쿠키의 영향을 분리합니다. 시크릿 모드에서 정상이라면 일반 창의 쿠키와 사이트 데이터를 삭제하고, 비밀번호 관리 확장 프로그램이나 광고 차단 확장을 잠시 비활성화합니다.

  1. Clash에서 Gemini-AI 그룹을 안정적인 노드로 수동 선택합니다.
  2. 브라우저의 Gemini 및 Google 로그인 사이트 데이터를 삭제합니다.
  3. Clash 연결 목록을 비운 뒤 브라우저를 다시 시작합니다.
  4. 로그인 페이지와 Gemini 본체가 같은 정책 그룹을 사용하는지 확인합니다.
  5. 응답 생성 중 끊기면 다른 지역 노드와 다른 전송 방식의 노드를 비교합니다.
  6. 계정에 보안 확인이나 추가 인증이 표시되면 반복 로그인을 중단하고 공식 절차를 완료합니다.

속도는 단순한 핑 수치보다 실제 왕복 시간과 지속 연결 품질이 중요합니다. 노드 테스트 결과가 80ms인 노드라도 피크 시간대에 패킷 손실이 높으면 응답 생성이 자주 중단될 수 있습니다. 반대로 150ms 노드라도 연결이 안정적이면 긴 대화에서는 더 나은 체감 성능을 보일 수 있습니다. url-test의 전환이 너무 잦다면 tolerance 값을 높이거나 테스트 간격을 늘려 세션 중간의 불필요한 노드 변경을 줄이세요.

문제 기록을 남길 때는 노드 이름, 발생 시간, 사용한 클라이언트, 오류 단계, 연결 로그의 규칙 이름을 함께 적으세요. “안 된다”보다 “Gemini 페이지는 열리지만 accounts.google.com 요청이 DIRECT로 매칭된 뒤 로그인에서 멈춘다”처럼 기록하면 해결 속도가 크게 빨라집니다.

자주 묻는 질문

Gemini 규칙을 모든 Google 도메인에 적용해야 하나요?

그럴 필요는 없습니다. 우선 Gemini 본체와 로그인에 실제로 사용되는 도메인만 확인해 추가하세요. 모든 Google 트래픽을 하나의 프록시로 보내면 국내 서비스까지 느려지고 계정 보안 확인이 증가할 수 있습니다.

DIRECT로 두어도 되는 도메인은 무엇인가요?

일반 국내 사이트나 프록시가 필요하지 않은 서비스는 기존 DIRECT 정책을 유지하는 것이 좋습니다. 다만 로그인 과정에서 필요한 호스트가 DIRECT로 처리되어 실패한다면 연결 로그를 확인한 뒤 해당 도메인만 Gemini-AI 그룹에 추가하세요.

노드 Ping은 정상인데 Gemini가 열리지 않는 이유는 무엇인가요?

노드 지연 시간 테스트는 특정 테스트 서버와의 연결만 측정합니다. Gemini의 TLS, DNS, IP 평판, 인증 흐름까지 보장하지는 않습니다. 실제 Gemini 도메인 접속과 로그인 요청을 별도로 확인하고, 다른 노드와 비교해야 합니다.

Clash를 바꿔도 로그인 오류가 계속됩니다.

계정의 보안 확인, 브라우저 쿠키, 시스템 시간, 공식 지원 조건을 먼저 점검하세요. 여러 노드로 짧은 시간에 반복 로그인하면 위험 감지가 강화될 수 있으므로 무리하게 재시도하지 말고 공식 도움말과 계정 알림을 확인하는 것이 안전합니다.

Gemini 3 접속 안정화의 핵심은 모든 트래픽을 무조건 우회하는 것이 아니라, 실제로 필요한 도메인과 연결 단계를 확인한 뒤 최소 범위로 규칙을 적용하는 것입니다. 구독 업데이트 상태, 노드의 지속적인 연결 품질, DNS 모드, 규칙 순서를 차례로 점검하면 대부분의 설정 오류를 빠르게 분리할 수 있습니다. 먼저 수동 노드와 시크릿 모드로 기준 상태를 만든 다음 자동 선택과 세부 규칙을 추가하면, 환경이 바뀌어도 재현 가능한 Clash 구성을 유지할 수 있습니다.

시작하기

Clash로 트래픽을 완전히 제어하세요

Windows, macOS, Linux, Android, iOS 지원. 유연한 규칙, 간단한 설정.

무료 다운로드 설정 가이드 보기 →