먼저 증상을 나누고 연결 로그를 확인하세요

Clash에서 Grok이 열리지 않을 때는 “프록시가 안 된다”는 한 문장으로 원인을 단정하기 어렵습니다. 로그인 화면 자체가 열리지 않는 경우, 화면은 보이지만 대화 전송이 멈추는 경우, 답변 생성 도중 타임아웃이 나는 경우는 각각 다른 연결 단계에서 실패했을 수 있습니다. 여기에 브라우저 캐시, 계정 인증, 서비스 측 장애도 영향을 줍니다. 먼저 같은 기기와 네트워크에서 다른 웹사이트와 프록시 연결이 정상인지 확인하고, 실패 시각과 화면에 표시된 오류 문구를 기록해 두세요.

그다음 Clash의 연결(Connections) 로그를 열고 Grok을 새로고침하거나 메시지를 한 번 전송합니다. 실패 직후 새로 생긴 행에서 도메인, 사용된 정책 그룹, 최종 노드, 연결 상태를 확인하세요. 브라우저에서는 grok.com, x.ai, 계정 로그인이나 리다이렉트에 관련된 호스트가 보일 수 있지만, 실제 요청은 버전과 기능에 따라 달라질 수 있습니다. 따라서 특정 도메인 목록을 그대로 추측해 추가하기보다, 현재 로그에 나타난 호스트를 기준으로 살펴보는 편이 정확합니다.

ℹ 기록할 항목: 실패 시각, 오류 문구, 로그에 표시된 도메인, 해당 연결의 정책 그룹과 노드, 다른 웹사이트의 접속 여부를 함께 적어 두면 설정 문제와 회선 문제를 구분하기 쉽습니다.

전역 모드와 규칙 모드로 원인을 분리하기

가장 빠른 비교 방법은 전역(Global) 모드를 잠시 사용해 같은 브라우저에서 Grok을 다시 여는 것입니다. 전역 모드는 트래픽을 선택한 프록시 정책으로 보내는 테스트이므로, 규칙 모드에서만 실패하고 전역 모드에서는 성공한다면 노드보다는 규칙 매칭이나 정책 그룹 구성을 먼저 의심할 수 있습니다. 전역 모드에서도 같은 오류가 이어진다면 노드, DNS, 로컬 프록시 연결, 브라우저 또는 서비스 상태로 범위를 넓혀 점검합니다.

비교할 때는 한 번에 한 항목만 바꾸세요. 전역 모드로 전환한 뒤 로그에서 Grok 관련 연결이 실제로 선택한 정책을 타는지 확인하고, 결과를 기록한 다음 원래 모드로 돌립니다. 회사나 학교 네트워크처럼 프록시 정책이 정해져 있는 환경에서는 관리자의 허가 없이 모드를 바꾸거나 제한을 우회하지 마세요. 테스트가 끝나면 반드시 평소 사용 모드로 복구해야 다른 사이트의 트래픽이 예상하지 않은 경로로 나가지 않습니다.

전역 모드에서만 동작하는 경우에는 규칙 목록에서 해당 호스트가 어떤 규칙에 먼저 걸리는지 확인합니다. 위쪽에 넓은 범위의 도메인 규칙이나 일반적인 직접 연결 규칙이 있으면, 뒤쪽에 추가한 구체적인 규칙까지 도달하지 않을 수 있습니다. 규칙은 위에서 아래로 평가되는 구성이 일반적이므로, 구체적인 예외를 필요한 위치에 두고 마지막 정책에만 기대지 않는 것이 좋습니다. 규칙 동작의 기본 원리는 규칙 라우팅 점검법에서 함께 확인할 수 있습니다.

Grok 관련 규칙과 정책 그룹을 점검하세요

규칙 모드로 돌아온 뒤 로그에서 연결 행을 하나씩 선택해, 도메인이 예상한 정책 그룹으로 전달됐는지 봅니다. 웹페이지의 기본 문서 요청은 프록시를 타지만 인증 리다이렉트나 보조 API 요청은 DIRECT로 빠지는 식으로 경로가 나뉘면, 첫 화면은 열려도 로그인이나 메시지 전송 단계에서 실패할 수 있습니다. 반대로 관련 없는 트래픽까지 광범위하게 프록시 그룹에 넣으면 불필요한 지연이 생기고 다른 사이트의 동작도 달라질 수 있습니다.

규칙을 고친 뒤에는 프로필을 다시 불러오고, 연결 로그를 지운 다음 Grok을 새로고침해 새 연결이 의도한 그룹에 들어가는지 확인합니다. 기존 연결은 설정을 바꿔도 계속 살아 있을 수 있으므로, 화면만 새로고침했는데 결과가 달라지지 않는다면 브라우저 탭을 닫고 다시 열어 비교하세요. 여러 규칙을 한꺼번에 추가하면 어느 줄이 효과를 냈는지 알기 어려우므로, 한 줄씩 적용하고 로그 결과를 남기는 방식이 안전합니다.

노드 지연과 프록시 회선을 구분하세요

전역 모드에서도 Grok이 실패한다면 현재 선택한 노드가 정상인지 확인합니다. Clash의 프록시 목록이나 정책 그룹 화면에서 노드가 끊김 상태인지, 지연 측정이 계속 실패하는지 살펴보고, 제공되는 경우 서로 다른 노드 두 개를 차례로 테스트하세요. 한 노드에서만 타임아웃이 나고 다른 노드에서는 같은 브라우저와 같은 모드로 정상 접속된다면, 해당 노드의 회선이나 목적지까지의 경로가 원인일 가능성이 높습니다. 이때 규칙을 더 추가하기보다 정상 동작한 노드를 기본 선택으로 두고 차이를 기록하는 편이 낫습니다.

지연 시간 숫자만으로 판단하는 것은 주의해야 합니다. 짧은 연결 검사에서 응답이 빠르더라도, 실제 웹 애플리케이션의 인증이나 긴 응답 스트림이 같은 속도로 동작한다는 뜻은 아닙니다. 반대로 지연 측정 대상이 응답하지 않는다고 해서 모든 사이트 연결이 실패하는 것도 아닙니다. Grok 접속 시각의 연결 로그와 실제 페이지 동작을 함께 비교하고, 특정 노드에서만 재현되는지 확인하세요. 여러 노드와 다른 네트워크에서도 동시에 같은 오류가 나면 로컬 노드만을 원인으로 단정하지 않는 것이 중요합니다.

노드 변경이 원인 분리에 도움이 됐다면, 테스트 후에도 안정적으로 동작하는 노드를 선택하고 정책 그룹의 자동 선택·지연 테스트 기준을 확인하세요. 다만 자동 선택이 빠른 노드를 찾더라도 Grok과 다른 서비스에 동일한 최적 경로를 보장하지는 않습니다. 해외 서버를 오가는 경로, 제공자의 혼잡도, 시간대별 회선 상태에 따라 결과가 달라질 수 있으므로 같은 조건에서 비교하는 것이 좋습니다.

DNS, 브라우저, 인증 상태를 점검하세요

DNS 문제는 도메인 조회가 오래 걸리거나 잘못된 주소를 받는 방식으로 연결 지연을 만들 수 있습니다. 로그에서 도메인 조회 오류나 연결 전 단계의 실패가 보인다면, Clash 프로필의 DNS 설정을 최근에 변경했는지 확인하고, 운영체제와 클라이언트가 실제로 어떤 DNS 경로를 사용하는지 살펴보세요. 설정을 여러 곳에서 한꺼번에 바꾸지 말고 현재 프로필을 백업한 뒤 한 항목씩 검증해야 합니다. DNS 응답이 정상인데 연결 완료 후 Grok이 타임아웃된다면 원인은 DNS가 아니라 프록시 경로, 인증 또는 서비스 응답일 수 있습니다.

브라우저 쪽 문제도 간단히 배제할 수 있습니다. 다른 브라우저나 새 비공개 창에서 접속을 비교하고, 확장 프로그램을 잠시 끈 상태에서도 같은 증상이 나는지 확인하세요. 인증 쿠키가 오래됐거나 리다이렉트가 중간에 끊기면 메인 화면은 열려도 로그인 이후 요청이 실패할 수 있습니다. 쿠키와 사이트 데이터를 지우기 전에는 계정 재로그인이 필요한지 확인하고, 조직 계정이나 업무용 브라우저 정책이 있는 경우 데이터를 임의로 삭제하지 마세요.

시스템 시각이 크게 어긋나면 인증 과정의 토큰 유효성 검사에 문제가 생길 수 있으므로 날짜와 시간의 자동 설정도 확인합니다. 다른 브라우저와 다른 노드에서 모두 로그인 단계만 실패한다면 Clash 규칙을 계속 넓히기보다 계정 상태, 인증 화면의 오류, 서비스 공지 여부를 살펴보세요. 브라우저가 보여 주는 오류 코드와 Clash 로그의 실패 시각을 맞춰 보면 문제가 프록시 연결 전인지, 인증 이후인지 파악하는 데 도움이 됩니다.

TUN과 시스템 프록시 설정을 확인하세요

브라우저마다 결과가 다르거나 전역 모드와 규칙 모드의 차이가 설명되지 않는다면, 운영체제와 Clash가 트래픽을 가로채는 방식이 일치하는지 확인합니다. 일반적인 시스템 프록시 방식은 운영체제 프록시 설정을 따르는 앱에 적용됩니다. 반면 TUN 모드는 가상 네트워크 인터페이스를 통해 더 넓은 범위의 트래픽을 처리할 수 있지만, 권한, 드라이버, 다른 VPN과의 충돌, 클라이언트별 코어 지원 상태에 영향을 받습니다. TUN을 켰다는 표시만으로 Grok 요청이 반드시 해당 경로를 탄다고 단정하지 말고, 실제 연결 로그와 시스템 설정을 대조하세요.

먼저 Clash의 시스템 프록시가 활성화되어 있는지, 운영체제의 프록시 주소와 포트가 현재 클라이언트 설정과 맞는지 확인합니다. 다른 프록시 앱이나 VPN이 동시에 실행 중이라면 테스트 동안 하나만 남겨 경로를 단순하게 만들되, 조직이 관리하는 네트워크 구성은 임의로 해제하지 마세요. TUN을 사용하는 경우에는 관리자 권한이나 시스템 확장 승인이 필요한지, 클라이언트 화면에 오류가 표시되는지, 코어가 실제로 실행 중인지 점검합니다. 설정을 바꿨다면 클라이언트와 브라우저를 재시작해 새 연결로 결과를 확인합니다.

특히 TUN과 시스템 프록시를 동시에 바꾸면 개선된 이유를 알 수 없게 됩니다. 처음에는 현재 방식을 확인하고, 시스템 프록시만 점검한 뒤 결과를 기록합니다. 다음으로 승인된 환경에서 TUN을 별도로 시험해 로그와 브라우저 결과가 어떻게 달라지는지 비교하세요. 문제가 해결되면 불필요한 경로를 중복 활성화하지 말고, 평소 사용하는 설정을 명확히 정리해 둡니다.

설정 문제와 Grok 서비스 장애를 구분하세요

여러 노드와 브라우저에서 같은 시각에 실패하고, 연결 로그에는 프록시 연결이 성립한 흔적이 있는데 페이지나 응답만 계속 멈춘다면 서비스 측 장애나 계정 문제도 고려해야 합니다. 반대로 로그에 특정 호스트의 DNS 실패, 연결 거부, TLS 오류가 반복된다면 로컬 네트워크나 프록시 경로를 더 살펴볼 근거가 있습니다. 오류 메시지 하나만으로 어느 쪽인지 확정하지 말고, 실패 단계와 다른 서비스의 접속 결과를 함께 비교하세요.

문제를 기록할 때는 계정 정보, 인증 토큰, 구독 URL처럼 민감한 내용은 공유하지 마세요. 지원을 요청해야 한다면 오류 시각, 사용한 클라이언트와 코어 종류, 재현 단계, 민감 정보를 제거한 로그 일부를 준비합니다. Clash 설정 전체를 공개하는 대신 관련 규칙과 호스트만 익명화해 전달하면 불필요한 노출을 줄일 수 있습니다. 일시적인 서비스 장애라면 규칙을 무작정 추가하거나 DNS 설정을 반복해서 바꾸기보다 잠시 기다린 뒤 같은 조건으로 재시험하는 편이 안전합니다.

오래된 GUI나 관리가 중단된 클라이언트는 TUN 지원, 코어 업데이트, 로그 표시 방식이 현재 환경과 맞지 않아 원인 확인이 번거로울 수 있습니다. 반면 Clash V.CORE는 클라이언트와 코어의 동작 상태를 점검하면서 정책 그룹, 연결 로그, 시스템 프록시와 TUN 설정을 한 흐름으로 확인하는 데 도움이 됩니다. 현재 사용하는 도구가 업데이트되지 않아 로그 확인이나 연결 모드 비교가 어렵다면, 필요한 기능과 운영체제 호환성을 살펴본 뒤 다운로드 페이지에서 Clash V.CORE를 확인해 보세요.