v2rayN으로 커널 시작에 실패했거나 로그에 bind 또는 address already in use가 표시되고 브라우저 프록시가 갑자기 작동하지 않는 Windows 사용자를 위한 안내입니다. 실패한 수신 주소와 프로토콜을 확인하고, 포트를 점유한 PID를 찾은 다음 중복 실행된 v2rayN인지 잔류 커널인지 다른 프로그램인지 판단합니다. 충돌 프로세스를 안전하게 종료할 수 없을 때만 포트를 변경하고, 시스템 프록시·브라우저·터미널·기타 수동 프록시 설정도 함께 수정합니다.
먼저 실패한 대상이 원격 노드가 아닌 로컬 수신인지 확인
v2rayN은 구독, 노드, 라우팅과 시스템 프록시 상태를 관리하는 그래픽 클라이언트입니다. 실제로 설정을 읽고 연결을 처리하는 것은 프록시 커널입니다. 시작할 때 커널은 Windows 로컬 컴퓨터에서 127.0.0.1:10808처럼 수신 주소를 하나 바인딩해야 합니다. 브라우저나 터미널이 이 진입점으로 요청을 보내면 커널이 라우팅 규칙에 따라 직접 연결할지 프록시를 사용할지 결정합니다.
포트가 다른 프로세스에 이미 점유되어 있으면 커널은 보통 로컬 인바운드를 만드는 단계에서 중단됩니다. 이때 VMess, VLESS 노드를 바꾸거나 구독을 갱신해도 원격 서버에 연결하기 전에 발생한 충돌이므로 포트가 해제되지 않습니다. 먼저 v2rayN의 핵심 로그에서 listen, bind, 로컬 주소와 포트 번호가 포함된 줄을 확인해야 합니다.
오류: listen tcp 127.0.0.1:10808: bind: Only one usage of each socket address is normally permitted.
원인과 해결 방법: TCP 포트 10808을 다른 프로세스가 이미 수신 중입니다. 먼저 PID로 프로세스를 확인하세요. 중복 실행된 클라이언트나 잔류 커널이라면 해당 프로세스를 정상 종료한 뒤 다시 시작합니다.
오류: failed to listen on address: 127.0.0.1:10809
원인과 해결 방법: 커널이 지정된 로컬 인바운드를 만들지 못했습니다. 10809의 TCP 및 UDP 점유 상태를 확인하고, 설정에 동일한 주소·포트·전송 프로토콜을 사용하는 인바운드가 두 개 없는지 확인하세요.
오류: listen tcp 0.0.0.0:10808: bind: address already in use
원인과 해결 방법: 프로그램이 모든 로컬 네트워크 인터페이스에서 10808을 수신하려 하면서 기존 수신과 겹쳤습니다. 로컬 컴퓨터에서만 사용할 경우 127.0.0.1에 바인딩해야 하는지 확인하세요. 충돌을 피하려고 수신 범위를 넓히지 마세요.
Windows에서 포트를 점유한 PID 찾기
먼저 로그에 표시된 포트 번호를 적어 두세요. 항상 10808이라고 단정하지 마세요. 설정마다, 이전 버전에서 마이그레이션된 결과마다, 사용자가 변경한 기록마다 포트가 다를 수 있습니다. 아래에서는 TCP 10808을 예로 듭니다. 로그에 10809나 다른 숫자가 표시되면 명령의 포트를 실제 값으로 바꾸세요.
방법 1: PowerShell 사용
PowerShell을 열고 다음 명령을 실행하세요. State Listen은 결과를 수신 중인 TCP 포트로 제한하고, OwningProcess는 포트를 점유한 프로세스의 PID를 표시합니다.
Get-NetTCPConnection -LocalPort 10808 -State Listen |
Select-Object LocalAddress, LocalPort, State, OwningProcess
Get-Process -Id 14632 |
Select-Object Id, ProcessName, Path두 번째 명령의 14632는 예시 PID일 뿐이므로 첫 번째 명령에서 실제로 반환된 OwningProcess 값으로 바꿔야 합니다. 일반 창에서 프로세스 경로가 보이지 않으면 관리자 권한으로 PowerShell을 다시 열 수 있지만, 이름이 비슷하다는 이유만으로 시스템 서비스를 강제 종료하지 마세요.
방법 2: 명령 프롬프트 사용
netstat은 비교적 오래된 Windows 환경에서 빠르게 조회할 때 유용합니다. -a는 수신 항목을 표시하고, -n은 주소를 숫자로 유지하며, -o는 PID를 표시합니다.
netstat -ano | findstr ":10808"
tasklist /FI "PID eq 14632"127.0.0.1:10808이 표시되고 상태가LISTENING이면 로컬 루프백 주소의 TCP 포트를 어떤 프로세스가 점유하고 있다는 뜻입니다.0.0.0.0:10808이 표시되면 해당 프로세스가 모든 로컬 IPv4 인터페이스에서 수신 중이라는 뜻입니다. 따라서 다른 프로그램이127.0.0.1:10808에 바인딩할 수도 없습니다.TIME_WAIT만 표시되는 경우에는 보통 프로그램이 계속 수신 중이라는 뜻이 아닙니다.LISTENING항목과 해당 PID를 계속 찾아보세요.- 인바운드에 UDP가 필요하다면
Get-NetUDPEndpoint -LocalPort 10808도 실행하세요. TCP 조회 결과가 없다고 해서 UDP 충돌이 없다는 의미는 아닙니다.
중복 실행, 잔류 커널, 다른 프로그램의 충돌 구분
PID를 찾은 뒤에는 프로세스의 정체에 따라 처리 방법이 달라집니다. 가장 흔한 원인은 포트 자체의 고장이 아니라 같은 클라이언트가 두 번 실행되었거나, 이전 종료 후 커널이 계속 실행 중이거나, 다른 로컬 프록시 도구나 개발 서비스가 우연히 같은 포트를 선택한 경우입니다.
먼저 작업 표시줄의 알림 영역과 작업 관리자를 확인하세요. v2rayN은 주 창을 닫아도 알림 영역에 남을 수 있으므로 프로그램을 다시 더블클릭했다고 해서 인스턴스가 하나뿐이라는 뜻은 아닙니다. 알림 영역 메뉴에서 먼저 정상 종료한 뒤 연결된 커널 프로세스도 종료되었는지 확인하세요. 강제 종료는 인터페이스가 응답하지 않고 PID의 정체를 확인한 경우에만 사용해야 합니다.
| 조회 결과 | 일반적인 원인 | 권장 처리 |
|---|---|---|
| 다른 v2rayN 프로세스 | 중복 실행되었거나 이전 인스턴스가 알림 영역에서 계속 실행 중 | 하나의 인스턴스만 남기고 클라이언트 메뉴에서 나머지를 정상 종료한 뒤 커널을 다시 시작 |
| 독립 커널 프로세스 | 클라이언트가 비정상 종료된 후 연결된 커널이 함께 종료되지 않음 | 프로세스 경로와 시작 시간을 확인하고 소속을 확인한 뒤 잔류 프로세스 종료 |
| 다른 프록시 또는 네트워크 도구 | 두 프로그램이 동일한 로컬 수신 포트로 설정됨 | 어느 프로그램이 기존 포트를 사용할지 결정하고 다른 프로그램에는 사용하지 않는 포트 지정 |
| 개발 서비스 또는 로컬 디버깅 프로그램 | 서비스가 우연히 10808, 10809 또는 사용자 지정 포트를 수신 중 | 작업 중인 프로세스를 무작정 종료하지 말고 의존성을 확인한 뒤 한쪽 설정 변경 |
| 동일한 설정의 두 인바운드 | 수동 설정에서 SOCKS, HTTP 또는 혼합 인바운드가 같은 엔드포인트를 사용 | 생성된 설정과 사용자 지정 설정을 확인해 주소·포트·프로토콜 조합이 중복되지 않도록 처리 |
- 로그에 표시된 수신 주소, 포트와 TCP 또는 UDP 유형을 기록하세요.
- PowerShell 또는
netstat으로 PID를 찾고 프로세스 이름, 경로와 시작 시간을 확인하세요. - 중복 인스턴스라면 먼저 정상 종료하세요. 업무용 프로그램이라면 영향을 먼저 평가하고 바로 강제 종료하지 마세요.
- v2rayN의 커널을 다시 시작한 뒤 포트를 재조회하여 PID가 현재 커널 프로세스로 바뀌었는지 확인하세요.
충돌 프로세스를 해제할 수 없을 때 수신 포트 변경
점유 프로세스가 반드시 유지해야 하는 서비스이거나 두 프록시 환경을 동시에 실행해야 한다면 v2rayN의 로컬 수신 포트를 변경할 수 있습니다. 먼저 PowerShell에서 후보 포트가 비어 있는지 조회하세요. 예를 들어 10818을 사용하려면 TCP와 UDP를 각각 확인합니다.
Get-NetTCPConnection -LocalPort 10818 -ErrorAction SilentlyContinue
Get-NetUDPEndpoint -LocalPort 10818 -ErrorAction SilentlyContinue두 명령에서 결과가 나오지 않는다는 것은 조회 시점에 해당 엔드포인트가 발견되지 않았다는 뜻일 뿐, 영구적으로 예약되었다는 의미는 아닙니다. 그런 다음 v2rayN의 “설정” → “매개변수 설정”에서 로컬 수신, SOCKS, HTTP 또는 혼합 프록시 포트 항목을 찾으세요. 인터페이스 버전에 따라 필드 이름이 조금 다를 수 있으므로 현재 화면과 생성된 설정을 기준으로 판단하세요. 원격 노드 포트를 로컬 수신 포트로 바꾸지 마세요.
- 기존 포트(예: 10808)를 기록해 두면 되돌리거나 여전히 이전 값을 참조하는 애플리케이션을 찾기 쉽습니다.
- 사용하지 않는 새 포트(예: 10818)를 선택하세요. 포트는 1에서 65535 사이여야 합니다.
- “설정” → “매개변수 설정”에서 변경 사항을 저장하고 프록시 커널을 다시 시작하여 새 인바운드 설정을 적용하세요.
Get-NetTCPConnection -LocalPort 10818 -State Listen을 실행하여 새 포트가 현재 커널에서 수신 중인지 확인하세요.- 10808도 다시 조회하여 이전 수신이 사라졌는지 확인하세요. 변경에 성공했다고 생각했지만 실제로는 이전 인스턴스가 계속 서비스를 제공하는 상황을 피할 수 있습니다.
변경 후에도 오류 발생: listen tcp 127.0.0.1:10818: bind
원인과 해결 방법: 새 포트도 이미 점유되었거나 다른 v2rayN 인스턴스가 동일한 설정을 읽고 있습니다. 10818의 PID를 다시 조회하고, 프로세스 확인을 건너뛴 채 포트만 연속으로 바꾸지 마세요.
변경 후 오류는 없지만 브라우저 연결이 거부됨
원인과 해결 방법: 커널은 새 포트에서 수신 중이지만 브라우저나 확장 프로그램은 여전히 이전 포트를 가리키고 있습니다. 수동 프록시를 127.0.0.1:10808에서 실제 새 엔드포인트로 변경하세요.
수신 주소도 신중하게 다뤄야 합니다. 로컬 애플리케이션에서만 사용할 경우 일반적으로 루프백 주소 127.0.0.1을 유지해야 합니다. 주소를 0.0.0.0으로 바꾸는 것은 포트 점유 문제의 해결책이 아닙니다. 접근 가능한 범위가 달라지고 모든 인터페이스에서 수신하는 기존 프로그램과 계속 충돌할 수도 있습니다.
포트 변경 후 모든 프록시 진입점 동기화
커널의 수신 포트와 애플리케이션의 프록시 주소는 일치해야 합니다. v2rayN 매개변수를 변경해도 모든 브라우저 확장 프로그램, 터미널 환경 변수, 개발 도구와 가상 머신의 수동 설정이 자동으로 바뀌지는 않습니다. 시스템 프록시를 v2rayN이 관리한다면 시스템 프록시 상태를 다시 설정할 때 새 포트가 기록되는 경우가 많지만, 수동 설정을 사용하는 애플리케이션은 하나씩 수정해야 합니다.
SOCKS와 HTTP 유형도 구분해야 합니다. 둘 다 로컬에 있어도 같은 포트를 사용한다는 보장은 없습니다. HTTP 클라이언트를 SOCKS만 제공하는 포트로 지정하면 포트 점유가 아니라 연결 실패, 프로토콜 오류 또는 애플리케이션이 프록시를 우회하는 현상이 나타날 수 있습니다.
| 연결 지점 | 확인할 내용 | 변경 예시 |
|---|---|---|
| Windows 시스템 프록시 | 프록시 서버 주소와 포트를 v2rayN이 다시 기록했는지 확인 | 127.0.0.1:10808에서 127.0.0.1:10818로 변경 |
| 브라우저 개별 프록시 | 브라우저나 확장 프로그램이 시스템 프록시를 덮어쓰는지 확인 | 실제 진입점 유형에 맞춰 HTTP 또는 SOCKS 포트 변경 |
| 터미널 환경 변수 | HTTP_PROXY、HTTPS_PROXY、ALL_PROXY |
기존 터미널 창을 닫고 변수를 수정한 뒤 새 세션 열기 |
| 개발 및 다운로드 도구 | 애플리케이션 내부에 저장된 프록시 호스트, 포트와 프로토콜 | 이전 10808 참조를 삭제하고 다시 연결 |
| 로컬 네트워크 장치 | 정말 로컬 네트워크 접근이 필요한지와 해당 수신 주소 확인 | 먼저 접근 범위를 명확히 하고 수신 범위를 넓혀 포트 문제를 해결하려 하지 않기 |
set HTTP_PROXY=http://127.0.0.1:10818
set HTTPS_PROXY=http://127.0.0.1:10818
$env:HTTP_PROXY="http://127.0.0.1:10818"
$env:HTTPS_PROXY="http://127.0.0.1:10818"앞의 두 줄은 현재 명령 프롬프트 세션에 적용되고, 뒤의 두 줄은 현재 PowerShell 세션에 적용됩니다. 모두 HTTP 프록시 예시입니다. 실제 진입점이 SOCKS라면 애플리케이션이 지원하는 SOCKS 형식을 사용하고 해당 애플리케이션이 환경 변수를 인식하는지 확인하세요. 창을 닫으면 세션 범위 변수는 보통 유지되지 않습니다.
자주 묻는 질문과 놓치기 쉬운 범위
점유 프로세스를 종료했는데도 v2rayN에서 10808이 사용 중이라고 표시되는 이유는 무엇인가요?
포트 조회를 다시 실행하고 PID를 확인하세요. 백그라운드 서비스가 프로세스를 자동으로 다시 시작했거나 두 번째 v2rayN 인스턴스가 있을 수 있습니다. 먼저 알림 영역에 있는 중복 인스턴스를 종료한 뒤 TCP와 UDP 엔드포인트가 모두 해제되었는지 확인하세요.
10808을 10818로 바꾸면 구독도 다시 가져와야 하나요?
보통은 필요하지 않습니다. 구독에는 원격 노드와 관련 설정이 저장되고, 로컬 수신 포트는 클라이언트 연결 설정에 해당합니다. 변경 후 커널을 다시 시작하고 시스템 프록시와 수동 프록시 애플리케이션을 함께 수정하세요.
로그에 bind 오류가 없는데 웹 페이지가 열리지 않으면 어떻게 해야 하나요?
먼저 새 포트가 LISTENING 상태인지 확인한 다음 애플리케이션이 실제로 해당 포트를 사용하는지 점검하세요. 로컬 진입점이 정상일 때에만 노드 가용성, 라우팅 분기, DNS와 원격 TLS 설정을 계속 확인합니다.
시스템 프록시만 끄면 포트가 해제되나요?
그것만으로는 판단할 수 없습니다. 시스템 프록시 스위치는 일부 애플리케이션에 요청을 보낼 위치를 알려 줄 뿐이며, 커널이 계속 수신하는지는 실행 상태로 결정됩니다. 커널 또는 클라이언트를 종료하고 포트 명령으로 다시 확인하세요.
포트가 비어 있는데 시작하는 순간 다시 점유되는 이유는 무엇인가요?
두 인스턴스가 동시에 시작되었거나 백그라운드 프로그램이 조회 직후 먼저 바인딩했을 수 있습니다. 충돌 당시의 PID, 프로세스 경로와 시작 시간을 기록하면 포트를 무작위로 계속 바꾸는 것보다 원인을 찾기 쉽습니다.
Windows 방화벽 차단과 포트 점유는 서로 다른 문제입니다. 점유 오류는 커널이 로컬 바인딩 단계에서 실패했다는 뜻이고, 방화벽 규칙은 보통 연결이 통과할 수 있는지에 영향을 줍니다. 명확한 bind 또는 address already in use가 보이면 먼저 수신 충돌을 처리하고 방화벽을 끄는 것을 첫 번째 조치로 삼지 마세요.
TUN을 사용하면 애플리케이션 트래픽을 캡처하는 방식이 시스템 프록시와 달라지지만, 커널은 여전히 로컬 제어 포트, DNS 진입점 또는 다른 인바운드를 만들 수 있습니다. TUN을 활성화했다는 이유로 로그에 표시된 구체적인 수신 주소를 무시해서는 안 됩니다. 클라이언트를 막연히 다시 설치하지 말고 오류에 표시된 포트를 하나씩 확인하세요.
완료 후 검증 목록
문제 해결의 기준은 “오류 창이 사라졌다”가 아닙니다. 커널이 정상적으로 수신하고 애플리케이션이 올바른 진입점을 사용하며 이전 인스턴스가 기존 포트를 계속 점유하지 않아야 합니다. 다음 순서로 로컬 문제와 원격 노드 문제를 분리할 수 있습니다.
- 핵심 로그에
bind,address already in use또는 같은 의미의 수신 실패 기록이 더 이상 나타나지 않습니다. Get-NetTCPConnection에서 새 포트가Listen상태이고 PID가 현재 사용하는 프록시 커널에 해당합니다.- 기존 포트를 더 이상 사용하지 않는다면 잔류 커널이 계속 수신하고 있지 않은지 확인하세요. 다른 서비스가 사용 중이라면 그 용도를 기록합니다.
- Windows 시스템 프록시의 주소, 포트와 프로토콜이 v2rayN의 현재 수신 설정과 일치합니다.
- 브라우저 개별 프록시, 터미널 변수와 기타 수동 설정이 더 이상 이전 포트를 참조하지 않습니다.
- 먼저 하나의 애플리케이션으로 로컬 연결을 확인한 뒤 다른 애플리케이션을 점검하세요. 노드, 라우팅, DNS와 수신 포트를 동시에 변경하지 마세요.
- 로컬 수신은 정상이지만 원격 연결에 실패한다면 노드 주소, 프로토콜 매개변수, 시스템 시간, TLS와 라우팅 규칙을 확인하세요.
정리하면 포트 충돌은 “로그의 엔드포인트 → PID → 프로세스 정체 → 설정 진입점” 순서로 처리해야 합니다. 중복 실행과 잔류 커널은 먼저 프로세스를 종료하고, 반드시 유지해야 하는 다른 서비스와는 로컬 포트를 변경해 충돌을 피하세요. 포트가 바뀌면 실제로 프록시를 사용하는 애플리케이션에도 반드시 반영해야 합니다. 그렇지 않으면 커널은 정상적으로 시작되어도 브라우저와 터미널은 계속 작동하지 않는 이전 진입점에 접속합니다.