Cursor 연결 안 될 때 해결법, Clash 네트워크 시간 초과 점검

먼저 Cursor와 Clash의 실패 계층 구분하기

Cursor가 실행되지만 로그인 화면이 계속 멈추거나 AI 코드 완성 요청이 시간 초과된다면, 애플리케이션 자체가 고장 났다고 단정하기 전에 네트워크 경로를 나누어 확인해야 합니다. Cursor는 데스크톱 앱, 로그인·인증 서버, 모델 API, 확장 기능과 업데이트 서버에 각각 연결할 수 있습니다. 따라서 웹 브라우저가 정상적으로 열리더라도 Cursor의 모든 기능이 정상이라는 뜻은 아닙니다. 반대로 Clash의 아이콘이 실행 중이어도 mihomo 코어가 실제로 포트를 열고 트래픽을 전달하고 있다는 보장도 없습니다.

일반적인 연결 과정은 네 단계로 나뉩니다. 먼저 Cursor가 도메인을 조회하고, 운영체제 또는 애플리케이션이 프록시 주소를 선택한 다음, Clash가 규칙에 따라 직접 연결 또는 프록시 연결을 결정합니다. 마지막으로 원격 서버와 TLS 세션을 만들고 요청과 응답을 주고받습니다. DNS 조회, 로컬 포트, 규칙 매칭, 원격 노드 중 하나만 실패해도 Cursor에는 timeout, network error, failed to fetch처럼 짧은 오류만 표시될 수 있습니다.

오류 메시지로 원인 범위 좁히기

• 로그인 페이지가 열리지 않음: 시스템 프록시가 꺼져 있거나 Cursor가 사용하는 인증 도메인이 잘못된 규칙으로 분류되었을 가능성이 있습니다.
• 로그인은 되지만 AI 응답만 시간 초과: 모델 API, 스트리밍 연결, WebSocket 또는 장시간 HTTPS 연결이 규칙이나 노드에서 차단되었을 수 있습니다.
• “Unable to connect”: 로컬 프록시 포트가 닫혀 있거나 Cursor가 존재하지 않는 프록시 주소를 사용하고 있을 수 있습니다.
• 인증서 또는 TLS 오류: 시스템 시간이 틀렸거나 HTTPS 가로채기, 보안 프로그램, DNS 변조가 연결에 개입했을 가능성이 있습니다.
• 잠깐 연결된 뒤 끊김: 노드의 패킷 손실, UDP·QUIC 제한, 프록시 서버의 유휴 연결 종료 또는 스트리밍 경로 불안정이 원인일 수 있습니다.

Clash 로컬 포트와 시스템 프록시 확인하기

Cursor 연결 문제에서 가장 흔한 원인은 Clash가 실행 중이지만 애플리케이션이 올바른 프록시 포트로 연결되지 않는 경우입니다. 설정 파일의 mixed-port가 7890이라고 해서 항상 해당 포트를 사용할 수 있는 것은 아닙니다. 다른 프로그램이 이미 포트를 점유했거나, 클라이언트가 설정을 적용하지 못했거나, 실제로는 HTTP와 SOCKS 포트를 별도로 열었을 수 있습니다.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090

mixed-port는 일반적으로 HTTP와 SOCKS5 요청을 함께 받을 수 있는 포트입니다. 반면 external-controller의 9090은 클라이언트가 코어 상태를 제어하는 API 포트이며, Cursor의 프록시 주소로 입력하면 안 됩니다. Cursor나 운영체제 프록시에는 보통 127.0.0.1:7890을 사용하지만, 실제 값은 FlClash의 현재 포트 화면과 실행 로그를 기준으로 확인해야 합니다.

시스템 프록시와 애플리케이션 프록시의 차이

Windows와 macOS의 시스템 프록시를 켜면 HTTP·HTTPS 프록시를 존중하는 대부분의 데스크톱 앱이 운영체제 설정을 읽습니다. 그러나 Electron 기반 앱은 버전과 실행 매개변수에 따라 자체 프록시 환경 변수를 우선하거나, 로그인 창과 확장 프로세스가 서로 다른 네트워크 경로를 사용할 수 있습니다. Cursor 설정에 프록시 항목이 있다면 시스템 프록시를 켠 뒤에도 별도 프록시가 지정되어 있는지 확인하세요.

• Clash에서 코어가 실행 중인지 확인하고 현재 수신 포트를 기록합니다.
• 운영체제의 HTTP·HTTPS 프록시 주소가 127.0.0.1인지 확인합니다.
• 프록시 포트가 실제 mixed-port와 일치하는지 확인합니다.
• Cursor에 수동 프록시가 설정되어 있다면 잘못된 이전 포트나 원격 주소를 제거합니다.
• 연결 테스트 중에는 시스템 프록시와 TUN을 동시에 무리하게 전환하지 않습니다.

Windows에서는 명령 프롬프트에서 다음과 같이 로컬 포트가 열려 있는지 확인할 수 있습니다. 포트가 열려 있다는 것은 수신 프로세스가 있다는 뜻일 뿐, 원격 연결이 정상이라는 의미는 아닙니다.

curl -I --proxy http://127.0.0.1:7890 https://example.com
curl -I --connect-timeout 10 https://example.com

첫 번째 명령은 Clash의 HTTP 프록시를 통한 요청이고, 두 번째 명령은 시스템 기본 경로를 통한 요청입니다. 첫 번째만 성공하면 Clash 경로는 작동하지만 운영체제 또는 Cursor가 프록시를 사용하지 않는 상태일 수 있습니다. 두 명령 모두 실패하면 DNS, 인터넷 회선, 노드 또는 방화벽을 함께 확인해야 합니다.

직접 따라 하는 Cursor 시간 초과 점검 순서

아래 순서는 설정 변경을 최소화하면서 실패 지점을 좁히는 방법입니다. 각 단계가 끝날 때 Cursor를 완전히 종료한 뒤 다시 실행하고, 로그인 또는 짧은 AI 요청을 한 번만 테스트하세요. 여러 노드를 반복해서 바꾸기보다 성공 여부와 Clash 로그의 변화를 기록하는 편이 정확합니다.

1. Clash 코어 상태 확인: FlClash 또는 사용하는 클라이언트에서 코어가 실행 중인지 확인합니다. 프로필이 선택되어 있고 mixed-port가 비어 있지 않은지 살펴봅니다.
2. 시스템 프록시 켜기: 우선 TUN을 끄고 시스템 프록시만 활성화합니다. Cursor가 이 경로를 사용하는지 확인하기 위한 가장 단순한 테스트입니다.
3. 기본 HTTPS 테스트: 브라우저에서 일반 HTTPS 사이트를 열고, 터미널에서는 curl을 사용해 127.0.0.1:7890 경유 요청을 확인합니다.
4. 로그 확인: Cursor에서 로그인이나 AI 요청을 시작하는 순간 Clash 로그를 관찰합니다. 요청 도메인이 전혀 보이지 않으면 Cursor가 프록시를 사용하지 않거나 로컬 연결 단계에서 막힌 것입니다.
5. 정책 그룹 확인: 관련 도메인이 REJECT, 빈 정책 그룹 또는 연결이 불안정한 노드로 들어가지 않는지 확인합니다.
6. 노드 교체: 같은 정책 그룹에서 다른 노드를 선택하고 다시 테스트합니다. 모든 노드에서 같은 방식으로 실패하면 노드보다 규칙·DNS·앱 프록시를 먼저 의심해야 합니다.
7. TUN을 마지막에 테스트: 시스템 프록시만으로 해결되지 않을 때 TUN을 켭니다. TUN을 켠 뒤에는 운영체제 라우팅, DNS 하이재킹, 가상 어댑터 권한이 추가 변수가 됩니다.

규칙 작성과 정책 그룹 점검

Cursor의 모든 도메인을 임의로 하나의 주소로 추측해 규칙에 넣는 것은 좋은 방법이 아닙니다. 로그인, 계정 인증, 모델 요청, 업데이트와 확장 마켓플레이스가 서로 다른 호스트를 사용할 수 있기 때문입니다. 먼저 Clash 연결 로그에서 실제 도메인과 최종 정책을 확인하고, 필요한 경우 해당 도메인을 서비스 정책 그룹으로 보냅니다. 규칙은 위에서부터 매칭되므로 너무 앞에 있는 DOMAIN-SUFFIX 또는 GEOSITE 규칙이 뒤의 예외 규칙을 무효화할 수 있습니다.

mode: rule
rules:
  - DOMAIN-SUFFIX,example.com,Cursor
  - MATCH,Proxy

위 설정의 도메인은 설명을 위한 예시입니다. 실제 구성에서는 Clash 로그에 표시된 도메인을 기준으로 추가해야 하며, 인증 토큰이 포함된 URL이나 개인 계정 정보를 규칙 파일과 함께 공유하지 마세요. 규칙을 수정한 뒤에는 코어 설정 검사를 실행하고, YAML 들여쓰기가 공백으로 유지되는지 확인해야 합니다.

로그에 요청이 기록되지만 연결 시간이 계속 초과된다면 정책 그룹의 노드 상태를 확인하세요. 지연 시간이 낮은 노드가 반드시 Cursor 스트리밍에 적합한 것은 아닙니다. 짧은 HTTP 측정은 빠르더라도 장시간 연결에서 패킷 손실이 발생할 수 있습니다. TCP 기반 노드와 QUIC 기반 노드를 각각 시험하고, AI 응답이 끝까지 전달되는지 비교하는 것이 더 실용적입니다.

DNS, TUN 및 보안 프로그램의 간섭 확인하기

Clash의 시스템 프록시는 애플리케이션의 HTTP 요청만 전달할 수 있지만, 일부 프로세스는 시스템 프록시를 무시하고 직접 DNS와 TCP 연결을 시도합니다. 이런 경우 TUN이 해결책이 될 수 있습니다. TUN은 가상 네트워크 인터페이스를 통해 시스템 트래픽을 코어로 넘기므로 프록시를 인식하지 않는 프로그램도 처리할 수 있지만, 권한과 라우팅 설정이 추가로 필요합니다.

TUN을 사용할 때는 먼저 시스템 프록시를 끄고 중복 경로가 생기지 않는지 확인하는 것이 좋습니다. 클라이언트에 따라 TUN 모드에서 자동 라우팅, 엄격한 라우팅, DNS 하이재킹 옵션의 이름이 다를 수 있습니다. 자동 라우팅을 켰는데도 특정 도메인만 실패한다면 DNS 모드와 nameserver-policy를 확인하세요. 직접 연결 DNS가 차단되거나 오염되면 올바른 IP를 얻지 못해 Cursor가 시간 초과를 표시할 수 있습니다.

• DNS 실패: 로그에 도메인 해석 실패 또는 no such host가 나타납니다.
• TUN 권한 실패: 가상 어댑터가 생성되지 않거나 TUN을 켜도 연결 로그가 증가하지 않습니다.
• 라우팅 충돌: TUN을 켠 뒤 모든 인터넷이 끊기거나 로컬 네트워크까지 프록시로 들어갑니다.
• 보안 프로그램 간섭: 백신, 기업용 방화벽, HTTPS 검사 기능이 Cursor 또는 mihomo의 TLS 연결을 차단할 수 있습니다.

기업 네트워크에서는 프록시 인증, TLS 검사 인증서, 도메인 허용 목록이 별도로 적용될 수 있습니다. 이 환경에서는 개인 장치에서 같은 설정을 반복하는 것보다 네트워크 관리자에게 Cursor 인증 및 API 도메인의 허용 여부를 문의해야 합니다. 인증서를 임의로 설치하거나 HTTPS 검사를 무조건 해제하는 방식은 계정 정보와 코드 데이터의 보안을 약화시킬 수 있으므로 피해야 합니다.

자주 묻는 질문