Gemini 접속 오류가 정말 Clash 문제인지 먼저 구분하기
Clash에서 Gemini가 열리지 않거나 계속 시간 초과가 발생하는 경우, 무조건 노드를 바꾸는 것부터 시작하면 원인을 놓치기 쉽습니다. 브라우저에서 gemini.google.com 자체가 열리지 않는지, 로그인 화면은 보이지만 채팅 요청만 멈추는지, 또는 짧은 질문은 되는데 긴 답변이나 파일 업로드에서만 끊기는지를 먼저 나눠 보세요. 증상마다 확인해야 할 계층이 다르기 때문입니다.
아예 페이지가 로드되지 않는다면 DNS 응답, 프록시 모드, 노드의 TLS 연결을 먼저 봐야 합니다. 로그인은 되지만 메시지를 보낼 때 Network error나 Request timed out이 나타난다면 Gemini API 요청이 다른 규칙을 타고 있을 가능성이 큽니다. 반대로 웹사이트는 정상인데 특정 데스크톱 앱이나 터미널에서만 실패한다면, 해당 프로그램이 시스템 프록시를 사용하지 않거나 별도의 환경 변수를 요구할 수 있습니다.
문제를 재현할 때는 여러 설정을 동시에 바꾸지 않는 것이 중요합니다. 현재 사용 중인 노드, 모드, DNS 방식, TUN 상태를 메모한 다음 한 항목씩 변경해야 어떤 조치가 효과가 있었는지 확인할 수 있습니다. 또한 회사·학교·공공 Wi-Fi의 네트워크 정책이나 Google 계정의 지역 제한이 원인일 수도 있으므로, 개인 네트워크와 다른 회선에서도 같은 증상이 나타나는지 비교해 보세요.
1단계: Clash 프로필과 노드의 기본 상태 확인
먼저 Clash 클라이언트에서 올바른 프로필이 활성화되어 있는지 확인합니다. 구독을 갱신한 뒤 프로필은 바뀌었지만 실제로는 이전 설정을 사용하거나, 규칙 프로바이더가 업데이트되지 않아 오래된 도메인 분기가 남아 있는 경우가 있습니다. 프로필 화면에서 현재 사용 중인 코어가 정상 실행 중인지, 설정 파일 오류나 재시작 반복이 없는지도 함께 확인하세요.
그다음 프록시 그룹에서 현재 노드의 상태를 살펴봅니다. 노드 이름이 초록색으로 표시되어도 실제 Gemini 연결이 안정적이라는 뜻은 아닙니다. 단순 연결 테스트는 짧은 TCP 또는 HTTP 요청만 확인할 수 있어, 로그인 리디렉션이나 긴 HTTPS 스트리밍 응답까지 보장하지 않습니다. 같은 그룹의 다른 노드를 두세 개 선택해 Gemini 페이지와 채팅 요청을 각각 테스트하고, 특정 노드에서만 시간 초과가 발생하는지 비교하는 편이 정확합니다.
- 모든 노드에서 실패: 프록시 모드, DNS, 규칙 또는 로컬 방화벽을 우선 확인합니다.
- 일부 노드에서만 실패: 해당 노드의 지연 시간, 출구 지역, TLS 안정성 또는 제공자 측 혼잡을 의심합니다.
- 페이지는 열리지만 응답만 실패: Gemini 관련 API·인증 도메인이 다른 정책으로 빠지는지 확인합니다.
- 잠시 후 자동 복구: 노드의 순간적인 패킷 손실, 연결 수 제한, 스트리밍 유지 문제일 수 있습니다.
Clash의 연결 로그를 열어 Gemini를 새로고침하거나 메시지를 보낸 직후의 호스트를 기록하세요. 일반적으로 gemini.google.com 외에도 Google 로그인과 API 요청에 사용되는 여러 호스트가 나타날 수 있습니다. 로그에 DIRECT, REJECT, 예상하지 못한 프록시 그룹이 표시된다면 노드 자체보다 규칙 매칭이 먼저 해결되어야 합니다.
2단계: 시스템 프록시와 TUN 모드를 순서대로 점검하기
Clash에는 보통 규칙 모드, 글로벌 모드, 직접 연결 모드가 있습니다. Gemini 문제를 진단할 때는 먼저 잠시 글로벌 모드로 전환해 보세요. 모든 트래픽을 현재 선택한 프록시 그룹으로 보내는 방식이므로, 글로벌 모드에서 Gemini가 정상화된다면 노드보다 규칙 설정에 문제가 있을 가능성이 높습니다. 다만 글로벌 모드는 국내 사이트와 패키지 저장소까지 프록시를 통과시켜 불필요한 지연을 만들 수 있으므로, 원인 확인 후에는 규칙 모드로 돌아오는 것이 좋습니다.
글로벌 모드에서도 동일하게 시간 초과가 발생한다면 시스템 프록시가 실제로 켜져 있는지 확인하세요. Clash 화면에서 프록시 스위치를 켰더라도 운영체제의 HTTP·HTTPS 프록시가 비활성화되어 있거나, 다른 VPN 프로그램이 프록시 설정을 덮어쓰는 경우가 있습니다. 브라우저의 수동 프록시 설정, 운영체제 네트워크 설정, 보안 프로그램의 웹 보호 기능이 서로 다른 포트를 가리키지 않는지 점검해야 합니다.
브라우저 이외의 앱이나 터미널까지 같은 경로로 보내야 한다면 TUN 모드가 필요할 수 있습니다. TUN은 가상 네트워크 인터페이스를 통해 시스템 트래픽을 가로채므로, 시스템 프록시를 무시하는 프로그램에도 적용 범위를 넓힐 수 있습니다. 그러나 TUN을 켠다고 항상 문제가 해결되는 것은 아닙니다. 관리자 권한, 가상 인터페이스 충돌, 운영체제 방화벽, 다른 VPN 드라이버와의 중복이 있으면 오히려 연결이 불안정해질 수 있습니다.
TUN을 처음 켤 때는 기존 VPN이나 네트워크 필터를 잠시 종료하고 Clash만 실행해 보세요. 또한 자동 라우팅, DNS 처리, 스택 모드 같은 항목이 클라이언트마다 다르게 표시되므로, 변경 전 현재 값을 적어 두는 것이 안전합니다. TUN을 끈 상태에서 브라우저 시스템 프록시만으로 정상 작동한다면, TUN을 계속 사용할 필요는 없습니다. 반대로 Gemini 앱이나 터미널만 실패한다면 TUN과 해당 프로세스의 라우팅을 별도로 확인해야 합니다.
3단계: Gemini와 Google 인증 도메인의 규칙을 확인하기
규칙 모드에서는 Gemini 웹 도메인만 프록시로 보내고 인증·정적 리소스는 직접 연결하는 식의 불완전한 분기가 자주 발생합니다. 화면은 열리지만 로그인 토큰 교환이나 채팅 요청에서 멈추는 이유가 여기에 있습니다. Clash 연결 로그에서 Gemini를 새로고침하고 로그인한 다음, 관련 요청이 동일한 프록시 그룹을 통과하는지 확인하세요.
일반적인 환경에서는 다음과 같은 호스트가 로그에 나타날 수 있지만, 실제 사용 중인 클라이언트와 Google 계정 흐름에 따라 달라질 수 있습니다.
- Gemini 웹:
gemini.google.com - Google 로그인:
accounts.google.com및 인증 관련 호스트 - Google API:
generativelanguage.googleapis.com,aiplatform.googleapis.com등 - 정적 콘텐츠: Google 서비스가 사용하는 CDN 또는 별도 리소스 도메인
규칙을 직접 추가할 때는 지나치게 넓은 DOMAIN-KEYWORD,google 같은 표현보다 로그에서 확인한 호스트를 우선 사용하세요. Google 전체 트래픽을 하나의 그룹으로 보내면 검색, 지도, 업무용 서비스까지 불필요하게 우회될 수 있고, 일부 계정 보안 검사가 비정상적으로 작동할 수 있습니다. 가능하다면 DOMAIN-SUFFIX 또는 정확한 DOMAIN 규칙으로 범위를 좁히고, 규칙의 순서가 지역 규칙이나 GEOIP 규칙보다 앞에 있는지 확인합니다.
규칙을 저장한 뒤에는 반드시 프로필을 재로드하거나 코어를 재시작해야 합니다. 화면에서 YAML을 수정했더라도 실행 중인 코어에 이전 규칙이 남아 있으면 결과가 바뀌지 않습니다. 수정 후 연결 로그에서 실제 정책 그룹이 바뀌었는지 확인하고, 같은 노드에서 새 탭을 열어 다시 테스트하세요. 캐시와 기존 세션 때문에 결과가 혼동될 수 있으므로, 필요하면 시크릿 창에서 로그인 흐름을 재현하는 것도 도움이 됩니다.
4단계: DNS와 연결 유지 문제 조정하기
Gemini 접속 시간 초과가 간헐적으로 반복되면 DNS 응답이 불안정하거나, DNS 결과와 실제 프록시 출구가 서로 맞지 않는 상황을 의심할 수 있습니다. 로컬 공유기 DNS가 특정 도메인을 제대로 해석하지 못하거나, 운영체제가 먼저 받은 DNS 결과를 캐시해 잘못된 주소를 계속 사용할 수도 있습니다. Clash의 DNS 모드를 사용한다면 현재 모드가 fake-ip인지 redir-host인지 확인하고, 문제가 시작된 시점에 DNS 설정을 변경했는지도 돌아보세요.
DNS 설정을 바꿀 때는 여러 서버를 무작정 추가하기보다 하나의 안정적인 구성을 기준으로 테스트하는 것이 좋습니다. DNS 요청도 프록시를 통과해야 하는 환경이라면 DNS 누수 방지와 원격 해석 옵션을 검토해야 하지만, 사용 중인 코어와 클라이언트가 해당 옵션을 모두 지원하는지는 다를 수 있습니다. 설정 파일에 존재하지 않는 필드나 다른 코어 전용 옵션을 복사하면 프로필 자체가 오류로 비활성화될 수 있으니, 먼저 공식 문서와 현재 코어의 지원 범위를 확인하세요.
페이지는 열리는데 긴 답변 중간에 멈춘다면 DNS보다 연결 유지 문제가 더 가까울 수 있습니다. 불안정한 노드는 HTTP/2 스트림이나 긴 응답을 오래 유지하지 못하고, 프록시 제공자가 연결 수를 제한하면 짧은 요청만 성공하는 패턴이 나타납니다. 이때는 노드의 평균 핑보다 실제 Gemini 요청의 첫 응답 시간과 스트리밍 지속 시간을 비교해야 합니다. 여러 노드에서 같은 요청을 반복하되, 요청 횟수를 과도하게 늘려 계정 제한이나 서비스 측 방어를 유발하지 않도록 주의하세요.
마지막 확인 순서와 안정적인 설정 유지 방법
수정이 끝났다면 다음 순서로 원상태를 재현해 보세요. 먼저 Clash를 재시작하고 프로필과 규칙 프로바이더가 정상적으로 로드되었는지 확인합니다. 그다음 규칙 모드에서 Gemini 홈 화면을 열고, 로그인 세션을 확인한 뒤 짧은 메시지와 비교적 긴 메시지를 차례로 보내세요. 각 단계에서 연결 로그를 확인해 같은 호스트가 같은 정책 그룹을 타는지 살펴보면 설정 변경의 효과를 객관적으로 판단할 수 있습니다.
- 현재 노드와 프록시 포트를 기록합니다.
- 시스템 프록시 또는 TUN 중 실제로 필요한 방식 하나를 우선 활성화합니다.
- 글로벌 모드로 규칙 문제인지 노드·DNS 문제인지 분리합니다.
- 로그에서 Gemini와 인증 관련 호스트의 실제 정책을 확인합니다.
- 규칙을 좁은 범위로 추가하고, 프로필을 재로드한 뒤 다시 테스트합니다.
- 안정화된 뒤에는 글로벌 모드 대신 필요한 도메인만 프록시를 통과시키는 규칙 모드로 되돌립니다.
설정 파일을 수정할 때는 개인 구독 URL이나 인증 정보가 포함된 내용을 공개 저장소나 커뮤니티에 그대로 올리지 마세요. 문제 해결을 위해 로그를 공유해야 한다면 계정 이메일, 토큰, 노드 주소, 내부 IP를 지우고 도메인·정책 결과·오류 시각만 남기는 것이 안전합니다. 또한 Gemini 자체의 서비스 장애나 계정 제한은 Clash 설정으로 해결할 수 없으므로, 다른 네트워크와 공식 상태 안내에서도 같은 문제가 발생하는지 확인해야 합니다.
일부 단순 프록시 앱은 한 번에 전체 트래픽만 우회해 설정이 쉬운 대신, Gemini 인증 호스트와 API 호스트를 나누어 확인하기 어렵고 TUN·DNS·규칙 로그가 제한적인 경우가 있습니다. 반면 Clash는 처음에는 프로필과 규칙 구조가 복잡해 보여도, 어떤 요청이 DIRECT인지 어떤 요청이 특정 프록시 그룹을 타는지 확인하면서 원인을 좁힐 수 있고, 필요한 도메인만 분기해 다른 서비스의 속도 저하도 줄일 수 있습니다. Gemini 시간 초과를 노드 교체만으로 반복 해결하기보다 이런 로그 기반 설정을 직접 관리하고 싶다면, 사용 중인 플랫폼에 맞는 Clash 클라이언트를 내려받아 같은 점검 순서를 적용해 보세요.