7897 혼합 포트 사용 중: 점유 프로세스 확인 및 수신 포트 변경

먼저 7897에서 수신이 실패했는지, 연결이 실패했는지 확인하세요

Clash Verge Rev의 혼합 포트는 mihomo 설정의 mixed-port에 해당합니다. 하나의 수신 포트에서 HTTP 프록시와 SOCKS5 프록시 연결을 모두 받을 수 있습니다. 이 글에서는 7897을 확인할 포트로, 7898을 변경 예시 포트로 사용합니다. 실제 값은 클라이언트 설정과 커널 로그를 기준으로 확인하세요. 예시 포트가 모든 설치 환경에서 동일하게 사용되는 것은 아닙니다.

포트 충돌은 로컬에서 수신 대기 소켓을 열 때 발생합니다. 클라이언트 창은 열리지만 커널 로그에 bind, address already in use 또는 Windows의 “일반적으로 각 소켓 주소는 한 번만 사용할 수 있습니다”라는 오류가 표시되는 경우가 대표적입니다. 구독 업데이트가 성공하고 노드 지연 시간이 정상이어도 로컬 프록시 포트가 작동한다는 뜻은 아닙니다.

listen tcp 127.0.0.1:7897: bind: address already in use

위는 흔히 볼 수 있는 오류 형식이며, 실제 로그의 접두사는 다를 수 있습니다. 먼저 ‘로그’ 페이지에서 7897과 bind를 검색한 다음 아래 표를 참고해 문제를 구분하세요. 모든 네트워크 오류를 포트 점유로 간주하지 않는 것이 중요합니다.

로그 또는 증상	우선 확인할 항목
address already in use	같은 주소와 포트를 사용하는 수신 프로세스 및 와일드카드 주소 수신
connection refused	앱이 연결하려는 주소와 포트에서 실제로 서비스가 수신 대기 중인지
access permissions / permission denied	시스템 예약 포트, 권한 제한 또는 보안 소프트웨어 정책
연결된 뒤 시간 초과 발생	로컬 포트뿐 아니라 노드, 규칙, DNS 및 대상 사이트

Windows: PowerShell로 수신 프로세스 확인

1단계: 로컬 수신 포트만 조회

PowerShell을 열고 아래 명령어를 실행하세요. 일반 터미널에서 전체 정보를 확인할 수 없다면 관리자 권한으로 다시 실행하세요. 이 명령은 로컬 포트와 Listen 상태만 필터링하므로, 원격 포트가 우연히 7897인 연결을 점유 상태로 잘못 판단하지 않습니다.

Get-NetTCPConnection -LocalPort 7897 -State Listen -ErrorAction SilentlyContinue |
  Select-Object LocalAddress, LocalPort, State, OwningProcess

OwningProcess 열에는 프로세스 ID인 PID가 표시됩니다. 실제 출력에 나온 숫자를 기록한 뒤 프로세스 이름과 경로를 확인하세요. 아래 예시는 수신 프로세스의 PID를 모읍니다. 변수는 $ownerPid를 사용하며, PowerShell 내장 변수인 $PID에는 값을 할당하지 마세요.

$owners = Get-NetTCPConnection -LocalPort 7897 -State Listen -ErrorAction SilentlyContinue |
  Select-Object -ExpandProperty OwningProcess -Unique

foreach ($ownerPid in $owners) {
  Get-Process -Id $ownerPid |
    Select-Object Id, ProcessName, Path
}

2단계: 다른 클라이언트 인스턴스인지 확인

mihomo 또는 다른 프록시 클라이언트가 표시되면 먼저 작업 표시줄 알림 영역과 작업 관리자를 확인하세요. 창을 닫아도 프로그램이 종료되지 않고 백그라운드에서 계속 실행될 수 있습니다. 서비스 모드에서는 시스템 서비스가 커널을 관리할 수도 있습니다. 프로세스 이름만 보고 강제 종료하지 말고 해당 클라이언트의 ‘종료’ 메뉴나 서비스 관리 기능을 사용하세요.

프로세스를 종료한 직후 새 PID로 다시 나타난다면 백그라운드 서비스나 실행기가 자동으로 다시 시작하는 경우가 많습니다. 프로세스를 반복해서 종료해도 충돌은 해결되지 않습니다. 해당 서비스를 중지하거나 두 프로그램에 서로 다른 포트를 지정하세요. 이름에 proxy, clash 또는 mihomo가 들어간 프로세스를 한꺼번에 종료하지 마세요.

수신 결과는 없는데 바인딩에 실패하는 경우

먼저 오류에 표시된 주소와 프로토콜을 확인하세요. IPv4의 0.0.0.0:7897은 모든 IPv4 인터페이스에서 수신한다는 뜻입니다. 로컬 네트워크 주소뿐 아니라 루프백 주소에서의 수신과도 충돌할 수 있습니다. 로그에 액세스 권한 오류가 명시되어 있다면 Windows의 TCP 제외 포트 범위를 확인하세요.

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

7897이 제외 범위에 포함되어 있다면 해당 범위 밖에 있고 다른 프로세스가 사용하지 않는 포트로 변경하는 것이 좋습니다. 프록시 포트 하나를 해결하려고 시스템 제외 항목을 직접 삭제하지 마세요. 가상화, 컨테이너 및 네트워크 구성 요소가 이러한 설정에 의존할 수 있습니다.

macOS 및 Linux: PID로 프로그램 확인

macOS: lsof로 TCP 수신 포트 확인

‘터미널’을 열고 아래 명령어를 실행하세요. -nP는 주소와 포트를 숫자로 표시하고, -sTCP:LISTEN은 수신 대기 소켓만 표시합니다. sudo를 사용하면 다른 사용자의 프로세스가 권한 부족으로 누락될 가능성을 줄일 수 있습니다.

sudo lsof -nP -iTCP:7897 -sTCP:LISTEN

출력의 COMMAND는 프로그램 이름, PID는 프로세스 ID, NAME은 수신 주소입니다. 전체 실행 명령을 확인하려면 조회한 PID를 입력한 다음 확인 명령을 실행하세요.

read -r owner_pid
ps -p "$owner_pid" -o pid=,user=,command=

이전 클라이언트의 프로세스임을 확인했다면 메뉴 막대에서 해당 프로그램을 종료하세요. 백그라운드 서비스가 실행한 프로세스라면 서비스의 출처를 확인한 뒤 중지해야 합니다. 시스템 프로세스나 출처가 불분명한 프로그램은 바로 종료하지 않는 것이 좋습니다. 대신 Clash Verge Rev의 포트를 사용 가능한 값으로 변경할 수 있습니다.

Linux: ss로 수신 포트와 프로세스 확인

터미널에서 아래 명령어를 실행하세요. -l은 수신 대기 소켓, -t는 TCP, -n은 숫자 형식, -p는 관련 프로세스를 표시합니다. 프로세스 상세 정보는 관리자 권한이 있어야 확인할 수 있습니다.

sudo ss -ltnp 'sport = :7897'

결과가 systemd로 관리되는 프록시 서비스라면 해당 서비스의 정상적인 중지 절차를 따르세요. 커널 프로세스만 종료하면 자동으로 다시 시작될 수 있습니다. 로그에 UDP 바인딩 충돌이 명시된 경우에만 UDP를 별도로 확인하세요. 같은 번호를 사용한다고 서로 다른 프로토콜의 포트를 같은 충돌로 간주해서는 안 됩니다.

sudo ss -lunp 'sport = :7897'

출력 없음: 현재 조회에서 해당 수신 소켓을 찾지 못했다는 뜻입니다. 포트를 계속 사용할 수 있다는 보장은 없으며, 다시 시작할 때 다른 프로그램이 먼저 포트를 열 수도 있습니다.
127.0.0.1에서 수신: 일반적으로 로컬에서만 사용됩니다. 충돌을 해결하기 위해 외부 인터페이스에 수신하도록 변경할 필요는 없습니다.
0.0.0.0 또는 [::]에서 수신: 와일드카드 주소를 사용합니다. IPv6 듀얼 스택 동작은 시스템과 소켓 옵션에 따라 달라지므로 실제 로그를 함께 확인하세요.

혼합 포트 변경: 7897에서 7898로

두 가지 방법이 있습니다. 더 이상 사용하지 않는 점유 프로그램을 종료하고 7897을 계속 사용하거나, 기존 프로그램은 유지한 채 Clash Verge Rev를 다른 빈 포트로 변경할 수 있습니다. 두 클라이언트를 동시에 사용해야 한다면 두 번째 방법이 간단하지만, 시스템 프록시 설정을 서로 반복해서 덮어쓰지 않도록 해야 합니다.

앞서 안내한 시스템 명령어로 7898을 조회해 해당 포트를 사용하는 수신 프로세스가 없는지 확인하세요. Windows에서는 제외 포트 범위에 포함되는지도 확인해야 합니다.
Clash Verge Rev를 열고 ‘설정’으로 이동한 다음 ‘Clash 설정’에서 ‘혼합 포트’ 항목을 찾으세요. 버전에 따라 설정 대화상자나 포트 설정 영역에 표시될 수 있으니, 화면에 표시된 ‘혼합 포트’라는 이름을 기준으로 찾으면 됩니다.
기존 값 7897을 7898로 변경하고 저장하세요. 커널을 재시작하라는 안내가 표시되면 지시에 따르세요. 그런 다음 ‘로그’ 페이지에서 새 수신 주소를 확인하세요.
7898의 수신 프로세스를 다시 조회해 현재 클라이언트가 사용하는 커널인지, 다른 프로세스인지 확인하세요.

mihomo YAML에서 해당하는 필드는 다음과 같습니다. 필드의 의미를 보여 주는 예시이며 구독 파일을 함께 수정할 필요는 없습니다.

mixed-port: 7898

Clash Verge Rev는 클라이언트 설정으로 구독의 공통 필드를 덮어쓸 수 있습니다. 따라서 다운로드한 YAML을 직접 수정해도 최종 수신 포트가 바뀌지 않을 수 있으며, 구독 업데이트로 수동 변경 사항이 덮어써질 수도 있습니다. 먼저 클라이언트의 설정 메뉴를 사용하고, 시작 로그와 운영체제의 수신 상태를 통해 적용된 값을 확인하세요. 오버라이드 설정을 관리하는 방법은 고급 설정을 참고하세요.

시스템 프록시, 터미널 변수 및 앱 설정 동기화

커널은 7898에서 수신하도록 변경했지만 앱은 여전히 7897에 연결하는 경우가 포트 변경 후 가장 흔히 빠뜨리는 부분입니다. 포트를 바꿀 때는 ‘수신하는 쪽’과 ‘사용하는 쪽’을 모두 확인해야 합니다. 클라이언트가 관리하는 시스템 프록시를 업데이트하더라도 브라우저 확장 프로그램, 터미널 환경 변수, 프록시를 수동으로 설정한 개발 도구까지 함께 변경되는 것은 아닙니다.

시스템 프록시 다시 적용

새 포트를 저장한 뒤 ‘설정’에서 ‘시스템 프록시’를 껐다가 다시 켜 클라이언트가 프록시 주소를 다시 설정하도록 하세요. 그런 다음 시스템 설정에서 값을 확인합니다. Windows 11은 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’, macOS는 ‘시스템 설정’ → ‘네트워크’ → 현재 네트워크 연결 → ‘세부사항’ → ‘프록시’입니다. Linux의 시스템 프록시 설정 위치는 데스크톱 환경에 따라 다르며, 일부 앱은 데스크톱 프록시 설정을 사용하지 않습니다.

로컬 프록시 주소는 보통 127.0.0.1을 사용하며 포트는 새 수신 포트와 일치해야 합니다. HTTP 및 HTTPS 대상 트래픽은 동일한 HTTP 프록시 포트를 통해 전달할 수 있습니다. 그렇다고 로컬 프록시 주소에 https://를 붙여야 하는 것은 아닙니다. 다른 클라이언트도 시스템 프록시를 설정하고 있다면 해당 기능을 먼저 끄세요. 그렇지 않으면 설정이 서로 덮어써질 수 있습니다.

터미널과 개발 도구는 별도로 확인

열려 있는 터미널에 이전 HTTP_PROXY, HTTPS_PROXY 또는 ALL_PROXY 값이 남아 있을 수 있습니다. 아래 명령어는 현재 터미널 세션에만 적용되며 시스템 설정을 영구적으로 변경하지 않습니다.

# macOS / Linux: 현재 셸 세션
export HTTP_PROXY=http://127.0.0.1:7898
export HTTPS_PROXY=http://127.0.0.1:7898
export ALL_PROXY=socks5h://127.0.0.1:7898

# Windows PowerShell: 현재 세션
$env:HTTP_PROXY = "http://127.0.0.1:7898"
$env:HTTPS_PROXY = "http://127.0.0.1:7898"
$env:ALL_PROXY = "socks5h://127.0.0.1:7898"

이 환경 변수를 사용하는지는 앱 자체의 구현에 따라 다릅니다. 브라우저 프록시 확장 프로그램, Git 프록시 설정, 편집기 네트워크 설정, 컨테이너 내부 환경 변수에는 각각 별도의 값이 저장되어 있을 수 있습니다. 브라우저만 다시 열지 말고 7897을 사용하는 항목을 하나씩 확인하세요.

TUN 모드는 혼합 포트와 다릅니다

TUN 모드는 가상 네트워크 인터페이스를 통해 트래픽을 처리하고, 혼합 포트는 앱이 직접 연결하는 로컬 프록시 포트입니다. mixed-port를 변경해도 TUN 경로나 DNS 설정은 자동으로 바뀌지 않습니다. 앱에 이전 프록시 포트가 직접 지정되어 있다면 TUN을 켜도 연결 오류가 계속될 수 있습니다. 포트 충돌을 해결하기 위한 방법으로 TUN을 켜지 마세요.

새 포트 확인: 먼저 수신 상태를 확인한 뒤 요청 테스트

검증은 단계별로 진행하세요. 먼저 해당 포트를 올바른 커널이 사용 중인지 확인한 다음, 프록시를 명시적으로 지정해 요청을 보냅니다. 웹페이지가 열린다는 이유만으로 문제가 해결됐다고 판단하지 마세요. 캐시된 페이지일 수 있고, 직접 연결이나 다른 네트워크 경로를 통해 열렸을 수도 있습니다.

해당 운영체제의 수신 포트 조회 명령을 다시 실행하고 포트를 7898로 바꿔 프로세스와 수신 주소를 확인하세요.
‘로그’ 페이지에서 다시 불러온 뒤 새로운 bind 오류가 없는지 확인하세요.
아래 HTTP 프록시 테스트를 실행한 다음 ‘연결’ 페이지에서 요청 대상과 규칙 일치 결과를 확인하세요.

# macOS / Linux
curl --noproxy "" --proxy http://127.0.0.1:7898 --connect-timeout 5 --max-time 15 -I https://example.com

# Windows PowerShell
curl.exe --noproxy "" --proxy http://127.0.0.1:7898 --connect-timeout 5 --max-time 15 -I https://example.com

연결 제한 시간은 5초, 전체 제한 시간은 15초로 설정한 테스트 값이며 실제 지연 시간이 아닙니다. --noproxy ""는 기존 프록시 우회 목록의 영향을 배제합니다. HTTP 응답을 받았다면 요청이 로컬 프록시 포트에서 처리된 것입니다. 다만 응답 코드가 반드시 200이라는 뜻은 아닙니다. 규칙에 따라 직접 연결될 수도 있으므로 연결 상세 정보를 확인하세요.

127.0.0.1:7898에 연결할 수 없다는 메시지가 바로 표시되면 수신 상태를 다시 확인하세요. 로컬 프록시에 연결된 뒤 TLS, DNS 또는 상위 서버 시간 초과가 발생한다면 노드, 도메인 이름 확인 및 규칙을 점검해야 합니다. 이 경우 로컬 포트를 계속 바꿔도 대개 해결되지 않습니다.

자주 묻는 추가 질문: 포트를 바꿨는데도 오류가 발생하는 경우

7897 관련 기록이 여러 줄이면 여러 프로그램이 충돌한 건가요?

반드시 그렇지는 않습니다. 같은 PID가 IPv4와 IPv6에서 각각 수신할 수도 있고, 연결이 이미 성립된 항목이 여러 개일 수도 있습니다. 출력 줄 수만 세지 말고 수신 상태, 주소, 프로토콜, PID를 확인하세요. TCP의 TIME_WAIT 항목도 실행 중인 수신 프로세스로 간주해서는 안 됩니다.

창만 닫고 다시 열어도 되나요?

절차 중 하나로 시도할 수 있지만 결과 확인을 대신할 수는 없습니다. 알림 영역에 남은 프로그램, 서비스 모드, 두 번째 클라이언트가 커널을 계속 실행할 수 있습니다. 종료한 뒤 포트를 다시 조회해야 수신이 실제로 해제됐는지 알 수 있습니다. 다시 실행한 다음에는 새 포트를 사용하는 프로세스도 확인하세요.

‘LAN 연결 허용’을 켜면 포트 점유가 해결되나요?

일반적인 해결 방법으로 사용할 수 없습니다. 이 설정은 수신 범위를 변경해 루프백 주소에서 더 많은 네트워크 인터페이스로 범위를 넓힐 수 있으며, 기존 수신과 오히려 충돌할 수도 있습니다. 로컬에서만 사용할 때는 로컬 접근 범위를 유지하세요. LAN에서 공유하려면 방화벽과 접근 제어도 함께 고려해야 합니다.

클라이언트를 다시 설치하거나 구독을 삭제해야 하나요?

대개 그럴 필요는 없습니다. 구독은 노드와 규칙을 제공하며, 포트 충돌은 로컬 소켓을 바인딩하는 단계에서 발생합니다. 먼저 수신 프로세스를 확인하고, 사용 가능한 포트를 선택한 뒤, 모든 프록시 사용처를 동기화하고 요청을 테스트하세요. 설치나 서비스 자체에 문제가 있다고 확인된 경우에만 해당 구성 요소를 점검하고, 먼저 모든 설정을 지우지는 마세요.