이 글의 목차
편집기에 로그인할 수 있다고 모델 응답, 외부 도구, 터미널 명령이 모두 연결된 것은 아닙니다. 멈춘 것처럼 보일 때는 계정 페이지, 전체 응답, 도구 결과, 다운로드 중 무엇을 기다리고 있는지 확인하세요. 각 동작에 맞는 진단과 로그가 있으므로 프록시 설정을 한꺼번에 전부 다시 할 필요는 없습니다.
Cursor 로그인, 모델, MCP, 터미널을 각각 확인하는 방법
Cursor에서 실패한 동작만 다시 실행하고 Clash의 연결 기록과 대조하세요. 로그인, 모델 스트리밍 요청, MCP 하위 프로세스, 통합 터미널은 각각 연결을 만듭니다. 시스템 프록시를 쓰는 것도 있고 자체 환경 변수만 읽는 것도 있으므로 아래 표에서 해당 동작의 진단 위치를 찾으세요.
실패한 작업에 해당하는 설정 찾기
| 실패 위치 | 관찰할 항목 |
|---|---|
| 로그인 또는 계정 페이지 | 리디렉션 후 HTTP 상태, 앱 진단, Clash Connections |
| 모델이 계속 Connecting / 요청 시간 초과 | Cursor Network Diagnostics, 고정 노드, 스트리밍 연결 |
| MCP 도구가 빨간색이거나 시작 실패 | 전송 유형, 프로세스 로그, mcp.json, 환경 변수 |
| 통합 터미널의 git / npm 시간 초과 | shell의 HTTP_PROXY / HTTPS_PROXY와 실제 포트 |
시스템 프록시 설정 후 Cursor 재시작
Cursor 기본 프록시 설정
Clash의 Proxies에서 노드 고정
사용 가능함을 확인한 구체적인 노드 하나를 선택하고 Rule 모드를 유지합니다.
Clash의 System Proxy 활성화
시스템 프록시가 현재 mixed-port를 가리키는지 확인하고 다른 프록시 클라이언트를 종료합니다.
Cursor를 완전히 종료한 뒤 다시 실행
새 Cursor 프로세스가 운영체제 프록시 설정을 다시 읽게 합니다.
Cursor의 Network 페이지 열기
Cursor Settings > Network로 이동해 앱의 내장 진단을 실행할 준비를 합니다.
Settings > Network에서 진단 실행
진단 결과별 다음 확인 방법
| 결과 | 다음 확인 위치 |
|---|---|
| 진단, 로그인, 모델이 모두 정상 | 기본 연결이 완료되었으므로 계속 실패하는 MCP 또는 터미널만 처리 |
| 진단 실패, Connections에 새 요청 없음 | 진단을 다시 실행하고 시스템 프록시를 확인하세요. 브라우저에는 기록이 있지만 Cursor에는 여전히 없다면 TUN으로 비교하세요 |
| 진단 실패, 요청이 고정 노드를 사용하고 timeout 발생 | 노드, 접속 네트워크, 연결 지속성 비교 |
| 진단 또는 로그인에서 401 / 403 / 429 반환 | 계정, 권한 또는 사용량 안내를 확인하고 프록시 포트를 계속 바꾸지 않음 |
Run Diagnostics를 실행할 때 실패 항목과 시각을 기록하고 같은 시각의 요청을 Connections에서 찾으세요. 이 대응 관계가 빨간 아이콘 하나만 저장하는 것보다 유용합니다. 이후 로그인과 모델 시험에서도 같은 고정 노드를 유지하세요.
Sign in 후 페이지가 열리지 않거나 계속 리디렉션되거나 대기하는 경우
Sign in 후 페이지가 열리지 않거나 로그인 화면으로 돌아가거나 계속 기다리는 경우 같은 고정 노드로 다시 시도하고 실패 위치를 기록하세요. 외부 브라우저와 Cursor를 각각 확인하세요. 새 요청이 Connections에 없다면 요청을 보낸 프로그램이 현재 프록시를 사용하는지 먼저 확인하고 timeout, 401, 403에 따라 처리하세요.
401은 로그인 상태의 문제일 가능성이 더 높고, 403은 페이지의 계정이나 지역 안내를 확인해야 하며, timeout일 때는 노드와 네트워크를 비교합니다. 로그인 중에는 접속 경로를 고정하고 외부 인증 요청과 Cursor로 돌아오는 결과를 각각 확인하세요. 앱으로 돌아오는 동작이 반드시 프록시를 통해 원격 서비스에 접속하는 것은 아닙니다.
Cursor 로그인 수정 완료 기준
- Sign in 리디렉션 요청이 Connections에 나타남
- 로그인 인증을 마친 뒤 Cursor로 정상적으로 돌아오며 외부 요청은 동일한 고정 접속 경로를 사용함
- Cursor 계정 영역에 로그인됨으로 표시됨
- Cursor를 다시 시작해도 로그인 상태가 유지됨
Connecting 표시와 긴 응답 중단 확인
로그인 성공은 인증 페이지 경로가 적어도 정상이라는 뜻입니다. 모델이 계속 Connecting, Network Error 또는 응답 중단 상태라면 모델 요청을 별도로 재현하세요. 짧은 질문으로 응답 시작 여부를 확인하고 조금 긴 질문으로 스트리밍 연결 지속성을 관찰하며 그동안 노드를 바꾸지 마세요.
Cursor 개발자 도구에서 요청 상태를 볼 수 있습니다. 명령 팔레트를 열어 Developer: Toggle Developer Tools를 실행하세요. 더 완전한 기록이 필요하면 Developer: Open Logs Folder를 실행합니다.
Request ID, 발생 시각, Cursor 버전을 기록하세요. 로그를 공유하기 전에 token, 코드 내용, 개인 경로를 삭제합니다.
짧은 응답은 성공하지만 긴 응답은 반복해서 중단됨
출구를 고정하고 다른 노드 및 네트워크와 비교해 스트리밍 연결 안정성을 확인하세요.
모델 요청이 401을 반환함
Cursor 로그인 상태 또는 관련 자격 증명을 확인하세요. 네트워크는 서비스에 도달했습니다.
진단과 모델 요청이 모두 timeout
Clash에 이번 요청이 기록되는지 확인하세요. 기록이 없으면 앱 프록시를, 기록은 있지만 시간 초과가 나면 노드를 확인하세요.
페이지가 429를 반환함
계정 사용량 또는 빈도 제한을 확인하고 프록시 포트를 계속 바꾸지 마세요.
Connections에 Cursor가 없으면 TUN으로 비교
시스템 프록시를 켠 뒤 Network Diagnostics를 다시 실행하세요. 브라우저의 요청은 기록되지만 Cursor의 요청은 기록되지 않는다면 현재 버전이나 하위 프로세스가 시스템 프록시를 사용하지 않을 수 있습니다. TUN으로 비교하면 더 많은 프로세스의 트래픽을 Mihomo로 보낼 수 있습니다. TUN은 요청이 프록시에 들어오도록 도울 뿐 401, 403, MCP 설정 오류는 고치지 못합니다.
TUN을 켠 뒤 같은 진단을 실행하세요. Connections에 새 Cursor 요청이 나타나고 성공하면 이전에는 시스템 프록시를 우회했던 것입니다. 기록이 나타나도 timeout이면 노드와 접속 네트워크를 다시 확인하세요.
MCP 연결 방식: 로컬 stdio와 원격 HTTP
로컬 stdio에서는 Cursor가 명령을 실행하고 표준 입력과 표준 출력으로 통신합니다. SSE와 Streamable HTTP는 URL로 MCP 서비스에 연결하며 서비스는 로컬 또는 원격에서 실행될 수 있습니다. 전자는 실행 파일, 인수, 환경을 확인하고 후자는 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"
}
}
}
}spawn ENOENT, 해석 오류, 도구 호출 시간 초과
- spawn ENOENT
- Cursor가 command를 찾지 못했습니다. 실행 파일의 올바른 경로를 사용하고 같은 환경에서 수동으로 실행하세요.
- JSON parse error
- mcp.json 구문 오류입니다. 쉼표, 따옴표, 객체 계층을 확인하세요.
- server exited
- 로컬 프로세스가 시작 후 종료되었습니다. stderr, 의존성, 작업 디렉터리를 확인하세요.
- HTTP 401 / 403
- 원격 MCP가 요청을 받았습니다. 인증과 서비스 권한을 확인하세요.
- tool call timeout
- 서비스는 연결되었지만 호출이 제시간에 완료되지 않았습니다. 서버 로그와 외부 의존성을 확인하세요.
수정 후 Cursor의 MCP 패널에서 서비스를 다시 불러오세요. 정상 상태는 녹색 표시만이 아니라 최소 도구 호출 하나를 완료하고 로그에서 요청과 응답을 확인하는 것입니다. 도구 내부에서 인터넷에 접근한다면 자체 프록시 환경도 필요합니다.
통합 터미널의 환경 변수와 포트
통합 터미널은 shell 환경을 상속하며 Cursor 화면의 네트워크 설정을 따르지 않을 수 있습니다. HTTP_PROXY, HTTPS_PROXY, NO_PROXY를 출력해 현재 포트와 우회 대상을 확인한 뒤 curl로 요청을 반복하세요. 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 또는 로그 증거가 있어야 합니다.