v2rayN 로컬 포트 사용 중일 때: 점유 프로세스 확인 및 10808 포트 변경

1. 10808 바인딩 실패: 리스닝 포트와 노드 포트 구분하기

v2rayN은 클라이언트 인터페이스이며, 로컬 프록시 리스닝은 보통 v2rayN이 실행한 프록시 코어가 담당합니다. 애플리케이션은 먼저 127.0.0.1:10808 같은 로컬 주소에 연결하고, 코어는 설정에 따라 아웃바운드 연결을 처리합니다. 로그에 나타나는 로컬 바인딩 실패는 이 진입 지점에서 발생하므로 구독에 등록된 원격 서버 포트부터 변경할 필요는 없습니다.

10808은 흔히 사용하는 로컬 리스닝 포트지만, 모든 버전의 인바운드 유형이 같다고 볼 수는 없습니다. 일부 인터페이스에서는 SOCKS와 HTTP 포트를 따로 설정하며, 구형 설정에서는 HTTP 포트로 10809를 사용하는 경우도 많습니다. 다른 인터페이스에서는 혼합 리스너 하나가 두 프록시 프로토콜을 모두 받습니다. 「설정」→「매개변수 설정」에 표시된 실제 항목과 시작 로그를 기준으로 확인하세요.

TCP와 UDP는 서로 다른 리스닝 리소스이며, IPv4와 IPv6의 바인딩 방식도 다를 수 있습니다. 0.0.0.0:10808 또는 [::]:10808이 보이면 와일드카드 리스닝이 루프백 주소의 리스너와 충돌할 수 있다는 점에 유의하세요. 127.0.0.1로 표시된 항목만 검색해서는 안 됩니다.

2. 오류 메시지로 포트 점유·권한 문제·연결 거부 구분하기

먼저 클라이언트 로그를 열고 실패 전후의 몇 줄을 저장하세요. listen, bind, 주소와 포트를 중점적으로 확인합니다. 코어마다 로그 접두어가 다를 수 있으므로, 아래는 운영체제 오류에서 흔히 보이는 문구이며 로그 전체가 정확히 일치할 필요는 없습니다.

3. Windows: PID로 10808 점유 프로세스 찾기

PowerShell에서 TCP 리스너를 조회한 다음 프로세스 정보를 확인하세요. 아래 명령은 정보만 조회하며 프로그램을 종료하지 않습니다. 결과가 비어 있으면 조회 시점에 해당 포트의 TCP 리스너를 찾지 못했다는 뜻입니다. 모든 프로토콜과 시스템 예약 여부까지 확인된 것은 아닙니다.

$listeners = Get-NetTCPConnection -LocalPort 10808 -State Listen -ErrorAction SilentlyContinue
$listeners | Select-Object LocalAddress, LocalPort, State, OwningProcess
$listeners.OwningProcess | Sort-Object -Unique | ForEach-Object {
    Get-Process -Id $_ | Select-Object Id, ProcessName, Path
}

명령 프롬프트에서 아래 명령을 실행해도 됩니다. 두 번째 줄의 1234는 예시 PID이므로 첫 번째 명령에서 실제로 확인한 PID로 바꿔야 합니다. 포트 번호 10808을 프로세스 ID로 입력하지 마세요. 결과를 필터링할 때는 원격 연결 기록을 잘못 읽지 않도록 로컬 주소 열도 확인하세요.

netstat -ano -p tcp | findstr ":10808"
tasklist /FI "PID eq 1234"

1. 리스닝 상태 확인: LISTENING을 우선 확인하세요. TIME_WAIT 기록만으로는 프로그램이 리스닝 중이라고 볼 수 없습니다.
2. 경로와 출처 확인: 작업 관리자의 「세부 정보」에서 PID를 대조하고, 필요하면 파일 위치도 확인하세요. 프로세스 경로를 조회하려면 관리자 권한이 필요한 경우가 있습니다.
3. 정상 종료 우선: 다른 v2rayN 인스턴스라면 해당 인스턴스의 트레이 메뉴에서 종료하세요. 창을 닫아도 트레이로 최소화되기만 할 수 있습니다.
4. 필요한 서비스 유지: 포트를 계속 사용해야 하는 프로그램이라면 v2rayN의 포트를 변경하세요. 프로세스 이름만 보고 시스템 서비스를 강제 종료하지 마세요.

TCP 조회 결과가 비어 있는데 오류가 UDP와 관련되어 있다면 Get-NetUDPEndpoint -LocalPort 10808 -ErrorAction SilentlyContinue로 추가 확인할 수 있습니다. 중복 인스턴스를 종료한 뒤에는 조회를 다시 실행하고, 사용할 클라이언트만 시작하세요. 두 인스턴스가 번갈아 포트를 점유하는 일을 막을 수 있습니다.

4. macOS와 Windows의 예약 포트: 점유 프로세스가 검색되지 않을 때

macOS: 리스너와 전체 명령 확인

터미널에서 다음 명령을 실행하세요. -nP는 숫자 주소와 포트를 그대로 표시해 이름 확인으로 인한 혼동을 줄입니다. 권한이 부족하면 sudo lsof로 다시 조회하세요. 두 번째 줄의 예시 PID도 실제 값으로 바꿔야 합니다.

lsof -nP -iTCP:10808 -sTCP:LISTEN
ps -p 1234 -o pid=,ppid=,command=

해당 앱 메뉴에서 먼저 종료한 다음 리스너 기록이 사라졌는지 확인하세요. 클라이언트를 종료했는데도 코어 프로세스가 남아 있다면 전체 명령과 부모 프로세스를 확인한 뒤, 이미 종료한 인스턴스에 속하는 것이 확실할 때만 조치하세요. 이름으로 여러 프로세스를 한꺼번에 종료하지 마세요. 현재 사용 중인 다른 설정도 같은 코어를 실행할 수 있습니다.

Windows: 포트 제외 범위 확인

액세스 권한 거부 오류가 발생하고 리스너도 검색되지 않는다면 터미널에서 TCP 제외 범위를 확인하세요. 10808이 출력된 시작·끝 범위에 포함된다면 시스템 예약 규칙을 변경하기보다 범위 밖의 사용 가능한 포트를 선택하는 편이 좋습니다.

netsh interface ipv4 show excludedportrange protocol=tcp
netsh interface ipv6 show excludedportrange protocol=tcp

5. SOCKS·HTTP 또는 혼합 리스닝 포트 변경

아래에서는 포트 변경 예시로 11808과 11809를 사용하지만, 이 포트가 항상 비어 있다는 뜻은 아닙니다. 앞서 사용한 조회 명령에서 10808을 대상 포트로 바꿔 먼저 확인하세요. 시스템에 관련 제외 범위가 있다면 대상 포트가 범위에 포함되지 않는지도 확인해야 합니다.

1. 되돌릴 수 있도록 기존 포트와 리스닝 주소, 현재 시스템 프록시 모드를 기록해 두세요.
2. v2rayN에서 「설정」→「매개변수 설정」을 열고 로컬 리스닝, SOCKS, HTTP 또는 혼합 포트 항목을 찾으세요. 메뉴 그룹 이름은 인터페이스 버전에 따라 다를 수 있습니다.
3. SOCKS와 HTTP 항목이 따로 있다면 각각 11808과 11809로 설정할 수 있습니다. 혼합 리스닝 항목만 있다면 해당 값을 11808로 변경하세요. 11809 항목이 있다고 임의로 가정하지 마세요.
4. 설정을 저장하고 인터페이스의 안내에 따라 코어나 클라이언트를 다시 시작한 뒤, 로그에 바인딩 실패가 계속 표시되는지 확인하세요.
5. 새 포트의 리스너를 다시 조회해 해당 PID가 이번에 시작한 코어의 것인지 확인한 다음, 애플리케이션 측 프록시 설정을 변경하세요.

로컬에서만 사용할 경우 루프백 주소로 리스닝하도록 유지하세요. 리스닝 주소를 0.0.0.0으로 변경하는 것은 포트 점유를 해결하는 일반적인 방법이 아니며, 접근 가능 범위가 넓어질 수도 있습니다. 사용자 지정 JSON 설정을 사용한다면 실제 적용 중인 inbounds를 확인하세요. 인터페이스 설정이 가져온 구성의 고정 포트를 덮어쓰지 못할 수 있습니다. 항목의 의미는 JSON 설정 안내서를 참고하세요.

6. 시스템 프록시·브라우저·명령줄 설정 함께 변경하기

코어가 새 포트에서 시작되어도 기존 프록시 설정이 모든 애플리케이션에서 자동으로 해제되거나 갱신되지는 않습니다. 시스템 프록시, 브라우저의 수동 프록시, 터미널 환경 변수는 서로 다른 설정이므로 각 애플리케이션이 실제로 사용하는 연결 경로를 하나씩 확인하세요.

• v2rayN 시스템 프록시: 트레이 메뉴의 「시스템 프록시」에서 먼저 시스템 프록시를 해제한 다음 「자동으로 시스템 프록시 설정」을 선택해 현재 설정을 다시 적용하세요. 완료 후에도 시스템에 실제로 적용된 포트를 확인해야 합니다.
• Windows: 「설정」→「네트워크 및 인터넷」→「프록시」로 이동해 수동 프록시 또는 설정 스크립트를 확인하세요. 스크립트를 사용한다면 수동 프록시 스위치만 보지 말고 스크립트가 반환하는 프록시 포트를 확인하세요.
• macOS: 「시스템 설정」→「네트워크」→현재 네트워크 연결→「세부사항」→「프록시」로 이동하세요. 웹 프록시, 보안 웹 프록시 또는 SOCKS 프록시를 수동으로 설정했다면 각각 해당하는 새 포트로 변경하세요.
• 브라우저: 시스템 프록시를 사용하는 브라우저는 보통 시스템 설정을 따릅니다. 별도 프록시 설정이나 확장 프로그램을 사용하는 브라우저는 해당 설정에서 포트를 변경하고 HTTP와 SOCKS5 중 올바른 프로토콜이 선택되었는지 확인하세요.
• 명령줄: 현재 터미널의 HTTP_PROXY, HTTPS_PROXY, ALL_PROXY와 소문자로 된 같은 이름의 변수를 확인하세요. 시작 스크립트를 수정해도 기존 터미널 세션에는 이전 값이 남아 있을 수 있습니다.

HTTPS 웹사이트에 로컬 HTTP 프록시로 접속할 때 프록시 주소는 보통 http://127.0.0.1:11809로 지정합니다. 웹사이트가 HTTPS라고 해서 로컬 프록시 진입점도 반드시 https://를 사용해야 하는 것은 아닙니다. 일반 시스템 HTTP 프록시를 SOCKS만 지원하는 리스닝 포트에 직접 연결할 수도 없습니다.

7. 포트 변경 후 확인 순서와 되돌리기 점검

먼저 로컬 리스닝을 확인하고, 다음으로 프록시 프로토콜을 점검한 뒤, 마지막으로 원격 연결을 확인하세요. 아래 두 명령은 개별 HTTP 인바운드와 SOCKS 인바운드의 예시입니다. 혼합 포트를 사용한다면 첫 번째 명령의 11809를 11808로 바꾸세요. 요청 예시는 이 사이트의 홈을 대상으로 하며, 응답 시간이나 상태 코드를 고정값으로 가정하지 않습니다.

curl --proxy http://127.0.0.1:11809 --connect-timeout 5 --max-time 20 -I https://v2rayindex.com/
curl --proxy socks5h://127.0.0.1:11808 --connect-timeout 5 --max-time 20 -I https://v2rayindex.com/

Windows PowerShell에서는 일부 환경에서 같은 이름의 별칭이 인수를 바꾸지 않도록 curl 대신 curl.exe를 사용할 수 있습니다. socks5h는 대상 도메인 이름을 프록시 서버에서 확인한다는 뜻입니다. 로컬에서 이름을 확인하는 socks5와 다르므로 테스트에 사용한 방식을 기록하세요.

• 새 포트에서 리스닝하지 않음: 클라이언트 로그를 다시 확인하고 설정이 저장되었는지, 코어가 시작되었는지, 사용자 지정 설정이 인터페이스 값을 덮어쓰는지 살펴보세요.
• 즉시 연결 거부: 포트와 주소부터 확인하세요. IPv4 루프백 주소에서만 리스닝하는 경우 localhost가 IPv6로 해석될 수 있으므로 테스트할 때는 127.0.0.1을 명시하세요.
• 프록시에는 연결되지만 원격 요청이 실패함: 로컬 바인딩 충돌이 더 이상 현재의 차단 원인이 아닐 가능성이 큽니다. 프록시 프로토콜, 라우팅, 도메인 이름 확인, 원격 연결 로그를 계속 점검하세요.
• 명령줄은 성공하지만 브라우저는 실패함: 브라우저가 아직 10808을 가리키는지, 별도 프록시 확장 프로그램을 사용하는지, 이전 시스템 프록시 설정이 남아 있는지 확인하세요.
• 클라이언트 사용을 잠시 중단할 때: 먼저 시스템 프록시를 해제한 다음 클라이언트를 종료하세요. 리스닝이 중단된 로컬 포트에 애플리케이션이 계속 접속하는 일을 막을 수 있습니다.