Clash에서 Gemini 접속이 안 될 때 타임아웃 해결법 완벽 가이드

증상부터 구분하기: Gemini만 타임아웃되는 이유

Clash를 실행한 뒤 일반 검색 사이트나 동영상 서비스는 정상적으로 열리는데 Gemini만 계속 로딩되거나 “연결 시간이 초과되었습니다”라는 메시지가 표시된다면, 프록시 전체가 멈춘 것으로 단정하지 않는 것이 좋습니다. 이 증상은 대개 노드 자체의 장애, Gemini 관련 도메인의 라우팅 오류, DNS 해석 실패, 브라우저의 연결 방식, TUN 또는 시스템 프록시 충돌 중 하나에서 발생합니다. 특히 Gemini는 한 페이지를 여는 순간 끝나는 서비스가 아니라 로그인, API 요청, 대화 목록 조회, 응답 스트리밍 등 여러 Google 도메인과 연결을 이어 가므로 일부 요청만 DIRECT로 빠져도 화면이 완전히 열리지 않을 수 있습니다.

먼저 같은 브라우저에서 다른 해외 사이트를 하나 열고, Gemini를 시크릿 창이나 다른 브라우저에서도 테스트하세요. 모든 브라우저에서 동일하게 실패하면 Clash의 라우팅이나 노드 문제일 가능성이 높고, 한 브라우저에서만 실패하면 확장 프로그램, 캐시, 보안 DNS, 쿠키 문제가 더 유력합니다. Gemini 앱을 사용하는 모바일 환경에서는 앱별 VPN 제외 목록이나 배터리 절전 정책도 함께 확인해야 합니다.

증상	우선 의심할 원인	첫 번째 확인 항목
Gemini 주소부터 열리지 않음	노드, DNS, 도메인 규칙	`gemini.google.com`의 매칭 정책과 DNS 로그
화면은 열리지만 로그인 실패	Google 인증 도메인 누락, 쿠키 문제	`accounts.google.com` 및 브라우저 쿠키
질문 전송 후 응답만 멈춤	스트리밍 연결, 노드 품질, HTTP/3	다른 노드와 TCP 기반 연결 비교
Clash를 끄면 정상 작동	라우팅 또는 DNS 우회	Rule 모드와 Global 모드 결과 비교
모바일에서 화면을 끄면 끊김	VPN 권한, 배터리 제한	VPN 연결 상태와 백그라운드 제한

노드와 프록시 모드부터 점검하기

가장 빠른 진단 방법은 현재 규칙을 바로 수정하는 것이 아니라, 먼저 안정적인 노드와 전역 프록시를 이용해 원인을 분리하는 것입니다. Clash Verge Rev, Clash for Windows, Mihomo 계열 클라이언트에서 Profiles 또는 Proxies 화면을 열고, 지연 시간이 짧은 노드를 하나 선택하세요. 지연 시간이 낮아도 실제 HTTPS 연결 품질이 좋다는 뜻은 아니므로, 단순한 ping 숫자보다 Gemini 페이지 로딩과 질문 전송 결과를 기준으로 판단해야 합니다. 여러 노드가 같은 지역에 있어도 서버의 TCP 연결 품질, TLS 처리, Google 서비스 접근성은 서로 다를 수 있습니다.

현재 선택된 노드와 프록시 그룹의 실제 출구를 확인합니다. URL 테스트가 성공해도 Gemini에 적합하다는 보장은 없으므로 최소 두세 개 노드를 직접 비교합니다.
모드를 Global로 잠시 바꿉니다. Global 모드에서는 대부분의 연결이 선택한 프록시로 전달되므로, Rule 모드의 규칙 누락 여부를 빠르게 분리할 수 있습니다.
Global 모드에서 Gemini가 열리면 Rule 모드로 돌아가 gemini.google.com, accounts.google.com 및 페이지에서 실제로 호출되는 Google 관련 도메인의 매칭 결과를 확인합니다.
Global 모드에서도 실패하면 노드를 교체하고 DNS와 TUN을 점검합니다. 같은 노드만 반복해서 테스트하면 원인 판단이 늦어집니다.

Rule 모드에서 사용할 수 있는 기본적인 방향은 다음과 같습니다. 실제 설정의 정책 그룹 이름은 구성 파일마다 다르므로 PROXY라는 이름을 그대로 복사하기보다 현재 설정에 존재하는 그룹명을 사용해야 합니다.

rules:
  - DOMAIN-SUFFIX,gemini.google.com,PROXY
  - DOMAIN,accounts.google.com,PROXY
  - MATCH,PROXY

이 규칙은 예시일 뿐이며 Google 전체를 무조건 프록시로 보내야 한다는 뜻은 아닙니다. 인증, 정적 리소스, 대화 데이터가 서로 다른 호스트에서 제공될 수 있기 때문에 개발자 도구의 Network 탭이나 Clash 연결 로그에서 실제 요청 호스트를 확인한 뒤 필요한 범위만 추가하세요. DOMAIN-KEYWORD,google처럼 지나치게 넓은 키워드 규칙은 국내 Google 서비스나 다른 정상 요청까지 예기치 않게 프록시로 보내므로 우선 사용하지 않는 편이 안전합니다.

전역 모드는 영구 해결책이 아니라 진단 단계입니다

Global 모드에서만 Gemini가 열린다면 우선 라우팅 문제로 결론 내릴 수 있습니다. 이후에는 실제 누락 도메인을 확인해 Rule 모드에 최소한의 규칙만 추가하세요. 모든 트래픽을 계속 전역 프록시로 보내면 국내 사이트 지연과 노드 사용량이 불필요하게 증가할 수 있습니다.

라우팅 규칙과 DNS 해석 확인하기

Gemini 타임아웃에서 DNS 문제는 두 가지 형태로 나타납니다. 첫째, 도메인이 잘못된 주소로 해석되어 연결 대상 자체가 틀리는 경우입니다. 둘째, DNS 조회는 성공했지만 해당 조회가 Clash를 거치지 않아 브라우저가 로컬 네트워크의 결과를 사용하는 경우입니다. 후자는 다른 사이트가 열리기 때문에 놓치기 쉽습니다.

Clash의 연결 또는 로그 화면을 열고 Gemini를 새로고침하면서 어떤 도메인이 DIRECT와 PROXY로 처리되는지 확인하세요. gemini.google.com이 DIRECT로 표시되면 규칙 순서나 정책 그룹을 수정해야 합니다. 위쪽에 DOMAIN-SUFFIX,google.com,DIRECT 같은 넓은 규칙이 있다면 뒤에 추가한 Gemini 규칙은 도달하지 않습니다. Clash는 위에서 아래로 검사하고 첫 번째로 일치한 규칙에서 멈추므로, 예외 규칙은 넓은 규칙보다 앞에 배치해야 합니다.

DNS 설정에서는 enable, listen, nameserver, fallback, enhanced-mode를 함께 살펴봅니다. fake-ip를 사용하는 환경에서는 애플리케이션이 받은 198.18.0.0/16 대역의 가상 주소를 Clash가 원래 도메인으로 복원해야 합니다. 이 과정이 특정 브라우저나 Google 연결과 충돌하면 잠시 redir-host로 바꿔 비교할 수 있습니다. redir-host에서만 작동한다면 fake-ip 필터, DNS 매핑, 스니핑 설정을 의심하고, redir-host에서도 실패한다면 노드나 라우팅을 먼저 확인하세요.

nameserver 확인: 기본 업스트림이 응답하는지, 주소를 너무 많이 넣어 지연이 커지지 않았는지 확인합니다.
fallback 확인: 해외 도메인에 사용할 경로가 평문 DNS가 아닌 암호화된 DNS인지 살펴봅니다.
default-nameserver 확인: DoH 또는 DoT 서버의 호스트명을 처음 해석할 순수 IP가 필요합니다.
DNS 지연 확인: Gemini 접속 순간 로그에 반복적인 timeout, SERVFAIL, no such host가 발생하는지 확인합니다.
브라우저 보안 DNS 확인: Chrome, Edge, Firefox의 자체 Secure DNS가 Clash의 DNS 경로를 우회하는지 확인하고, 진단 중에는 잠시 끄거나 Clash와 일관된 방식으로 맞춥니다.

DNS 설정을 바꾼 뒤에는 브라우저 탭만 새로고침하지 말고 Clash의 DNS 캐시를 비우거나 클라이언트를 재시작하세요. 운영체제에도 이전 결과가 남아 있을 수 있습니다. Windows에서는 명령 프롬프트에서 ipconfig /flushdns를 실행하고, macOS에서는 네트워크 연결을 껐다 켜거나 DNS 캐시를 초기화한 뒤 다시 테스트합니다. 단, 캐시 초기화만으로 해결되는 경우는 일시적인 오염에 가깝고, 계속 재발한다면 업스트림과 라우팅 구조를 수정해야 합니다.

TUN, 시스템 프록시와 전송 방식 점검하기

시스템 프록시와 TUN은 서로 다른 방식으로 트래픽을 인수합니다. 시스템 프록시는 HTTP 또는 SOCKS 프록시를 따르는 애플리케이션에만 적용되며, 모든 앱과 모든 DNS 요청을 자동으로 처리하지는 않습니다. 반면 TUN은 가상 네트워크 인터페이스를 통해 더 넓은 범위의 TCP와 UDP 트래픽을 Clash로 넘깁니다. 브라우저만 사용할 때는 시스템 프록시로 충분할 수 있지만, 앱 내부 연결이나 DNS, HTTP/3까지 함께 확인하려면 TUN이 필요할 수 있습니다.

TUN을 켤 때는 기존 VPN, 다른 프록시 프로그램, 보안 제품의 네트워크 필터를 먼저 끄고 하나씩 테스트하세요. Windows에서는 관리자 권한과 TUN 서비스 설치 여부를 확인하고, macOS에서는 네트워크 확장 또는 VPN 구성 허용 여부를 확인합니다. Android에서는 Clash의 VPN 연결 요청을 허용해야 하며, 배터리 최적화가 켜져 있으면 화면이 꺼진 뒤 터널이 종료될 수 있습니다. iOS 역시 VPN 구성 추가를 허용하지 않으면 앱 화면은 열려도 실제 프록시 연결이 만들어지지 않습니다.

Gemini의 응답이 질문 전송 후 멈추는 경우에는 UDP와 HTTP/3도 의심할 수 있습니다. 일부 노드나 중간 네트워크에서 UDP 443 기반 QUIC 처리가 불안정하면 페이지 자체는 열리지만 스트리밍 응답이 끊기거나 긴 타임아웃이 발생할 수 있습니다. 진단 단계에서는 Clash 또는 브라우저에서 QUIC 사용을 제한하고 TCP 기반 HTTPS로 비교해보세요. TCP로 바꿨을 때 정상화되면 DNS보다 전송 경로와 노드의 UDP 지원 상태가 핵심 원인일 가능성이 큽니다.

설정 조합	장점	문제 발생 시 확인할 점
시스템 프록시 + Rule	구성이 간단하고 데스크톱 브라우저에 적합	브라우저 DNS와 앱별 우회 여부
시스템 프록시 + Global	규칙 누락 여부를 빠르게 확인	노드 품질과 인증 도메인 접근
TUN + Rule	앱과 DNS까지 폭넓게 인수	권한, DNS hijack, 라우팅 충돌
TUN + Global	전체 경로를 단순화한 진단용 조합	다른 VPN 및 방화벽과의 중복

로그로 원인을 확정하고 재발을 막기

설정을 한 번에 여러 개 바꾸면 무엇이 해결했는지 알 수 없습니다. 다음 순서로 한 항목씩 변경하고, 매번 새 브라우저 창에서 Gemini에 접속해 결과를 기록하세요. 먼저 노드를 교체하고, 다음으로 Global 모드에서 비교한 뒤, Rule 모드의 매칭 결과를 수정합니다. 이후 DNS 캐시를 비우고 enhanced-mode를 비교하며, 마지막으로 TUN과 QUIC 관련 설정을 확인하는 순서가 효율적입니다.

Clash 로그 레벨을 Info 또는 Debug로 설정하고 Gemini 접속을 시도합니다. 장시간 Debug를 유지하면 로그가 빠르게 쌓일 수 있으므로 진단 후 원래 수준으로 되돌립니다.
로그에서 gemini.google.com, 인증 호스트, 연결 대상 IP, 선택된策略 그룹, timeout 또는 handshake 오류를 찾습니다.
같은 시각의 브라우저 개발자 도구 Network 탭에서 실패한 요청의 호스트와 상태를 확인합니다. 브라우저에는 실패했지만 Clash 로그에 요청이 없다면 브라우저 또는 DNS가 Clash를 우회한 것입니다.
노드 교체, Global 전환, DNS 모드 변경을 각각 단독으로 적용해 결과를 비교합니다.
해결 후에는 필요하지 않은 광범위한 규칙과 임시 예외를 제거하고, 현재 사용 중인 설정을 별도로 백업합니다.

연속해서 여러 노드에서 동일한 타임아웃이 발생하고 Global, TUN, DNS까지 정상이라면 계정이나 서비스 측 조건도 확인해야 합니다. 계정 지역, 로그인 세션, 조직 계정 정책, 브라우저 확장 프로그램, 시스템 시간이 영향을 줄 수 있습니다. 다른 계정이나 깨끗한 브라우저 프로필에서 같은 노드를 시험하면 네트워크 문제와 계정 문제를 분리하는 데 도움이 됩니다. 시스템 날짜와 시간이 크게 어긋나면 TLS 인증서 검증이 실패할 수 있으므로 자동 시간 동기화도 켜두세요.

가장 재현성이 높은 점검 순서

노드 교체 → Global 모드 비교 → Rule 로그 확인 → DNS 경로 확인 → TUN 권한 확인 → QUIC/TCP 비교 → 브라우저와 계정 점검 순서로 진행하면 불필요한 설정 변경을 줄일 수 있습니다. 정상화된 뒤에는 마지막으로 바꾼 항목을 하나씩 원래대로 돌려 실제 원인을 확정하세요.

자주 묻는 질문

다른 해외 사이트는 열리는데 Gemini만 안 열리면 노드가 고장 난 것인가요?

반드시 그렇지는 않습니다. Gemini 관련 도메인만 DIRECT로 매칭되거나, 인증 및 스트리밍 요청이 별도의 Google 호스트로 빠지는 경우에도 같은 증상이 나타납니다. 먼저 Global 모드에서 비교하고 Clash 로그에서 실패한 호스트의 정책을 확인하세요. Global에서도 실패할 때 노드를 교체해 결과가 달라지는지 확인하면 노드 문제를 더 정확히 판단할 수 있습니다.

fake-ip를 사용하면 Gemini가 항상 고장 나나요?

그렇지는 않습니다. fake-ip는 일반적으로 도메인 규칙과 DNS 제어에 유용하지만, 특정 브라우저나 연결 방식과 호환 문제가 생길 수 있습니다. redir-host로 잠시 비교해 보되, 결과가 달라졌다는 사실을 원인 확정으로 착각하지 말고 DNS 로그와 실제 매칭 결과를 함께 확인하세요.

Clash를 재설치하면 타임아웃이 해결되나요?

손상된 코어, 잘못된 권한, 오래된 캐시가 원인일 때만 도움이 됩니다. 대부분의 타임아웃은 재설치보다 노드, 규칙, DNS, TUN 충돌과 관련이 있으므로 현재 설정과 로그를 먼저 백업하고 원인을 분리하는 편이 효율적입니다.

해결된 뒤에도 어떤 설정을 기록해 두어야 하나요?

정상 작동한 클라이언트와 mihomo 커널 버전, 노드 그룹, 프록시 모드, DNS enhanced-mode, TUN 사용 여부, QUIC 제한 여부를 기록해 두세요. 다음에 같은 문제가 생겼을 때 한 항목씩 비교할 수 있어 복구 시간이 크게 줄어듭니다.

클라이언트와 설정을 최신 상태로 점검하기

오래된 커널이나 클라이언트는 최신 DNS, TUN, 스트리밍 연결 처리에서 예상하지 못한 문제를 만들 수 있습니다. 사용 중인 플랫폼에 맞는 클라이언트를 확인한 뒤 설정을 백업하고 업데이트하세요.

다운로드 확인 설정 가이드