Cursor가 Clash에서 안 될 때 연결 시간 초과 해결법과 설정 가이드

Cursor만 연결 시간 초과가 발생하는 이유

Clash를 켠 상태에서 브라우저는 정상적으로 열리는데 Cursor만 로그인되지 않거나 AI 자동완성 요청이 계속 실패한다면, 노드 전체가 다운된 것보다 애플리케이션별 프록시 처리 차이를 먼저 의심해야 합니다. Cursor는 일반 웹페이지처럼 한 번의 HTTPS 요청만 보내는 것이 아니라 로그인, 라이선스 확인, 모델 목록 조회, 채팅 요청, 스트리밍 응답을 서로 다른 서버와 연결 방식으로 처리합니다. 따라서 브라우저 테스트가 성공했다는 사실만으로 Cursor의 모든 요청이 같은 경로를 사용한다고 판단할 수 없습니다.

특히 다음과 같은 메시지가 반복되면 연결 시간 초과, 잘못된 규칙 매칭, DNS 해석 실패, 노드 품질 저하가 주요 원인일 가능성이 큽니다.

• ETIMEDOUT, ECONNRESET, socket hang up처럼 연결 수립 또는 응답 대기 중 발생하는 오류
• 로그인 화면이 계속 로딩되거나 브라우저 인증 후 Cursor로 돌아왔을 때 세션이 반영되지 않는 현상
• AI 채팅은 열리지만 자동완성 요청만 실패하거나, 긴 응답을 받는 중 연결이 끊기는 현상
• Clash를 전역 모드로 바꾸면 작동하지만 규칙 모드에서는 Cursor만 실패하는 현상

이 문제를 확인할 때는 먼저 “인터넷이 되는가”가 아니라 “Cursor의 요청이 실제로 Clash에 들어오고, 올바른 정책 그룹을 통해 나가는가”를 확인해야 합니다. 브라우저에서 검색 페이지 하나가 열리는 것과 Cursor의 인증·API·스트리밍 연결이 모두 정상인 것은 서로 다른 테스트입니다.

5분 안에 확인할 기본 항목

설정을 크게 바꾸기 전에 현재 상태를 기록하면 원인을 훨씬 빠르게 좁힐 수 있습니다. Clash Verge, Clash Verge Rev, Mihomo 계열 클라이언트는 메뉴 이름이 조금 다르지만 프로필, 모드, 프록시 그룹, 로그라는 네 영역은 대부분 공통으로 제공합니다.

1. Clash의 프로필 페이지에서 현재 사용 중인 구성을 다시 선택합니다. 프로필을 다운로드하기만 하고 활성화하지 않으면 화면에 노드가 보여도 실제 규칙에는 반영되지 않을 수 있습니다.
2. 프록시 그룹에서 응답이 빠르고 만료되지 않은 노드를 직접 선택합니다. url-test 그룹이 비어 있거나 테스트 URL에 접근하지 못하면 자동 선택 결과가 잘못될 수 있으므로, 처음에는 자동 선택 대신 특정 노드를 고정하세요.
3. 모드를 잠시 전역(Global)으로 바꾼 뒤 Cursor를 완전히 종료하고 다시 실행합니다. 트레이 아이콘만 닫는 것으로 충분하지 않을 수 있으므로 작업 관리자나 활동 모니터에서 남은 프로세스도 확인합니다.
4. Clash 로그를 열고 Cursor를 실행한 직후 새로운 연결 기록이 생성되는지 확인합니다. 기록이 전혀 없다면 Cursor가 시스템 프록시를 사용하지 않거나, TUN이 꺼져 있어 해당 트래픽을 넘겨받지 못한 것입니다.
5. 브라우저에서 로그인 페이지와 일반 HTTPS 페이지를 각각 열어 노드 자체의 통신 상태를 비교합니다. 브라우저도 실패하면 Cursor 설정보다 노드, DNS, 구독 만료를 먼저 점검해야 합니다.

프록시 모드와 규칙을 올바르게 점검하기

규칙 모드에서는 도메인과 IP가 규칙 목록 위에서부터 아래로 비교되고, 첫 번째로 일치한 정책에서 처리가 끝납니다. Cursor 관련 요청이 해외 서비스용 프록시 그룹이 아니라 DIRECT로 매칭되면 브라우저의 국내 사이트는 정상이어도 Cursor만 시간 초과가 발생할 수 있습니다. 반대로 모든 트래픽을 프록시로 보내는 전역 모드에서 작동한다면 노드 자체보다는 규칙 분류에 문제가 있을 가능성이 높습니다.

규칙을 수정할 때는 짧은 키워드 하나로 광범위하게 잡기보다, 로그에 실제로 나타난 호스트명을 기준으로 정확한 도메인 또는 도메인 접미사 규칙을 작성하세요. 서비스의 호스트명은 클라이언트 버전과 기능에 따라 달라질 수 있으므로, 인터넷에서 복사한 오래된 도메인 목록을 그대로 붙여넣기보다 현재 로그를 기준으로 확인하는 편이 안전합니다.

# 실제 로그에서 확인한 호스트에 맞춰 작성하는 예시
DOMAIN-SUFFIX,cursor.com,AI-PROXY
DOMAIN-SUFFIX,cursor.sh,AI-PROXY
DOMAIN-SUFFIX,사용중인-API-도메인.example,AI-PROXY
MATCH,DIRECT

위 예시의 마지막 도메인은 설명을 위한 가짜 값이므로 그대로 사용하면 안 됩니다. 실제 설정에서는 Clash 로그에 표시된 대상만 넣고, 프록시 그룹 이름인 AI-PROXY도 현재 프로필에 존재하는 이름으로 바꿔야 합니다. 규칙을 추가한 뒤에는 프로필을 저장하고 재로드한 다음, 기존 연결을 끊기 위해 Cursor를 다시 시작하세요.

시스템 프록시와 TUN의 차이

시스템 프록시는 운영체제의 HTTP·HTTPS 프록시 설정을 따르는 애플리케이션만 처리합니다. Electron 기반 데스크톱 앱은 실행 시점에 프록시 설정을 읽거나 자체 네트워크 모듈을 사용할 수 있기 때문에, Clash에서 시스템 프록시를 켰는데도 모든 요청이 로그에 보이지 않을 수 있습니다. 이 경우 시스템 프록시를 켠 상태에서 Cursor를 완전히 종료한 뒤 재실행해야 하며, 이미 실행 중인 프로세스에는 새 설정이 적용되지 않을 수 있습니다.

TUN 모드는 가상 네트워크 인터페이스를 통해 시스템 프록시를 따르지 않는 TCP·UDP 연결까지 Clash가 넘겨받도록 합니다. Windows에서는 관리자 권한과 TUN 서비스 권한이 필요할 수 있고, macOS에서는 네트워크 확장 또는 VPN 구성 허용이 필요합니다. TUN을 켤 때는 시스템 프록시와 중복된 VPN 앱을 동시에 사용하지 말고, auto-route, DNS 가로채기, 출력 인터페이스 자동 감지 옵션이 현재 커널에서 지원되는지도 확인하세요.

DNS, 노드, 로그로 실패 지점 찾기

Cursor 도메인이 DNS에서 해석되지 않거나 잘못된 IP를 반환하면 규칙은 맞아도 연결이 시작되지 않습니다. Clash의 DNS가 활성화되어 있다면 fake-ip 또는 redir-host 모드와 실제 프로필의 설정을 확인하세요. fake-ip을 사용하는 환경에서는 특정 인증·개발 도구가 가상 주소와 호환되지 않을 수 있으므로, 문제가 계속되면 해당 도메인을 fake-ip-filter에 추가하거나 잠시 redir-host로 바꾸어 결과를 비교할 수 있습니다.

터미널에서 운영체제의 DNS 결과만 확인하면 Clash 내부의 결과와 다를 수 있습니다. 따라서 다음 명령은 참고용으로 사용하고, 최종 판단은 Clash 로그와 연결 기록을 함께 봐야 합니다.

nslookup cursor.com
# macOS / Linux
dig cursor.com
# Windows
ipconfig /flushdns

노드 문제도 자주 발생합니다. 구독에 표시된 노드가 모두 같은 서버를 가리키거나, 실제 대역폭이 소진되어 짧은 HTTPS 요청은 통과하지만 장시간 스트리밍 연결에서 끊길 수 있습니다. 노드 지연 시간이 80ms라는 표시만으로 품질을 보장할 수는 없습니다. 지연 측정은 특정 테스트 URL에 대한 왕복 시간일 뿐, Cursor의 인증 서버와 모델 API에 대한 TLS 연결 및 지속적인 응답 품질을 의미하지 않기 때문입니다.

• 자동 선택 그룹 대신 서로 다른 지역의 노드 2~3개를 차례로 직접 선택합니다.
• 각 노드에서 로그인, 짧은 채팅, 긴 응답을 나누어 테스트합니다.
• 한 노드에서만 실패하면 해당 노드의 라우팅·IP 평판·대역폭 문제로 판단합니다.
• 모든 노드에서 실패하면 규칙, DNS, 클라이언트 프록시 인식 문제를 다시 확인합니다.

Clash 로그에는 연결 대상, 매칭된规则, 사용된策略 그룹, 성공 또는 실패한 이유가 표시됩니다. 로그 레벨을 일시적으로 debug로 올려 테스트하되, 평소에는 info 수준으로 되돌리는 것이 좋습니다. 토큰이나 인증 헤더가 로그에 표시되는 클라이언트라면 화면을 캡처하거나 외부에 공유하지 마세요.

Cursor 내부 설정과 환경 변수 확인

Clash가 정상이어도 Cursor 내부 프록시 설정이나 운영체제 환경 변수가 잘못되어 있으면 연결이 실패합니다. Cursor 설정에서 프록시 관련 항목을 확인하고, 수동 프록시가 지정되어 있다면 주소와 포트가 현재 Clash의 mixed 포트 또는 HTTP·SOCKS 포트와 일치하는지 살펴보세요. 예를 들어 Clash가 로컬 HTTP 포트를 7890으로 열고 있는데 Cursor에 사용하지 않는 8080 포트가 입력되어 있으면 모든 요청이 즉시 시간 초과됩니다.

Windows, macOS, Linux의 셸 환경에 HTTP_PROXY, HTTPS_PROXY, ALL_PROXY가 남아 있는 경우도 있습니다. 이 값은 Clash의 시스템 프록시와 별도로 애플리케이션이나 하위 프로세스에 전달될 수 있습니다. 값이 오래된 포트나 다른 VPN을 가리키면 일시적으로 제거한 뒤 Cursor를 새로 실행해 결과를 비교하세요.

# Windows PowerShell
Get-ChildItem Env:HTTP_PROXY,Env:HTTPS_PROXY,Env:ALL_PROXY

# macOS / Linux
env | grep -i proxy

환경 변수를 확인할 때 실제 구독 주소나 인증 토큰을 명령어 결과와 함께 공유하지 마세요. 포트 번호와 변수 이름만 기록해도 충분합니다. 또한 Cursor를 업데이트한 직후 문제가 시작됐다면 이전 설정이 남은 것이 아니라 새 버전의 네트워크 동작이 바뀐 것일 수 있으므로, 설치된 버전과 Clash 커널이 최신 기능을 지원하는지 함께 확인해야 합니다.

권장 복구 순서

아래 순서는 설정을 무작정 초기화하지 않고 원인을 분리하는 방법입니다. 각 단계에서 결과를 기록하면 같은 문제를 반복해서 겪을 때도 복구 시간이 짧아집니다.

1. 다른 VPN과 프록시를 끄고 Clash만 실행합니다.
2. 브라우저에서 일반 HTTPS 접속을 확인한 뒤, Clash에서 특정 노드를 직접 선택합니다.
3. 모드를 전역으로 변경하고 Cursor를 완전히 종료한 다음 다시 실행합니다.
4. 전역 모드에서 성공하면 규칙 모드로 돌아가 Clash 로그에서 Cursor 관련 도메인의 실제 매칭 결과를 확인합니다.
5. 해당 도메인이 DIRECT 또는 잘못된 차단 정책으로 처리되면 정확한 DOMAIN이나 DOMAIN-SUFFIX 규칙을 프록시 그룹 앞쪽에 추가합니다.
6. 로그에 요청 자체가 없다면 시스템 프록시를 재설정하고, 그래도 보이지 않으면 관리자 권한으로 TUN을 활성화해 비교합니다.
7. 여러 노드에서 각각 짧은 요청과 긴 스트리밍 응답을 테스트해 노드 품질 문제인지 확인합니다.
8. 문제가 계속되면 DNS 모드, 시스템 시간, 보안 프로그램의 HTTPS 검사, Cursor 내부 수동 프록시와 환경 변수를 차례로 점검합니다.

복구 후에는 전역 모드를 계속 유지하기보다 필요한 도메인만 규칙으로 프록시 처리하는 방식을 권장합니다. 국내 개발 도구나 사내 주소까지 불필요하게 노드를 통과시키면 지연과 연결 실패가 늘어날 수 있습니다. 반대로 AI 서비스에 필요한 도메인을 지나치게 세분화하면 새 API 호스트가 추가될 때 다시 실패할 수 있으므로, 로그를 근거로 관리 가능한 범위의 접미사 규칙을 사용하는 것이 좋습니다.

자주 묻는 질문