Cursor Proxy 네트워크 문제 해결: 프록시 설정, 진단 및 HTTP/2 오류 수정

Cursor 편집기 오른쪽 아래에서 작은 원이 5분째 돌고 있습니다. 코드를 작성하던 중 AI 연결이 갑자기 끊기면서 “Network request failed”라는 메시지가 표시됩니다. 브라우저로 돌아가 보면 YouTube 영상은 매끄럽게 재생되고 Google ping 지연 시간도 20ms에 불과합니다.

다음 날 회사 내부 네트워크에서는 IT 부서가 여러 단계의 프록시를 설정해 둔 탓에 Cursor가 아예 실행을 거부했습니다. 오류 로그에는 ERR_HTTP2_PROTOCOL_ERROR, ECONNREFUSED, certificate verify failed가 줄줄이 나타났습니다. 하나씩 보면 익숙한데 함께 나오니 도무지 이해할 수 없었습니다.

꼬박 사흘 동안 GitHub Issues와 Discord 채널, 신뢰하기 어려운 각종 “궁극의 해결 방법”을 뒤진 끝에 알게 됐습니다. Cursor의 네트워크 문제는 단일 원인이 아니라 프록시, HTTP/2, 인증서, DNS라는 네 가지 함정이 겹쳐서 발생합니다.

이 글은 2026년 6월 Cursor 공식 문서를 기준으로 다시 검토했습니다. 이제는 먼저 Cursor Settings > Network의 진단 기능부터 실행한 다음 프록시, HTTP/2 호환 모드, 인증서, DNS를 차례로 처리합니다. 처음부터 시작 인수를 마구 바꾸지 말고 진단 결과를 통해 문제가 어디에 있는지 먼저 확인하세요.

또 하나 가장 놓치기 쉬운 부분이 있습니다. 프록시 주소를 제대로 입력했는데도 Cursor가 연결되지 않는 경우가 많습니다. 원인은 Cursor의 http.proxySupport 기본값이 override이기 때문입니다. 이 모드에서는 settings.json의 http.proxy만 사용하며 시스템 프록시는 완전히 무시합니다. 그런데 새로 설치한 환경에서는 이 항목이 기본적으로 비어 있습니다. 이 함정은 뒤에서 따로 설명하니 우선 기억해 두세요.

설정을 바꾸기 전에: 세 단계로 빠르게 원인 찾기

네트워크 문제가 생기면 곧바로 프록시를 변경하고 인증서를 삭제하거나 소프트웨어를 다시 설치하는 사람이 많습니다. 한참을 씨름해도 문제는 해결되지 않고 환경만 더 엉키기 쉽습니다.

제안하는 방법은 간단합니다. 먼저 5분만 투자해 정확히 어디에서 문제가 발생했는지 확인하세요.

1단계: Cursor 문제인지 네트워크 문제인지 확인하기

터미널을 열고 다음 세 명령을 입력합니다.

# 기본 네트워크 테스트
ping api.openai.com

# DNS 조회 테스트
nslookup api.openai.com

# HTTPS 연결 테스트
curl -I https://api.openai.com

ping은 성공하지만 curl이 실패한다면 열에 아홉은 프록시나 인증서 문제입니다. ping조차 실패한다면 Cursor가 아니라 네트워크 계층에 문제가 있습니다.

2단계: Cursor 오류 로그 확인하기

많은 사람이 이 단계를 건너뛰지만 실제로는 로그에 원인이 명확히 적혀 있습니다.

• Windows: %APPDATA%\Cursor\logs\main.log
• macOS: ~/Library/Application Support/Cursor/logs/main.log
• Linux: ~/.config/Cursor/logs/main.log

메모장으로 파일을 열고 ERROR 또는 WARN을 검색합니다. 자주 발생하는 오류는 다음과 같습니다.

• ECONNREFUSED → 프록시 설정이 잘못됐거나 프록시 서버가 중단됨
• ERR_HTTP2_PROTOCOL_ERROR → HTTP/2 프로토콜 비호환(가장 까다로운 문제)
• certificate verify failed → SSL 인증서 문제
• ETIMEDOUT → 시간 초과. DNS가 느리거나 네트워크가 차단됐을 수 있음

3단계: Cursor 프록시 설정이 적용되는지 테스트하기

Cursor는 Electron 기반이므로 프록시 설정이 시스템 프록시를 따르지 않아 별도로 설정해야 합니다. 테스트 방법은 다음과 같습니다.

1. Cursor 설정을 엽니다(Ctrl+, 또는 Cmd+,).
2. proxy를 검색합니다.
3. http.proxy와 https.proxy가 비어 있는지 확인합니다.

항목이 비어 있지만 로컬에서 프록시 소프트웨어(Clash, V2Ray, Shadowsocks)를 실행 중이라면 Cursor는 프록시를 전혀 사용하지 않는 것입니다. 연결되지 않는 것이 당연합니다.

Railway - 현대적인 배포 플랫폼, 번거로운 운영 없이 몇 분 만에 라이브

지금 시작 →광고

네 가지 프록시 설정 방법

프록시는 Cursor 네트워크 장애의 가장 흔한 원인입니다. 하지만 Cursor가 서로 다른 네 가지 프록시 설정 방식을 지원하며 각각의 용도가 완전히 다르다는 사실은 잘 알려져 있지 않습니다.

프록시 설정 전에 확인할 것: proxySupport가 override인가요?

로컬 프록시(Clash / V2Ray)를 계속 실행하고 있고 브라우저도 정상적으로 외부 사이트에 접속하는데 Cursor만 연결되지 않는다면 주소부터 입력하지 마세요. Cursor는 VS Code에서 물려받은 http.proxySupport 설정을 제공하며 네 가지 모드가 있습니다.

• off: 프록시를 전혀 사용하지 않음
• on: 항상 시스템 프록시를 읽음
• fallback: 먼저 settings.json의 http.proxy를 확인하고 비어 있으면 시스템 프록시로 전환
• override: settings.json의 http.proxy만 사용하고 시스템 프록시는 무시

문제는 http.proxySupport의 기본값이 override인데 http.proxy는 기본적으로 비어 있다는 점입니다. 두 조건이 겹치면 Cursor는 입력된 주소도 없고 시스템 프록시도 읽지 않아 완전히 직접 연결하게 됩니다. 로그인과 AI 요청이 모두 실패하는 이유입니다.

해결 방법은 간단합니다. 설정(Ctrl+,)을 열고 proxy support를 검색한 뒤 Http: Proxy Support를 override에서 on 또는 fallback으로 바꾸고 Cursor를 다시 시작합니다. Cursor가 시스템 프록시를 따르게 하는 것이 목적이라면 이 항목 하나만 바꿔도 해결되는 경우가 많습니다. 아래 네 가지 방법은 더 세밀한 제어가 필요할 때 사용하세요.

방법 1: 설정에 프록시 주소 직접 입력하기(가장 간단함)

적합한 상황: 회사에서 제공한 HTTP 프록시처럼 명확한 프록시 서버 주소가 있을 때

설정 순서:

1. Cursor 설정을 엽니다.
2. proxy를 검색합니다.
3. http.proxy에 http://127.0.0.1:7890을 입력합니다(실제 프록시 주소와 포트로 바꾸세요).

주의할 점:

• 프록시에 계정과 비밀번호가 필요하면 http://username:[email protected]:7890 형식으로 입력합니다.
• HTTPS 프록시도 https.proxy에 따로 입력해야 합니다. 그렇지 않으면 HTTP 요청만 프록시를 사용합니다.
• Clash의 기본 포트는 7890, V2Ray는 10808인 경우가 많으니 잘못 입력하지 마세요.

방법 2: 환경 변수(명령줄 실행에 적합)

적합한 상황: 터미널에서 Cursor를 실행하는 데 익숙하거나 프록시를 임시로 전환해야 할 때

Windows(PowerShell):

$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"
cursor

macOS/Linux:

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
cursor

이 방법은 전역 설정을 변경하지 않으며 터미널을 닫으면 적용이 해제된다는 장점이 있습니다.

방법 3: 시스템 프록시 자동 감지(기업 네트워크 권장)

적합한 상황: 회사 IT 부서에서 PAC 파일이나 투명 프록시를 설정한 경우

Cursor는 실제로 시스템 프록시를 읽을 수 있지만 기본적으로 비활성화돼 있습니다. 활성화하는 방법은 다음과 같습니다.

1. Cursor 시작 설정 파일을 찾습니다.

   • Windows: 바탕 화면 바로 가기를 마우스 오른쪽 버튼으로 클릭 → 속성 → 대상
   • macOS: /Applications/Cursor.app/Contents/Info.plist 편집

2. 시작 인수 --proxy-auto-detect를 추가합니다.

이제 Cursor가 시스템 프록시 설정을 자동으로 읽으므로 주소를 직접 입력할 필요가 없습니다.

방법 4: 인증서 오류 강제로 무시하기(권장하지 않지만 효과적임)

적합한 상황: 회사 프록시가 HTTPS 트래픽에 중간자 복호화를 적용해 인증서 검증이 실패할 때

중요 경고: 이 방법은 보안 수준을 낮추므로 임시로만 사용하세요!

시작 인수: --ignore-certificate-errors

전체 명령(Windows):

& "C:\Users\사용자이름\AppData\Local\Programs\Cursor\Cursor.exe" --ignore-certificate-errors

이 인수를 사용하면 Cursor가 SSL 인증서를 검증하지 않으므로 여러 기업 프록시 인증서 문제를 우회할 수 있습니다. 하지만 이는 마지막 수단이며 가능한 한 사용하지 않는 것이 좋습니다.

Alibaba Cloud - 개발자 클라우드 1순위, Lighthouse 서버 15% 할인

15% 할인 받기 →광고

HTTP/2의 함정: 브라우저에서는 되는데 Cursor에서는 안 되는 이유

브라우저에서 OpenAI API를 열면 정상이고 Curl 명령도 데이터를 제대로 반환하지만 Cursor에서만 ERR_HTTP2_PROTOCOL_ERROR 오류가 발생할 수 있습니다.

이런 문제를 곧바로 “버전 버그” 탓으로 돌리면 안 됩니다. 더 확실한 판단 방법은 먼저 Cursor의 Network 진단에서 HTTP/2 호환 문제가 있는지 확인한 뒤 HTTP/1.1로 전환해 테스트하는 것입니다.

우선 해결책: Cursor 설정에서 HTTP/2 호환 모드 전환하기

1. Cursor 설정을 엽니다.
2. Network 관련 설정으로 이동합니다.
3. Run Diagnostics를 실행합니다.
4. 진단이나 로그가 HTTP/2를 문제로 지목하면 Disable HTTP/2를 활성화하거나 HTTP Compatibility Mode를 HTTP/1.1로 변경합니다.
5. 창만 닫지 말고 Cursor를 완전히 종료한 뒤 다시 시작합니다.

매번 패널에 들어가기 싫다면 settings.json에 직접 다음과 같이 작성할 수도 있습니다.

{
  "cursor.general.disableHttp2": true
}

이는 공식 지원 설정이며 패널의 Disable HTTP/2와 같은 효과를 냅니다. 프록시 항목과 함께 관리할 수도 있습니다. 패널과 이 설정 키가 모두 없는 구버전에서만 시작 인수 cursor --disable-http2를 마지막 수단으로 사용하세요.

DNS 변경하기: HTTP/2 실패가 라우팅 문제일 때

일부 HTTP/2 오류는 Cursor가 아니라 DNS가 연결한 노드에서 발생합니다. 특정 DNS가 Cursor 인터페이스 도메인을 핸드셰이크 문제가 있는 Cloudflare 노드로 연결해 SSL handshake가 실패하는 경우입니다. 공식 포럼에서 여러 사용자가 시스템 DNS를 Cloudflare(1.1.1.1) 또는 Google(8.8.8.8)로 바꾼 뒤 HTTP/2가 바로 정상화됐다고 보고했습니다. HTTP/2를 끈 뒤 속도가 눈에 띄게 느려졌고 계속 HTTP/1.1을 쓰고 싶지 않다면 DNS를 먼저 바꾼 다음 HTTP/2를 다시 켜 보세요.

마지막 해결책: 프록시 소프트웨어 설정 수정하기(Clash 예시)

Clash 설정 파일(config.yaml)을 열고 프록시 규칙을 찾아 다음 내용을 추가합니다.

proxies:
  - name: "프록시 이름"
    type: http
    server: 127.0.0.1
    port: 7890
    http-version: "1.1"  # HTTP/1.1 강제 사용

변경 후 Clash와 Cursor를 다시 시작합니다. HTTP/2 문제가 프록시 경로의 협상 과정에서만 발생했다면 이 설정으로 요청이 안정되는 경우가 많습니다. 그래도 실패하면 시작 인수를 더 추가하지 말고 진단 보고서와 로그로 돌아가세요.

기업 네트워크를 위한 종합 해결 방법

회사 네트워크는 앞에서 설명한 문제가 모두 모여 있어 가장 까다롭습니다. 강제 프록시, SSL 중간자, 방화벽, 내부 DNS 중 어느 하나만으로도 Cursor가 작동하지 않을 수 있습니다.

기업 환경에서 확실하게 사용할 수 있도록 다음과 같은 설정 절차를 정리했습니다.

설정 체크리스트(순서대로 실행)

1. 회사 프록시 정보 확보하기

IT 부서에 다음 정보를 요청합니다.

• 프록시 서버 주소와 포트(예: proxy.company.com:8080)
• 계정과 비밀번호 필요 여부
• PAC 자동 설정 사용 여부
• SSL 복호화 여부(사용한다면 루트 인증서도 요청)

2. Cursor 프록시 설정하기

settings.json에 다음을 추가합니다.

{
  "http.proxy": "http://username:[email protected]:8080",
  "https.proxy": "http://username:[email protected]:8080",
  "http.proxySupport": "override",
  "http.proxyStrictSSL": false,
  "cursor.general.disableHttp2": true
}

몇 가지 사항에 유의하세요. http.proxy를 직접 입력했다면 http.proxySupport는 override를 사용하는 것이 가장 깔끔합니다. Cursor가 지정한 회사 프록시만 사용하도록 보장하기 때문입니다. SSL 중간자가 있다면 반드시 http.proxyStrictSSL: false를 추가해야 합니다. 기업 프록시는 HTTP/2를 차단하는 경우가 많으므로 cursor.general.disableHttp2를 true로 설정하면 진단 단계를 한 번 줄일 수 있습니다.

3. 회사 루트 인증서 가져오기

회사에서 SSL 복호화를 사용한다면 루트 인증서를 반드시 가져와야 합니다. 그렇지 않으면 Cursor에서 certificate verify failed 오류가 계속 발생합니다.

Windows:

1. 루트 인증서 파일(.crt 또는 .cer)을 두 번 클릭합니다.
2. “인증서 설치” → “로컬 컴퓨터” → “신뢰할 수 있는 루트 인증 기관”을 선택합니다.

macOS:

KiloClaw - 기업용 매니지드 OpenClaw, AI Agent 오케스트레이션 및 스마트 라우팅

시작하기 →광고

sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain 회사루트인증서.crt

4. 시작 인수 조합 추가하기

시작 스크립트를 만듭니다(Windows는 .bat, macOS/Linux는 .sh).

Windows(start-cursor.bat):

@echo off
set HTTP_PROXY=http://proxy.company.com:8080
set HTTPS_PROXY=http://proxy.company.com:8080
start "" "C:\Users\사용자이름\AppData\Local\Programs\Cursor\Cursor.exe" --proxy-auto-detect --disable-http2

macOS/Linux(start-cursor.sh):

#!/bin/bash
export HTTP_PROXY=http://proxy.company.com:8080
export HTTPS_PROXY=http://proxy.company.com:8080
/Applications/Cursor.app/Contents/MacOS/Cursor --proxy-auto-detect --disable-http2

이후에는 아이콘을 직접 클릭하지 말고 이 스크립트로 Cursor를 실행합니다.

5. 연결 테스트하기

실행 후 Cursor 개발자 도구(Ctrl+Shift+I 또는 Cmd+Option+I)를 열고 Network 탭으로 이동합니다. AI에 아무 질문이나 입력한 뒤 요청이 정상적으로 반환되는지 확인합니다.

여전히 작동하지 않는다면 앞에서 설명한 로그 파일로 돌아가 최신 오류 정보를 찾고 해당 진단 단계를 다시 확인하세요.

정리

길게 설명했지만 Cursor의 네트워크 문제는 결국 네 가지 원인으로 정리됩니다.

1. 프록시 미적용 → 먼저 http.proxySupport가 override인지 확인한 뒤 http.proxy와 환경 변수를 점검합니다.
2. HTTP/2 프로토콜 충돌 → Network 설정의 Disable HTTP/2 / HTTP Compatibility Mode: HTTP/1.1을 먼저 사용하고 필요하면 DNS를 바꿉니다.
3. SSL 인증서 검증 실패 → 루트 인증서를 가져오거나 임시로 검증을 끕니다.
4. 기업 네트워크 제한 → 프록시 + 인증서 + 시작 인수를 조합합니다.

저는 이 네 문제가 겹칠 수 있다는 사실을 몰라 사흘을 허비했습니다. 프록시를 고치면 HTTP/2 오류가 발생했고, HTTP/2를 끄면 인증서 문제가 나타났으며, 인증서를 가져오고 나니 DNS 조회가 실패했습니다. 매번 해결됐다고 생각했지만 오류 메시지만 바뀌었을 뿐입니다.

돌이켜 보면 처음부터 이 글의 순서대로 진단했다면 30분 안에 해결할 수 있었을 것입니다.

마지막으로 한마디만 하겠습니다. 오류 로그를 장식처럼 방치하지 마세요. 문제가 생길 때마다 로그에서 최신 ERROR를 먼저 찾으면 90%는 그 안에서 답을 얻을 수 있습니다. 나머지 10%를 해결하지 못하더라도 로그와 함께 GitHub Issues나 Discord에 질문하면 다른 사람도 훨씬 빨리 원인을 파악할 수 있습니다.

네트워크 문제 자체보다 무작정 설정을 바꾸는 것이 더 위험합니다. 이 글이 그 72시간을 아끼는 데 도움이 되기를 바랍니다.

공식 자료 및 다음 읽을거리

• Cursor 공식 네트워크 및 프록시 문제 해결 문서
• Cursor 공식 문서
• Cursor Pricing
• Cursor 자주 발생하는 오류 해결 가이드
• Cursor Pro 구독 완벽 가이드
• Cursor 무료 할당량 완벽 가이드