이 글의 목차
브라우저는 되지만 Cursor가 시간 초과된다면 네 가지 네트워크 경로를 구분하세요
Cursor에 Clash를 설정할 때 브라우저에서 웹페이지가 열린다는 사실만 입증해서는 안 됩니다. 계정 로그인, 모델 스트리밍 요청, MCP 하위 프로세스, 통합 터미널이 각각 연결을 시작하며 어떤 경로는 시스템 프록시를 읽고 다른 경로는 자체 환경 변수만 볼 수 있습니다.
실패 동작부터 찾기
| 실패 위치 | 관찰할 항목 |
|---|---|
| 로그인 또는 계정 페이지 | 리디렉션 후 HTTP 상태, 앱 진단, Clash Connections |
| 모델이 계속 Connecting / 요청 시간 초과 | Cursor Network Diagnostics, 고정 노드, 스트리밍 연결 |
| MCP 도구가 빨간색이거나 시작 실패 | 전송 유형, 프로세스 로그, mcp.json, 환경 변수 |
| 통합 터미널의 git / npm 시간 초과 | shell의 HTTP_PROXY / HTTPS_PROXY와 실제 포트 |
이후에는 현재 실패 중인 경로만 처리하세요. 결과를 비교할 수 있도록 Clash의 Proxies에서 노드를 고정하고 Rule 모드를 유지합니다. 요청 중 자동 그룹이 출구를 바꾸면 로그인, 다운로드, 긴 응답을 판단하기 더 어려워집니다.
시스템 프록시로 Cursor 기본 연결을 설정하세요
Cursor 기본 프록시 설정
Clash의 Proxies에서 노드 고정
사용 가능함을 확인한 구체적인 노드 하나를 선택하고 Rule 모드를 유지합니다.
Clash의 System Proxy 활성화
시스템 프록시가 현재 mixed-port를 가리키는지 확인하고 다른 프록시 클라이언트를 종료합니다.
Cursor를 완전히 종료한 뒤 다시 실행
새 Cursor 프로세스가 운영체제 프록시 설정을 다시 읽게 합니다.
Cursor의 Network 페이지 열기
Cursor Settings > Network로 이동해 앱의 내장 진단을 실행할 준비를 합니다.
이 단계는 Cursor에 명확한 시스템 프록시 시작점을 제공할 뿐입니다. 이어서 앱 내장 진단을 실행하고 결과를 Clash Connections와 대응시켜야 진입점, 노드, 계정 또는 MCP 자체의 문제인지 결정할 수 있습니다.
Network Diagnostics 결과에 따라 다음 진단 경로를 결정하세요
진단 결과별 다음 확인 방법
| 결과 | 다음 확인 위치 |
|---|---|
| 진단, 로그인, 모델이 모두 정상 | 기본 연결이 완료되었으므로 계속 실패하는 MCP 또는 터미널만 처리 |
| 진단 실패, Connections에 새 요청 없음 | Cursor가 시스템 프록시에 들어오지 않았으므로 TUN으로 비교 |
| 진단 실패, 요청이 고정 노드를 사용하고 timeout 발생 | 노드, 접속 네트워크, 연결 지속성 비교 |
| 진단 또는 로그인에서 401 / 403 / 429 반환 | 계정, 권한 또는 사용량 안내를 확인하고 프록시 포트를 계속 바꾸지 않음 |
Run Diagnostics를 실행할 때 실패 항목과 시각을 기록하고 같은 시각의 요청을 Connections에서 찾으세요. 이 대응 관계가 빨간 아이콘 하나만 저장하는 것보다 유용합니다. 이후 로그인과 모델 시험에서도 같은 고정 노드를 유지하세요.
Cursor 로그인이 실패하면 로그인 버튼 뒤의 리디렉션을 관찰하세요
Sign in을 클릭한 뒤 페이지가 열리지 않거나 이전 로그인 페이지로 돌아가거나 계속 기다린다면 고정 노드를 유지한 채 한 번 더 클릭하고 Connections를 확인하세요. 로그인 요청이 전혀 없다면 Cursor 앱이 현재 시스템 프록시에 들어오지 않은 것입니다. 요청이 나타났다면 timeout, 401, 403을 구분해 처리합니다.
401은 로그인 상태에 가깝고 403은 페이지의 계정 또는 지역 안내를 확인해야 하며 timeout일 때만 노드와 네트워크를 비교합니다. 로그인 중 자동 정책이 출구를 바꾸지 않게 하세요. 인증 페이지와 콜백 주소가 서로 다른 환경에서 와서 반복 리디렉션처럼 보일 수 있습니다.
Cursor 로그인 수정 완료 기준
- Sign in 리디렉션 요청이 Connections에 나타남
- 인증 페이지와 콜백이 같은 고정 출구를 사용함
- Cursor 계정 영역에 로그인됨으로 표시됨
- Cursor를 다시 시작해도 로그인 상태가 유지됨
로그인은 되지만 모델이 시간 초과되면 계정을 반복해서 초기화하지 마세요
로그인 성공은 인증 페이지 경로가 적어도 정상이라는 뜻입니다. 모델이 계속 Connecting, Network Error 또는 응답 중단 상태라면 모델 요청을 별도로 재현하세요. 짧은 질문으로 응답 시작 여부를 확인하고 조금 긴 질문으로 스트리밍 연결 지속성을 관찰하며 그동안 노드를 바꾸지 마세요.
Cursor 개발자 도구에서 요청 상태를 볼 수 있습니다. 명령 팔레트를 열어 Developer: Toggle Developer Tools를 실행하세요. 더 완전한 기록이 필요하면 Developer: Open Logs Folder를 실행합니다.
Request ID, 발생 시각, Cursor 버전을 기록하세요. 로그를 공유하기 전에 token, 코드 내용, 개인 경로를 삭제합니다.
짧은 응답은 성공하지만 긴 응답은 반복해서 중단됨
출구를 고정하고 다른 노드 및 네트워크와 비교해 스트리밍 연결 안정성을 확인하세요.
모델 요청이 401을 반환함
Cursor 로그인 상태 또는 관련 자격 증명을 확인하세요. 네트워크는 서비스에 도달했습니다.
진단과 모델 요청이 모두 timeout
Clash에 기록이 있는지 비교한 뒤 진입점과 노드 중 처리 대상을 결정하세요.
페이지가 429를 반환함
계정 사용량 또는 빈도 제한을 확인하고 프록시 포트를 계속 바꾸지 마세요.
Connections에 Cursor가 없다면 요청이 아직 Clash에 들어오지 않은 것입니다
시스템 프록시를 켠 뒤 Network Diagnostics를 다시 실행하세요. 브라우저 기록은 있지만 Cursor 기록이 계속 없다면 현재 버전 또는 특정 하위 프로세스가 시스템 프록시를 사용하지 않을 수 있습니다. 이때 TUN으로 더 많은 프로세스 트래픽을 Mihomo에 넣어 비교할 수 있습니다. TUN은 진입점만 해결하며 401, 403 또는 MCP 설정 오류는 고치지 못합니다.
TUN을 켠 뒤 같은 진단을 다시 실행하세요. Connections에 새 Cursor 요청이 나타나 성공하면 이전에는 시스템 프록시를 우회했던 것입니다. 기록은 나타나지만 계속 timeout이면 노드와 네트워크 경로로 돌아갑니다. 이 전후 비교가 여러 프록시를 장기간 동시에 켜는 것보다 신뢰할 수 있습니다.
진입점 전환 후 판단 항목
- 시스템 프록시에서 Cursor 요청이 Connections에 나타나는지
- TUN 활성화 후 같은 대상 연결이 새로 생기는지
- 새 연결이 DIRECT 또는 프록시 정책 중 어디에 맞는지
- 오류가 무기록에서 timeout으로 바뀌었는지 또는 사라졌는지
MCP는 transport부터 확인하세요. stdio와 원격 HTTP는 서로 다른 연결 방식입니다
Cursor는 로컬 stdio, SSE, Streamable HTTP 같은 MCP 전송을 지원합니다. stdio 서비스는 Cursor가 로컬 명령을 시작하므로 실행 파일, 매개변수, 환경의 정확성을 먼저 확인합니다. SSE 또는 Streamable HTTP에서만 원격 URL, 인증, 프록시 경로를 확인하세요.
프로젝트 설정은 보통 .cursor/mcp.json에 있고 전역 설정은 ~/.cursor/mcp.json에 있습니다. 수정 전에 어느 파일이 적용 중인지 확인해 프로젝트와 전역 파일에 같은 이름의 server가 정의되지 않게 하세요. JSON 구문 분석 통과는 문법이 맞다는 뜻일 뿐 서비스 프로세스 시작 여부는 MCP 로그에서 확인해야 합니다.
{
"mcpServers": {
"local-tool": {
"command": "/absolute/path/to/node",
"args": ["/absolute/path/to/server.js"],
"env": {
"HTTP_PROXY": "http://127.0.0.1:7890",
"HTTPS_PROXY": "http://127.0.0.1:7890",
"NO_PROXY": "localhost,127.0.0.1,::1"
}
}
}
}MCP의 "시작 실패"와 "도구 호출 시간 초과"를 구분하세요
- spawn ENOENT
- Cursor가 command를 찾지 못했습니다. 실행 파일의 올바른 경로를 사용하고 같은 환경에서 수동으로 실행하세요.
- JSON parse error
- mcp.json 구문 오류입니다. 쉼표, 따옴표, 객체 계층을 확인하세요.
- server exited
- 로컬 프로세스가 시작 후 종료되었습니다. stderr, 의존성, 작업 디렉터리를 확인하세요.
- HTTP 401 / 403
- 원격 MCP가 요청을 받았습니다. 인증과 서비스 권한을 확인하세요.
- tool call timeout
- 서비스는 연결되었지만 호출이 제시간에 완료되지 않았습니다. 서버 로그와 외부 의존성을 확인하세요.
수정 후 Cursor의 MCP 패널에서 서비스를 다시 불러오세요. 정상 상태는 녹색 표시만이 아니라 최소 도구 호출 하나를 완료하고 로그에서 요청과 응답을 확인하는 것입니다. 도구 내부에서 인터넷에 접근한다면 자체 프록시 환경도 필요합니다.
Cursor 터미널이 시간 초과되면 터미널에서 환경 변수를 검증하세요
통합 터미널은 shell 환경을 상속하며 Cursor 인터페이스의 네트워크 설정을 따르지 않을 수 있습니다. HTTP_PROXY, HTTPS_PROXY, NO_PROXY를 먼저 출력하고 curl로 시험 주소에 접속하세요. Clash Connections에 기록이 없다면 변수가 적용되지 않았거나 포트가 잘못된 것입니다.
CLASH_PORT=7890
export HTTP_PROXY="http://127.0.0.1:${CLASH_PORT}"
export HTTPS_PROXY="http://127.0.0.1:${CLASH_PORT}"
export NO_PROXY="localhost,127.0.0.1,::1"
curl -I https://example.comWindows PowerShell, Git, npm, 언어별 패키지 관리자가 프록시를 읽는 방식은 다를 수 있으므로 각 도구 문서에 따라 설정하세요. 프록시 자격 증명을 프로젝트 소스나 커밋 기록에 하드코딩하지 마세요. 포트는 현재 Clash 표시를 기준으로 하며 7890은 예시일 뿐입니다.
수정한 단계에서 당시 실패했던 동작을 다시 수행하세요
로그인 문제는 계정에 성공적으로 들어간 상태, 모델 문제는 응답 하나가 끝까지 완료된 상태, MCP는 실제 도구 호출 하나, 터미널은 기존에 실패한 git, npm 또는 curl의 결과를 기준으로 합니다. 네 항목을 함께 시험할 필요는 없지만 각 항목에는 자체 Connections 또는 로그 증거가 있어야 합니다.
모델은 안정적인데 특정 MCP에서 계속 spawn ENOENT가 난다면 이 가이드의 주요 경로에서 문제가 MCP 로컬 명령 계층으로 좁혀진 것입니다. command와 파일 경로만 확인하고 이미 작동하는 Cursor 네트워크 설정은 바꾸지 마세요.