Clash 포트 충돌 해결: 7890 점유 프로세스 확인 및 mixed-port 변경 방법

먼저 어떤 포트에서 리스닝에 실패했는지 확인하세요

Clash 클라이언트를 시작할 때 address already in use가 표시되면 보통 커널이 리슨하려는 로컬 주소와 포트를 이미 다른 프로세스가 사용 중이라는 뜻입니다. 로컬 프록시 진입점을 만드는 과정에서 발생한 문제로, 구독이 만료됐다는 뜻도 원격 노드를 사용할 수 없다는 의미도 아닙니다. 이때 구독을 반복해서 업데이트하거나 노드를 바꿔도 로컬 포트 충돌은 대개 해결되지 않습니다.

먼저 클라이언트의 로그 화면을 열고 listen, bind 또는 in use가 포함된 전체 오류 행을 찾아 주소, 포트, 프로토콜을 기록하세요. 아래는 오류 형식의 예시이며, 기기에서 실제로 확인한 결과는 아닙니다.

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

여기서 확인할 대상은 로컬 TCP 7890 포트입니다. 로그에 127.0.0.1:9090이 표시된다면 프록시 포트를 바로 바꾸지 말고 외부 컨트롤 인터페이스를 확인하세요. 0.0.0.0:7890은 모든 IPv4 인터페이스에서 리슨한다는 뜻이며, 같은 포트를 사용하는 특정 주소의 리스너와 충돌할 수 있습니다. [::]:7890이 표시되면 시스템의 IPv6 듀얼 스택 동작도 함께 고려해야 합니다.

설정 항목	용도	변경 후 함께 수정할 설정
`mixed-port`	하나의 포트에서 HTTP와 SOCKS 프록시 연결 제공	시스템 프록시, 브라우저 프록시 및 명령줄 프록시 변수
`port`	별도의 HTTP 프록시 연결	해당 연결을 사용하는 HTTP 프록시 설정
`socks-port`	별도의 SOCKS 프록시 연결	앱 내 SOCKS 프록시 설정
`external-controller`	클라이언트 또는 대시보드에서 사용하는 컨트롤 API	클라이언트 또는 대시보드의 컨트롤 인터페이스 연결 설정

Windows: netstat로 포트 점유 프로세스 찾기

로컬 주소, 리스닝 상태 및 PID 확인

Windows 터미널이나 명령 프롬프트를 열고 아래 명령을 실행하세요. 일반 권한으로도 보통 연결 정보를 확인할 수 있지만, 일부 프로세스 정보를 읽거나 서비스를 관리하려면 관리자 권한이 필요할 수 있습니다.

netstat -ano -p tcp | findstr ":7890"

출력 열은 순서대로 프로토콜, 로컬 주소, 외부 주소, 상태, PID를 나타냅니다. 반드시 로컬 주소 열을 확인해 포트가 실제로 7890인지 살펴보세요. 텍스트 검색으로 필터링하면 외부 주소나 더 긴 포트 번호까지 일치할 수 있습니다. TCP 프록시 연결을 확인할 때는 7890이 포함된 행을 찾는 데서 그치지 말고 상태가 LISTENING인 행을 확인하세요.

PowerShell에서 포트 번호를 정확하게 지정해 검색하면 수동으로 결과를 확인하기가 더 쉽습니다.

Get-NetTCPConnection -LocalPort 7890 -State Listen |
  Select-Object LocalAddress, LocalPort, State, OwningProcess

조회 결과의 PID가 4321이라고 가정하고, 아래 명령으로 프로그램 이름을 확인하세요. 4321은 명령 형식을 보여 주기 위한 예시이므로 실제 작업에서는 조회한 PID로 바꿔야 합니다.

tasklist /FI "PID eq 4321"

프로세스가 무엇인지 확인한 다음 종료할지 유지할지 결정하세요

다른 프록시 클라이언트: 트레이 메뉴에서 정상적으로 종료한 뒤 포트를 다시 조회하세요. 창만 닫으면 백그라운드에서 계속 실행될 수 있습니다.
현재 클라이언트의 이전 커널 프로세스: 먼저 클라이언트를 종료하고 작업 관리자에서 남은 프로세스의 경로와 명령줄을 확인하세요. 종료되지 않고 남은 커널 프로세스인 것이 확인된 뒤에만 끝내세요.
서비스 모드로 실행된 커널: 창을 닫아도 서비스는 계속 실행될 수 있습니다. 해당 클라이언트가 제공하는 서비스 관리 메뉴에서 관련 서비스를 중지하세요. 그렇지 않으면 프로세스를 끝낸 직후 다시 실행될 수 있습니다.
계속 사용해야 하는 다른 프로그램: 해당 프로그램은 그대로 두고 Clash에 다른 빈 포트를 지정하세요. 포트를 비우려고 시스템 서비스를 무작정 중지하지 마세요.

작업 관리자의 '세부 정보' 탭에서 PID를 확인할 수 있습니다. 열 제목을 마우스 오른쪽 버튼으로 클릭하고 '열 선택'을 누르면 명령줄을 표시할 수 있습니다. 시스템 프로세스가 포트를 점유하고 있다면 포트 번호만 보고 강제 종료하지 마세요. 관련 서비스를 더 확인하거나 다른 포트를 사용해야 합니다.

macOS 및 Linux: lsof 또는 ss로 리스닝 프로세스 확인

macOS에서는 '터미널'을 열고 아래 명령을 실행하세요. -nP는 주소와 포트를 숫자로 표시하고, -sTCP:LISTEN은 TCP 리스닝 소켓만 결과에 포함합니다.

lsof -nP -iTCP:7890 -sTCP:LISTEN

COMMAND, PID, NAME 항목을 확인하세요. 리스닝 프로세스가 다른 사용자 소유로 의심되고 일반 조회에 정보가 모두 표시되지 않으면, 필요한 권한이 있을 때 sudo를 붙여 다시 실행하세요. Linux에 lsof가 설치되어 있지 않다면 보통 iproute2에 포함된 ss를 사용할 수 있습니다.

sudo ss -ltnp 'sport = :7890'

프로세스의 실행 명령을 더 확인하려면 실제 PID를 사용해 조회하세요.

ps -p 4321 -o pid,ppid,command

먼저 애플리케이션 메뉴나 서비스 관리 기능에서 포트를 점유한 프로세스를 정상적으로 중지하세요. 관리 화면을 사용할 수 없는 상태로 남은 프로세스임이 확인되면 kill -TERM 4321처럼 정상 종료 신호를 보낼 수 있습니다. 강제 종료부터 시도하지 마세요. 프로세스가 반복해서 나타나는 원인을 파악할 수 없고 정상적인 정리 절차가 생략될 수 있습니다.

mixed-port 변경: 어떤 설정이 실제 적용되는지 먼저 확인

7890을 다른 필수 프로그램이 사용 중인 것이 확인되면 7892로 바꿀 수 있습니다. 단, 먼저 앞서 안내한 명령으로 7892가 비어 있는지 확인하세요. 포트 번호만 바꿔서는 브라우저, 터미널 또는 컨트롤 패널의 연결 설정이 자동으로 수정되지 않습니다.

Clash Meta(mihomo) 계열 커널에서 사용할 수 있는 부분 설정 예시입니다. 노드와 규칙이 포함된 전체 설정 파일이 아니므로 기존 설정에 반영하고, 구독, 프록시 그룹, 규칙, 접근 인증은 그대로 유지하세요.

mixed-port: 7892
allow-lan: false
external-controller: 127.0.0.1:9090

이 예시에서는 혼합 프록시 포트만 7892로 변경하고 컨트롤 인터페이스 포트 9090은 그대로 둡니다. 로그에 컨트롤 포트 충돌이 없다면 함께 바꿀 필요가 없습니다. allow-lan: false는 LAN 접근을 제한합니다. 개인 기기에서 로컬로만 사용할 경우 포트 점유 문제를 해결하려고 리스닝 범위를 네트워크 전체로 넓히면 안 됩니다.

그래픽 클라이언트의 포트 설정이 구독 파일보다 우선 적용될 수 있습니다

현재 프록시 포트, 컨트롤 포트, 사용 중인 설정 이름을 기록하고 복구할 수 있는 설정 사본을 저장하세요.
클라이언트 설정에서 '혼합 포트', '프록시 포트', '커널 설정'과 같은 항목을 확인하세요. 클라이언트마다 메뉴가 다르므로 전역 리스닝 설정을 관리하는 메뉴를 우선 사용해야 합니다.
클라이언트가 설정 덮어쓰기나 병합을 지원한다면, 실제로 지원되는 영구 설정 위치에 로컬 리스닝 설정을 추가하세요. 임의의 구독 파일에서 같은 방식으로 덮어쓰기가 가능하다고 가정하지 마세요.
변경 사항을 적용하고 커널을 다시 불러오거나 재시작한 뒤 로그를 확인하세요. 포트 리스닝 설정을 적용할 때 재시작이 필요한지는 클라이언트와 커널의 실제 동작에 따라 다릅니다.

다운로드한 구독 YAML 파일을 직접 수정하면 다음 업데이트 때 변경 내용이 덮어써질 수 있습니다. 반대로 구독 파일을 수정해도 클라이언트가 시작할 때 화면 설정으로 같은 항목을 덮어쓰면 변경 사항이 적용되지 않을 수 있습니다. 실제 적용된 설정, 커널 로그, 시스템의 리스닝 상태를 기준으로 판단하세요. 편집기에서 파일을 저장했다는 사실만으로는 충분하지 않습니다.

별도의 port 또는 socks-port가 활성화되어 있는지도 확인하세요. 이 설정들이 mixed-port와 같은 리스닝 주소 및 포트를 사용하지 않도록 하세요. 또한 YAML 최상위 항목에 mixed-port를 두 번 작성하지 마세요. 중복 키는 파싱 오류를 일으키거나 어떤 값이 적용될지 불분명하게 만들 수 있습니다.

컨트롤 포트 충돌: external-controller만 별도로 변경

오류가 9090에서 발생하고 프록시 포트 7890은 정상적으로 리스닝 중이라면 컨트롤 API에 문제가 있는 것입니다. 그래픽 인터페이스에서 연결 정보를 불러오지 못하거나 프록시 그룹 전환이 실패하고, 대시보드에서 커널 연결이 끊긴 것으로 표시될 수 있습니다. 일부 클라이언트에서는 시작 오류가 발생하기도 합니다. 먼저 9090을 점유한 프로세스를 확인한 뒤, 비어 있는 9091로 변경할지 결정하세요.

external-controller: 127.0.0.1:9091

변경 후에는 별도 대시보드가 새 컨트롤 주소에 연결되도록 설정해야 합니다. 그래픽 클라이언트가 컨트롤 인터페이스를 직접 관리한다면 관련 설정도 수정해 화면과 커널 설정을 일치시키세요. 커널 파일만 수정하고 화면의 연결 매개변수는 그대로 두면 프록시는 작동해도 인터페이스가 연결되지 않을 수 있습니다. 기존 secret 인증은 유지하고, 인터페이스에 접근해야 하는 대시보드에도 동일한 값을 설정하세요. 문제를 확인하려고 인증을 해제하지 마세요.

충돌을 해결하려고 컨트롤 인터페이스를 0.0.0.0:9091로 바꾸지 마세요. 인터페이스가 외부에 노출되는 범위가 넓어지고, 기존 리스닝과의 충돌을 피할 수 있다는 보장도 없습니다. 컨트롤 인터페이스와 혼합 프록시 인터페이스는 서로 다른 설정입니다. 충돌이 발생한 항목만 수정해야 결과를 확인하고 되돌리기 쉽습니다.

이전 포트로 연결되지 않도록 시스템 및 앱 프록시 설정도 업데이트하세요

혼합 포트를 7892로 바꿔도 127.0.0.1:7890을 계속 사용하는 앱은 여전히 연결되지 않습니다. 그래픽 클라이언트는 시스템 프록시를 켤 때 새 값을 설정하는 경우가 많지만, 자동 업데이트 여부는 클라이언트마다 다릅니다. 새 포트를 적용한 뒤 시스템 프록시를 껐다가 다시 켜고, 시스템에 표시되는 실제 주소를 확인하세요.

Windows 11: '설정' → '네트워크 및 인터넷' → '프록시' → '수동 프록시 설정'의 '프록시 서버 사용'에서 '설정'을 열고 주소와 포트를 확인하세요. 자동 구성 스크립트를 사용한다면 스크립트가 제공하는 프록시 주소도 확인해야 합니다.
macOS 13 이상: '시스템 설정' → '네트워크' → 현재 연결 → '세부사항' → '프록시'로 이동해 웹 프록시(HTTP), 보안 웹 프록시(HTTPS), SOCKS 프록시 중 실제로 활성화된 항목을 확인하세요.
Firefox: '설정' → '일반' → '네트워크 설정' → '설정'에서 확인하세요. 별도로 지정한 수동 프록시는 운영체제의 프록시 설정을 변경해도 자동으로 동기화되지 않습니다.
터미널 및 개발 도구: HTTP_PROXY, HTTPS_PROXY, ALL_PROXY와 Git, 편집기, 컨테이너에 별도로 설정된 프록시 주소를 확인하세요.

혼합 포트는 HTTP와 SOCKS 요청을 모두 받을 수 있지만, 앱에서 올바른 프로토콜을 선택해야 합니다. 예를 들어 HTTP 프록시 주소는 http://127.0.0.1:7892로 지정할 수 있습니다. SOCKS 프록시를 통해 도메인 이름을 확인해야 한다면 해당 형식을 지원하는 도구에서 socks5h://127.0.0.1:7892를 사용하세요. HTTP 프록시로 HTTPS 웹사이트에 터널을 연결한다고 해서 로컬 프록시 주소를 https://로 지정해야 하는 것은 아닙니다.

TUN 모드는 가상 네트워크 인터페이스로 트래픽을 처리하므로 시스템 HTTP 프록시와는 다릅니다. 일부 TUN 환경에서 브라우저가 접속된다고 해서 이전 7890 설정이 해결된 것은 아닙니다. 반대로 일반적인 혼합 포트 충돌을 해결하려고 TUN 장치를 제거할 필요도 없습니다. 프록시 연결을 확인할 때는 새 포트를 명시해 연결 경로가 혼동되지 않도록 하세요.

수정 결과와 재시작 후 설정 유지 여부 확인

먼저 리스닝 상태를 확인하고 실제 요청도 보내 보세요

7892를 다시 조회해 예상한 커널 프로세스가 리스닝 중인지 확인하고, 로그에 바인딩 실패가 계속 표시되는지도 살펴보세요. 그런 다음 curl로 새 연결 지점을 지정해 요청하세요. Windows PowerShell에서는 curl.exe를 사용하면 일부 환경에서 같은 이름으로 등록된 명령 별칭의 영향을 피할 수 있습니다.

curl.exe -I --connect-timeout 5 --max-time 15 --proxy http://127.0.0.1:7892 https://example.com/

macOS와 Linux에서도 같은 매개변수를 사용하고 명령어만 curl로 바꾸면 됩니다. 여기서 5초와 15초는 각각 연결 단계와 전체 요청의 최대 대기 시간이며, 속도 측정 결과가 아닙니다. 예시는 로컬 프록시에 인증이 설정되지 않았다고 가정합니다. 인증을 사용하는 경우 기존 방식대로 인증 정보를 제공하고 비밀번호를 공개 로그에 붙여넣지 마세요.

로컬 연결이 거부됨: 새 포트가 리스닝 중인지, 주소가 일치하는지, 커널이 종료되지는 않았는지 먼저 확인하세요.
요청은 커널에 도달하지만 아웃바운드 연결이 시간 초과됨: 연결 기록을 확인해 규칙 적용 결과, 노드, DNS를 점검하세요. 포트 리스닝이 복구되어도 이후 연결 경로까지 정상이라는 뜻은 아닙니다.
curl은 성공하지만 브라우저에서 실패함: 브라우저의 별도 프록시 설정, 프록시 확장 프로그램, 자동 구성 스크립트, 이전 연결을 확인하세요. 곧바로 포트를 다시 변경할 필요는 없습니다.
브라우저는 정상인데 대시보드에서 실패함: 컨트롤 인터페이스 주소와 인증을 다시 확인하세요. 컨트롤 인터페이스 오류를 프록시 연결 문제로 혼동하지 마세요.

종료 후 다시 실행해 한 번 더 확인하세요

테스트가 끝나면 클라이언트를 정상적으로 종료하고 다시 시작해 리스닝 포트가 여전히 7892인지 확인하세요. 컴퓨터를 켠 뒤에 문제가 자주 발생한다면 로그인 시 자동 실행 항목과 서비스 모드도 확인하세요. 실제로 필요한 자동 실행 항목만 남겨 이전 클라이언트와 새 클라이언트가 같은 포트를 동시에 사용하지 않도록 하세요.

TCP 조회에서 리스닝 프로세스가 보이지 않는데도 바인딩에 실패한다면 먼저 로그의 시간, 주소, 프로토콜을 다시 확인하세요. Windows에서 address already in use와 access permissions는 서로 다른 원인을 살펴봐야 합니다. 후자는 예약된 포트 범위나 보안 정책과 관련이 있을 수 있습니다. 아래 명령으로 TCP 제외 포트 범위를 확인할 수 있지만 시스템 예약 항목을 직접 삭제하지 마세요.

netsh interface ipv4 show excludedportrange protocol=tcp

최종적으로 네 가지를 모두 확인해야 합니다. 커널이 예상한 포트에서 정상적으로 리스닝하고, 시스템과 앱이 새 연결 지점을 사용하며, 컨트롤 인터페이스가 연결되고, 재시작 후에도 설정이 유지되어야 합니다. 설정을 되돌려야 한다면 기존 포트가 비워진 것을 먼저 확인한 다음 원래 설정을 복구하고 시스템 프록시도 함께 업데이트하세요. 클라이언트를 잠시 종료할 때는 클라이언트가 설정한 시스템 프록시도 꺼야 합니다. 그렇지 않으면 시스템이 중지된 로컬 포트로 계속 요청을 보낼 수 있습니다.