Clash 포트 사용 중 오류 해결: 7890 충돌 프로세스 찾기 및 혼합 포트 변경

먼저 충돌한 포트가 무엇인지 확인하기

“address already in use”, “bind failed” 또는 “포트가 이미 사용 중입니다”라는 메시지가 표시되면 원인은 대개 명확합니다. Mihomo 코어가 로컬 포트를 열려고 했지만 해당 포트를 다른 프로세스가 이미 사용 중인 상태입니다. 충돌이 자주 발생하는 포트는 7890이며, 7891, 9090 또는 설정에서 직접 지정한 포트일 수도 있습니다.

mixed-port는 HTTP 프록시와 SOCKS5 프록시 연결을 하나의 수신 포트에서 처리하는 혼합 프록시 포트입니다. 많은 Clash 클라이언트가 기본값으로 7890을 사용합니다. 브라우저 확장 프로그램, 시스템 프록시, 명령줄 도구가 주로 이 포트에 연결하므로 충돌이 발생하면 코어가 시작되지 않거나 프록시에 연결할 수 없습니다.

설정 항목	주요 포트	용도	mixed-port와 중복 사용 가능 여부
`mixed-port`	7890	HTTP와 SOCKS5 프록시를 모두 수신	하나의 프로세스만 수신 가능
`port`	7890	HTTP 프록스만 제공	동일한 수신 주소와 포트 사용 불가
`socks-port`	7891	SOCKS5 프록시만 제공	동일한 수신 주소와 포트 사용 불가
`external-controller`	9090	제어 인터페이스 제공, 일반 프록시 트래픽은 처리하지 않음	독립 포트 사용 필요

로그에서 정확한 포트 확인하기

먼저 클라이언트의 로그 화면을 열고 bind, listen, address already in use 또는 포트를 검색하세요. 로그에 listen tcp 127.0.0.1:7890이 표시되면 TCP 7890을 점검해야 합니다. 0.0.0.0:7890이 표시되면 프로그램이 로컬 네트워크 인터페이스 전체에서 해당 포트를 수신하려는 뜻이므로, 127.0.0.1만 수신할 때보다 충돌 범위가 넓습니다.

같은 설정 파일에 mixed-port: 7890과 port: 7890이 동시에 작성되어 있지는 않은지도 확인하세요. 이 경우 외부 프로그램을 찾을 필요가 없습니다. 설정 자체가 두 수신기가 같은 주소를 사용하도록 요구하고 있기 때문입니다. 혼합 포트만 남기고 사용하지 않는 독립 HTTP 또는 SOCKS 포트를 삭제하면 됩니다.

Windows에서 netstat로 7890 점유 프로세스 찾기

Windows 10과 Windows 11에서는 시스템에 기본 포함된 netstat을 사용할 수 있습니다. 현재 Clash 클라이언트를 완전히 종료한 뒤 관리자 권한으로 “터미널” 또는 “명령 프롬프트”를 열고 다음 명령을 실행하세요:

netstat -ano | findstr :7890

일반적인 결과는 다음과 같습니다. 마지막 열의 16420은 프로세스 식별자인 PID입니다:

TCP    127.0.0.1:7890    0.0.0.0:0    LISTENING    16420

상태가 LISTENING인 항목만 프로그램이 해당 TCP 포트를 수신 중임을 의미합니다. 원격 주소에 :7890이 포함되어 있다는 이유만으로 로컬 포트가 점유되었다고 판단할 수는 없습니다. “로컬 주소” 열이 127.0.0.1:7890, 0.0.0.0:7890 또는 [::]:7890인지 중점적으로 확인하세요.

PID로 프로그램 이름 확인하기

PID를 확인했다면 다음 명령을 이어서 실행하세요:

tasklist /FI "PID eq 16420"

PowerShell에서는 프로그램 경로도 확인할 수 있습니다:

Get-Process -Id 16420
Get-CimInstance Win32_Process -Filter "ProcessId = 16420" |
  Select-Object ProcessId, Name, ExecutablePath, CommandLine

결과가 다른 Clash, Mihomo, sing-box 또는 프록시 클라이언트라면 이전 코어가 UI 종료와 함께 종료되지 않았을 가능성이 큽니다. 먼저 해당 클라이언트의 메뉴에서 정상적으로 종료한 뒤 3~5초 후 포트를 다시 확인하세요. 작업 관리자에서 창만 닫아도 백그라운드 코어가 종료된다는 보장은 없습니다. 시스템 트레이에 실행 아이콘이 남아 있을 수도 있습니다.

프로세스를 종료해도 되는 것이 확실하다면 작업 관리자의 “세부 정보” 탭에서 PID로 찾거나 다음 명령을 실행할 수 있습니다:

taskkill /PID 16420 /F

netstat에 결과가 없는데도 오류가 발생할 때

로그에 표시된 포트가 실제로 7890인지 확인하세요. 제어 포트 9090을 혼합 포트로 착각하지 마세요.
IPv4와 IPv6를 모두 확인하세요. [::]:7890을 수신 중인 프로그램이 다른 프로세스의 IPv4 주소 바인딩을 막을 수 있습니다.
클라이언트를 종료한 뒤 명령을 다시 실행하세요. 현재 클라이언트의 정상적인 수신을 충돌로 잘못 판단하지 않도록 해야 합니다.
클라이언트가 두 개의 코어 인스턴스를 중복 실행하고 있지는 않은지 확인하세요. 예를 들어 포터블 버전과 설치 버전이 모두 시작 프로그램으로 등록되어 있을 수 있습니다.
로그에 실제로 권한 부족이 표시되는지도 확인하세요. 권한 오류와 포트 사용 중 오류는 해결 방법이 다릅니다.

macOS에서 lsof로 수신 프로그램 찾기

macOS에서는 lsof로 TCP 7890을 열어 둔 프로세스를 확인할 수 있습니다. “터미널”을 열고 다음 명령을 실행하세요:

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

-nP는 숫자 형식의 주소와 포트를 바로 표시해 도메인 확인으로 인한 지연을 방지합니다. 결과의 COMMAND는 프로세스 이름이고 PID는 프로세스 번호입니다. 예시는 다음과 같습니다:

COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
mihomo   8421 user   10u  IPv4        0t0      TCP 127.0.0.1:7890 (LISTEN)

다음 명령으로 시작 인자를 확인해 어느 클라이언트에 속한 프로세스인지 판단하세요:

ps -p 8421 -o pid,ppid,user,command

프로세스가 실행 중인 다른 프록시 클라이언트에서 시작된 것이라면 먼저 메뉴 막대 아이콘에서 정상적으로 종료하세요. 프로세스가 응답하지 않는 것이 확인된 경우에만 먼저 일반 종료 신호를 보내세요:

kill 8421

몇 초 기다린 후 lsof를 다시 실행하세요. 일반 종료가 실패한 경우에만 kill -9 8421을 고려하세요. 강제 종료를 하면 클라이언트가 현재 설정을 저장하지 못할 수 있으므로 첫 단계로 사용해서는 안 됩니다.

독립 SOCKS 포트도 함께 점검하기

설정에서 socks-port: 7891도 활성화되어 있다면 7890과 7891을 각각 조회해야 합니다. 혼합 포트를 7892로 바꿔도 7891에서 별도 수신기가 충돌하는 문제는 해결되지 않습니다:

sudo lsof -nP -iTCP:7890 -sTCP:LISTEN
sudo lsof -nP -iTCP:7891 -sTCP:LISTEN
sudo lsof -nP -iTCP:9090 -sTCP:LISTEN

Linux에서 ss로 포트 수신 상태 확인하기

대부분의 최신 Linux 배포판에는 ss가 기본으로 제공됩니다. 수신 소켓과 연결된 프로세스를 바로 표시할 수 있습니다. 다음 명령을 실행하세요:

sudo ss -ltnp 'sport = :7890'

옵션의 l은 수신 상태만 표시하고, t는 TCP, n은 숫자 포트를 바로 표시하며, p는 프로세스를 표시합니다. 호환성이 좋고 더 직관적인 필터 방식도 사용할 수 있습니다:

sudo ss -ltnp | grep ':7890'

결과는 다음과 비슷하게 표시될 수 있습니다:

LISTEN 0 4096 127.0.0.1:7890 0.0.0.0:* users:(("mihomo",pid=2317,fd=8))

Mihomo가 systemd로 관리된다면 kill만 사용해 프로세스를 종료하지 마세요. 서비스 관리자가 즉시 다시 시작할 수 있습니다. 먼저 서비스 상태를 확인한 다음 해당 유닛을 중지하세요:

systemctl --type=service --state=running | grep -Ei 'mihomo|clash'
sudo systemctl status mihomo
sudo systemctl stop mihomo

컨테이너 환경에서는 포트 매핑도 확인해야 합니다. 호스트의 Docker 또는 Podman 프록시 프로세스가 7890을 점유하고 있을 수 있으며, 컨테이너 내부에 Mihomo라는 호스트 프로세스가 없어도 발생할 수 있습니다:

docker ps --format 'table {{.ID}}\t{{.Names}}\t{{.Ports}}'
podman ps --format 'table {{.ID}}\t{{.Names}}\t{{.Ports}}'

mixed-port와 클라이언트 수신 포트 변경하기

7890을 점유한 프로그램을 계속 사용해야 한다면 Clash 또는 Mihomo를 사용하지 않는 포트로 변경하는 것이 가장 안전합니다. 예를 들어 7892를 사용할 수 있습니다. 먼저 앞서 안내한 시스템 명령으로 7892에 수신 항목이 없는지 확인한 뒤 클라이언트 설정을 변경하세요.

그래픽 인터페이스에서 변경하기

그래픽 인터페이스를 제공하는 클라이언트는 보통 「설정」→「환경 설정」→「혼합 포트」에서 변경할 수 있습니다. 7890을 7892로 바꾸고 저장한 뒤 코어를 재시작하세요. 클라이언트에 따라 메뉴 이름이 “Mixed Port”, “혼합 프록시 포트” 또는 “포트 설정”으로 표시될 수 있지만, 변경 대상은 모두 현재 코어의 mixed-port입니다.

페이지에 HTTP 포트, SOCKS 포트, 혼합 포트가 함께 표시되더라도 여러 항목에 같은 값을 입력하지 마세요. 단일 진입점만 필요하다면 혼합 포트를 활성화하고 사용하지 않는 독립 수신 항목을 끄면 충돌 가능성을 줄일 수 있습니다.

YAML 설정을 직접 편집하기

설정 파일에서 해당 항목을 다음과 같이 변경하세요:

mixed-port: 7892
allow-lan: false
mode: rule
log-level: info

mixed-port는 정수여야 하며 콜론이 포함된 주소 형식으로 작성할 수 없습니다. 같은 설정의 port, socks-port 또는 제어 인터페이스와 중복되어서도 안 됩니다. 저장한 뒤 코어가 설정을 다시 읽도록 해야 합니다. 디스크의 파일만 수정하면 이미 실행 중인 수신 포트가 자동으로 바뀌지 않습니다.

여러 Profile을 함께 사용하는 경우 현재 활성화된 설정을 편집하고 있는지 확인하세요. 일부 클라이언트는 구독 내용을 앱 데이터 폴더에 복사하므로 구독 원본 파일과 실행 중인 설정 파일이 다를 수 있습니다. 먼저 UI에서 현재 Profile 이름을 확인한 뒤 해당 설정의 편집 메뉴로 들어가 비활성 복사본을 수정하지 않도록 하세요.

새 포트가 실제로 수신 중인지 확인하기

코어를 재시작한 뒤 웹 페이지가 열리는지만 바로 확인하지 마세요. 먼저 시스템에 새 수신기가 생성되었는지, 이전 포트가 현재 클라이언트에 더 이상 사용되지 않는지 확인하세요:

# Windows
netstat -ano | findstr :7892

# macOS
sudo lsof -nP -iTCP:7892 -sTCP:LISTEN

# Linux
sudo ss -ltnp 'sport = :7892'

예상 결과는 로컬 주소 127.0.0.1:7892 또는 클라이언트에서 지정한 수신 주소가 LISTEN 상태로 표시되는 것입니다. 클라이언트가 LAN 연결을 허용하면 0.0.0.0:7892로 표시될 수 있습니다. 이 경우 접근 제어와 방화벽 규칙도 확인하고, 로컬 충돌을 해결한다는 이유만으로 수신 범위를 넓히지 마세요.

시스템 프록시와 앱 프록시 설정 동기화하기

포트를 변경했는데도 웹 페이지가 열리지 않는 가장 흔한 원인은 시스템 프록시가 여전히 이전 주소인 127.0.0.1:7890을 가리키는 것입니다. 코어는 7892에서 정상 실행 중인데 브라우저가 계속 7890에 연결하면 “변경 사항이 적용되지 않은” 것처럼 보입니다.

먼저 클라이언트에서 시스템 프록시를 다시 설정하세요

클라이언트에서 “시스템 프록시” 스위치를 끄세요.
혼합 포트가 7892로 저장되었는지 확인하고 코어를 재시작하세요.
“시스템 프록시”를 다시 켜세요.
운영체제의 프록시 설정 화면으로 이동해 주소가 127.0.0.1이고 포트가 7892인지 확인하세요.

Windows 11에서는 「설정」→「네트워크 및 인터넷」→「프록시」에서 수동 프록시 서버를 확인할 수 있습니다. macOS에서는 「시스템 설정」→「네트워크」→현재 네트워크→「세부사항」→「프록시」에서 웹 프록시 또는 보안 웹 프록시를 확인하세요. 일반적으로는 클라이언트가 이 항목을 관리하도록 두는 편이 안전하며, 직접 입력할 때는 실제 수신 포트와 일치해야 합니다.

브라우저 확장 프로그램과 명령줄 변수를 확인하기

프록시 전환 확장 프로그램은 시스템 설정을 우회하면서 이전 포트를 계속 사용할 수 있습니다. 확장 프로그램의 프록시 설정에서 HTTP 또는 SOCKS5 포트를 7892로 변경하세요. 개발 도구가 환경 변수로 프록시를 지정할 수도 있으므로 다음 항목을 각각 확인하세요:

HTTP_PROXY=http://127.0.0.1:7892
HTTPS_PROXY=http://127.0.0.1:7892
ALL_PROXY=socks5://127.0.0.1:7892

하나의 mixed-port에서 위 두 프로토콜을 모두 처리할 수 있지만, 앱에 입력하는 프로토콜 접두사는 올바라야 합니다. 독립 socks-port를 설정했다면 ALL_PROXY는 혼합 포트가 아니라 해당 독립 포트를 가리켜야 합니다.

TUN 모드의 차이점

TUN 모드는 가상 네트워크 인터페이스를 통해 트래픽을 가로채므로 일반적으로 시스템 HTTP 프록시 스위치에 의존하지 않습니다. 하지만 설정에서 Mihomo가 mixed-port: 7890을 생성하도록 되어 있다면 7890 점유로 인해 코어가 시작되지 않을 수 있습니다. 해결 방법은 충돌 프로세스를 종료하거나 수신 포트를 변경하는 것입니다.

문제 해결 중에는 트래픽 처리 방식을 하나만 남겨 두는 것이 좋습니다. TUN을 끄고 시스템 프록시로 7892를 확인하거나, 시스템 프록시를 끄고 TUN만 확인하세요. 두 방식을 동시에 켜면 변수가 늘어나 DNS, 라우팅 또는 브라우저 확장 프로그램 문제를 포트 충돌로 오인하기 쉽습니다.

변경 후에도 사용 중 오류가 날 때 확인 순서

포트를 7892로 바꿨는데도 로그에 7890이 사용 중이라고 표시된다면 실행 중인 설정에 방금 변경한 내용이 반영되지 않은 것입니다. 다음 순서대로 확인하면 설정, 프로세스, 시스템 프록시 중 무엇이 동기화되지 않았는지 빠르게 찾을 수 있습니다.

최신 로그를 다시 확인하세요. 오류 시간이 이번 재시작 이후인지 확인하고 로그에 표시된 전체 주소와 포트를 기록하세요.
현재 Profile을 확인하세요. 클라이언트에서 현재 선택된 설정 이름을 확인해 테스트 설정을 편집하고도 구독 설정이 실행되는 상황을 피하세요.
설정을 다시 불러오세요. YAML을 저장한 뒤 클라이언트의 “설정 다시 불러오기” 또는 “코어 재시작”을 사용하세요. 설정 창만 닫아서는 안 됩니다.
중복 클라이언트를 점검하세요. 시스템 트레이, 메뉴 막대, 시작 프로그램, systemd 서비스, 컨테이너를 확인해 두 번째 코어 인스턴스가 없는지 확인하세요.
중복 항목을 확인하세요. mixed-port, port, socks-port, external-controller가 같은 주소와 포트를 사용하지 않는지 확인하세요.
새 포트의 수신 상태를 확인하세요. 클라이언트 UI에 “실행 중”이라고 표시되는지만 보지 말고 netstat, lsof 또는 ss로 7892를 검증하세요.
모든 프록시 진입점을 동기화하세요. 시스템 프록시, 브라우저 확장 프로그램, 터미널 환경 변수, 개발 도구, LAN 기기의 이전 포트를 업데이트하세요.

curl로 최종 확인하기

7892가 정상적으로 수신 중인지 확인했다면 curl이 혼합 포트를 거쳐 요청을 보내도록 명시할 수 있습니다. 다음 명령은 연결 과정과 HTTP 응답 헤더를 표시합니다:

curl -I -v -x http://127.0.0.1:7892 https://example.com

출력에는 먼저 127.0.0.1:7892에 연결한 뒤 대상 사이트와 CONNECT 터널을 설정하는 과정이 나타나야 합니다. Connection refused가 표시되면 해당 주소에서 사용 가능한 수신기가 없다는 뜻입니다. 연결은 성공했지만 대상 요청이 시간 초과된다면 포트 충돌은 해결된 것이므로 다음으로 노드, 규칙, DNS 또는 네트워크 연결을 점검하세요.

재사용 가능한 해결 요약

로그에 address already in use가 표시됨: 먼저 수신 프로세스를 확인하고 노드부터 바꾸지 마세요.
이전 프록시 프로그램이 7890을 점유함: 이전 프로그램을 종료하고 중복 자동 시작을 정리하세요.
점유 프로그램을 계속 사용해야 함: 사용 가능 여부를 확인한 포트(예: 7892)로 mixed-port를 변경하세요.
코어는 새 포트에서 수신 중인데 앱이 인터넷에 연결되지 않음: 시스템 프록시와 앱 내부 프록시를 함께 변경하세요.
구독 업데이트 후 문제가 재발함: 클라이언트의 영구 덮어쓰기 설정에 포트 변경을 저장하세요.
TUN을 활성화해도 시작되지 않음: 설정의 혼합 포트와 제어 포트가 충돌하는지 계속 확인하세요.