Clash 포트 7890 사용 중일 때 해결 방법: 충돌 프로세스 확인 및 mixed-port 변경 전체 절차

먼저 충돌이 발생한 수신 포트를 확인하세요

Clash, Clash Meta(mihomo) 및 그래픽 클라이언트는 시작할 때 로컬 컴퓨터에 하나 이상의 수신 포트를 만들어야 합니다. 흔한 오류로는 address already in use, bind: Only one usage of each socket address, listen tcp 127.0.0.1:7890: bind와 클라이언트 화면의 “포트가 사용 중입니다”가 있습니다. 이는 운영체제가 새 수신 요청을 거부했다는 뜻이며, 전체 설정 파일이 손상되었다는 의미는 아닙니다.

7890은 Clash 설정에서 흔히 사용하는 프록시 포트일 뿐, 고정된 필수 값은 아닙니다. mixed-port: 7890을 사용하면 하나의 포트에서 HTTP와 SOCKS5 프록시 연결을 모두 받을 수 있습니다. 일부 오래된 설정은 port: 7890과 socks-port: 7891을 따로 사용합니다. mihomo 설정에는 투명 프록시, DNS, 컨트롤 인터페이스에 필요한 다른 포트도 포함될 수 있으므로 문제를 확인하기 전에 오류 메시지 전체를 먼저 읽어야 합니다.

자주 사용하는 포트와 용도

설정 항목	일반적인 값	용도	충돌 발생 시 증상
`mixed-port`	`7890`	HTTP 및 SOCKS5 혼합 프록시	시스템 프록시와 수동 프록시에 연결할 수 없음
`port`	`7890`	HTTP 프록시	브라우저 HTTP 프록시가 작동하지 않음
`socks-port`	`7891`	SOCKS5 프록시	SOCKS5를 사용하는 앱에 연결할 수 없음
`external-controller`	`127.0.0.1:9090`	패널 및 클라이언트 컨트롤 인터페이스	커널은 실행 중이지만 패널에는 연결 끊김으로 표시됨
`dns.listen`	`0.0.0.0:1053`	로컬 DNS 서비스	DNS 모듈 시작 실패 또는 비정상적인 해석

Windows에서 7890을 점유한 프로세스 확인

현재 Clash 클라이언트를 완전히 종료한 뒤 다시 시작해 보세요. 오류가 계속되면 백그라운드에 다른 커널 프로세스가 남아 있거나 다른 프록시 프로그램이 해당 포트를 사용 중일 수 있습니다. 창만 닫아서는 안 됩니다. 많은 클라이언트의 닫기 버튼은 프로그램을 알림 영역으로 최소화할 뿐, 커널은 백그라운드에서 계속 포트를 사용합니다.

방법 1: netstat 및 tasklist 사용

일반 권한으로 “터미널” 또는 “명령 프롬프트”를 열고 다음을 실행하세요:

netstat -ano | findstr :7890

일반적인 결과는 다음과 같습니다:

TCP    127.0.0.1:7890    0.0.0.0:0    LISTENING    18432

마지막 열의 18432는 프로세스 PID입니다. 상태가 LISTENING인 기록만 포트가 실제로 수신 대기 중임을 직접 보여 줍니다. 많은 TIME_WAIT 연결은 일반적으로 수신 충돌을 뜻하지 않으므로 이를 근거로 프로세스를 종료하지 마세요. PID에 해당하는 프로그램을 계속 확인합니다:

tasklist /FI "PID eq 18432"

결과가 mihomo.exe, clash.exe 또는 클라이언트에 포함된 커널 파일이면 대개 남아 있는 프로세스입니다. 다른 프록시 도구가 표시되면 먼저 해당 도구에서 서비스를 중지하거나 프로그램을 종료한 후 Clash 포트를 변경할지 결정하세요.

방법 2: PowerShell 사용

PowerShell에서는 수신 엔드포인트와 프로세스 이름을 바로 확인할 수 있습니다:

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

Get-Process -Id 18432

첫 번째 명령에서 권한 부족 메시지가 표시되면 Windows 터미널을 관리자 권한으로 열고 다시 실행하세요. “작업 관리자” → “세부 정보”에서 PID순으로 정렬해 프로세스 경로와 시작 시간도 확인할 수 있습니다. 경로가 현재 클라이언트 디렉터리에 있고 시작 시간이 이번 작업보다 훨씬 이르면 잔여 커널일 가능성이 높습니다.

남아 있는 프로세스를 안전하게 종료하기

먼저 알림 영역 메뉴에서 “종료”를 선택해 클라이언트가 커널, 시스템 프록시, 서비스를 함께 닫도록 하세요. 화면을 조작할 수 없을 때만 다음 명령을 사용합니다:

taskkill /PID 18432 /T

일반 종료가 실패하고 PID가 정확한지 확인한 후에는 강제 옵션을 추가할 수 있습니다:

taskkill /PID 18432 /T /F

macOS 및 Linux에서 포트 사용 여부 확인

macOS에서 lsof 사용

“터미널”을 열고 TCP 7890을 수신 대기 중인 프로그램을 확인하세요:

lsof -nP -iTCP:7890 -sTCP:LISTEN

출력의 COMMAND는 프로세스 이름, PID는 프로세스 번호, NAME은 수신 주소를 보여 줍니다. 출력이 없으면 오류 로그가 실제로 7891, 9090 또는 1053을 가리키는지 확인하세요. 수신 대기 상태 조건을 제거하고 포트와 관련된 모든 연결을 확인할 수도 있습니다:

lsof -nP -i :7890

잔여 mihomo 또는 Clash 커널인지 확인했다면 먼저 정상 종료를 시도하세요:

kill 18432

약 2초 기다린 후 lsof를 다시 실행하세요. 프로세스가 계속 남아 있다면 그래픽 클라이언트나 백그라운드 서비스가 자동으로 다시 실행하는지 확인합니다. kill -9를 직접 실행해도 현재 인스턴스만 종료될 뿐, 데몬이 반복해서 시작되는 문제는 해결되지 않습니다.

Linux에서 ss 또는 lsof 사용

대부분의 최신 배포판에는 ss가 기본으로 설치되어 있습니다:

sudo ss -ltnp 'sport = :7890'

다음 명령을 사용할 수도 있습니다:

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

mihomo가 systemd로 실행 중이라면 커널 프로세스만 종료하지 마세요. systemd가 서비스 설정에 따라 다시 시작합니다. 먼저 서비스 상태를 확인한 후 해당 유닛을 중지하세요:

sudo systemctl status mihomo
sudo systemctl stop mihomo

서비스 이름은 설치 방식에 따라 달라질 수 있으며 mihomo로 고정되지 않습니다. systemctl list-units --type=service | grep -Ei 'clash|mihomo'를 실행해 찾아보세요. 컨테이너 배포 환경에서는 Docker의 포트 매핑도 확인해야 합니다. 호스트의 127.0.0.1:7890을 컨테이너 프록시 프로세스가 점유하고 있을 수 있으며, 컨테이너 내부 커널이 직접 표시되지 않을 수도 있습니다.

프로세스를 종료할지 mixed-port를 변경할지 판단하기

점유 프로그램을 찾았다고 바로 포트를 변경하지 마세요. 먼저 두 프로그램을 모두 계속 실행해야 하는지 판단합니다. 점유자가 같은 클라이언트의 비정상 종료로 남은 커널이라면 잔여 프로세스를 종료하고 다시 시작하면 됩니다. 두 프록시 도구를 동시에 실행해야 하거나 7890을 로컬 개발 서비스가 고정적으로 사용한다면 한쪽에 새 포트를 지정해야 합니다.

기존 프로세스를 종료하기 적합한 경우

점유자가 현재 클라이언트와 동일한 커널 파일 및 설정 디렉터리를 사용합니다.
작업 관리자 또는 활성 상태 보기에서 mihomo나 Clash 커널 인스턴스가 두 개 표시됩니다.
이전 클라이언트는 삭제했지만 시작 프로그램, 서비스 또는 예약 작업이 남아 있습니다.
포트를 비운 뒤에는 프록시 클라이언트 하나만 실행하면 됩니다.

포트를 변경하기 적합한 경우

7890을 계속 실행해야 하는 다른 프록시 또는 디버깅 도구가 사용 중입니다.
안정 설정과 테스트 설정을 동시에 실행해야 하며 두 커널을 분리해야 합니다.
중앙 관리 환경에서 애플리케이션에 고정 포트 범위를 할당했습니다.
현재 설정을 다른 장치와 공유하고 있어 점유 프로그램을 바로 중지하면 기존 작업 흐름에 영향을 줍니다.

새 포트는 7893, 17890, 27890처럼 현재 수신 대기 중이지 않은 로컬 포트를 선택하세요. 변경하기 전에 같은 명령으로 후보 포트가 비어 있는지 확인합니다. 포트 범위는 1부터 65535까지입니다. 일반 데스크톱 설정에서는 1부터 1023까지의 주요 시스템 서비스 포트를 피하고, 설정의 컨트롤 인터페이스, DNS 수신 포트, 투명 프록시 포트와도 겹치지 않게 하세요.

설정 파일에서 mixed-port 변경

YAML을 직접 편집한다면 최상위의 mixed-port를 찾으세요. 다음 설정은 혼합 프록시 포트를 7890에서 7893으로 변경합니다:

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

mixed-port는 설정 최상위에 있어야 하며 proxies, proxy-groups, dns 아래로 들여쓰면 안 됩니다. 콜론 뒤에는 공백 하나를 두고 포트는 정수로 입력하세요. 저장한 뒤에는 커널이 설정을 완전히 다시 불러오도록 해야 합니다. 전략 그룹만 전환해서는 수신 포트가 다시 생성되지 않습니다.

중복 수신 설정을 함께 유지하지 마세요

설정에서 이미 혼합 포트를 사용한다면 HTTP와 SOCKS에 같은 값을 별도로 지정할 필요가 없습니다. 다음 설정은 여러 수신기가 7893을 두고 충돌하게 만듭니다:

mixed-port: 7893
port: 7893
socks-port: 7893

한 가지 방식만 선택해야 합니다. 진입점 하나만 필요하다면 다음만 남기세요:

mixed-port: 7893

HTTP와 SOCKS5를 실제로 분리 제공해야 한다면 서로 다른 포트를 사용하고 mixed-port를 삭제하세요:

port: 7893
socks-port: 7894

그래픽 클라이언트에서 포트 변경

클라이언트마다 메뉴 이름은 다르지만 일반적으로 “설정” → “매개변수 설정” → “포트” 또는 “설정” → “커널 설정” → “혼합 포트”에서 변경합니다. 7890을 확인된 빈 포트 7893으로 바꾸고 저장한 뒤 “커널 재시작”을 실행하거나 클라이언트를 완전히 종료했다가 다시 여세요.

일부 화면에는 HTTP, SOCKS, Mixed가 함께 표시됩니다. Mixed를 활성화했다면 혼합 포트를 기본 진입점으로 사용하세요. 클라이언트에서 개별 HTTP 및 SOCKS 수신을 끌 수 있다면 사용하지 않는 진입점을 꺼서 중복 설정을 줄이는 것이 좋습니다. 포트가 읽기 전용으로 잠겨 있다면 일반적으로 현재 설정 파일이나 오버라이드 규칙이 값을 제어한다는 뜻이므로 설정 관리 화면에서 변경해야 합니다.

시스템 프록시 설정도 함께 업데이트

포트를 변경한 뒤에도 시스템 프록시가 이전 주소인 127.0.0.1:7890을 가리킬 수 있습니다. 이 경우 커널은 정상적으로 시작했지만 브라우저에서는 연결할 수 없게 됩니다. 클라이언트의 “시스템 프록시” 스위치를 껐다가 다시 켜면 새 포트가 적용되는 경우가 많습니다. 운영체제에서 직접 확인할 수도 있습니다:

Windows: “설정” → “네트워크 및 인터넷” → “프록시”에서 주소가 127.0.0.1이고 포트가 7893인지 확인하세요.
macOS: “시스템 설정” → “네트워크” → 현재 네트워크 → “세부사항” → “프록시”에서 웹 프록시와 보안 웹 프록시 포트를 확인하세요.
브라우저 확장 프로그램, 개발 도구, 명령줄 프로그램에 프록시 주소를 별도로 지정했다면 7890도 7893으로 변경해야 합니다.

명령줄 환경 변수에도 이전 값이 남아 있을 수 있습니다. 새 혼합 포트를 사용하는 예시는 다음과 같습니다:

http_proxy=http://127.0.0.1:7893
https_proxy=http://127.0.0.1:7893
all_proxy=socks5://127.0.0.1:7893

환경 변수 설정 문법은 운영체제와 터미널에 따라 다릅니다. 중요한 것은 클라이언트 화면의 포트 숫자만 확인하지 말고 모든 호출 경로를 점검하는 것입니다.

TUN 모드에서도 수신 포트 충돌을 처리해야 합니다

TUN 모드는 가상 네트워크 인터페이스를 통해 시스템 트래픽을 받지만, 그렇다고 mixed-port 충돌을 무시할 수 있는 것은 아닙니다. 설정에 mixed-port: 7890이 선언되어 있으면 커널은 일반적으로 해당 수신기를 계속 생성하려고 합니다. 포트 바인딩에 실패하면 커널 시작이 중단되거나 일부 명시적 프록시 기능을 사용할 수 없게 될 수 있습니다.

TUN에만 의존한다면 클라이언트와 커널 설정에 따라 필요하지 않은 명시적 프록시 수신을 제거할 수 있습니다. 그러나 그래픽 클라이언트, 브라우저 확장 프로그램, 로컬 네트워크 장치는 여전히 mixed-port를 사용할 수 있습니다. 변경하기 전에 수동 프록시 호출이 있는지 확인하세요. TUN의 자동 라우팅, 엄격한 라우팅, DNS 하이재킹은 별도의 설정이므로 7890을 바꾸는 것으로 올바른 TUN 설정을 대신해서는 안 됩니다.

allow-lan: true를 활성화하면 클라이언트가 0.0.0.0:7893에서 수신 대기해 로컬 네트워크 장치의 접근을 허용할 수 있습니다. 로컬에서만 사용할 때는 allow-lan: false를 유지하거나 수신 주소를 루프백 인터페이스로 제한하세요. 로컬 네트워크 접근을 허용하는지와 관계없이 같은 주소 계열에서는 포트가 고유해야 합니다.

새 포트가 실제로 적용됐는지 확인

1단계: 수신 대기 상태 확인

커널을 재시작한 후 새 포트를 다시 확인하세요. Windows에서는 다음을 사용합니다:

netstat -ano | findstr :7893

macOS에서는 다음을 사용합니다:

lsof -nP -iTCP:7893 -sTCP:LISTEN

Linux에서는 다음을 사용합니다:

ss -ltnp 'sport = :7893'

mihomo 또는 Clash 커널이 LISTEN 상태이고 이전 포트 7890을 해당 인스턴스가 더 이상 사용하지 않는 것이 정상입니다.

2단계: 프록시 진입점 직접 테스트

curl이 설치되어 있다면 시스템 프록시 설정을 우회하고 새 포트를 직접 지정할 수 있습니다:

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

HTTP 응답 헤더가 반환되면 로컬 프록시 진입점이 요청을 받을 수 있다는 뜻입니다. Connection refused가 표시되면 새 포트가 수신 대기 중이 아니거나 주소가 잘못된 것입니다. 연결은 되지만 요청 시간이 초과되면 포트를 계속 바꾸지 말고 노드 상태, 전략 그룹 선택, DNS, 규칙을 확인하세요.

3단계: 클라이언트 로그 확인

“로그” 페이지에서 error, listen, bind 등의 키워드를 필터링하세요. 정상적으로 시작된 후에는 7890 또는 7893에 대한 바인딩 오류가 다시 나타나지 않아야 합니다. 오류가 127.0.0.1:9090으로 바뀌었다면 mixed-port는 해결되었지만 컨트롤 인터페이스가 다른 인스턴스와 충돌하는 것입니다. 같은 방법으로 external-controller를 확인하세요.

7890 충돌이 반복될 때 확인할 목록

클라이언트 창을 닫은 뒤 알림 영역, 메뉴 막대, 작업 관리자에 커널 프로세스가 계속 남아 있는지 확인하세요.
Clash 또는 mihomo 그래픽 클라이언트를 두 개 설치했고 모두 시작 프로그램으로 설정되어 있는지 확인하세요.
Windows에서는 “작업 관리자” → “시작 앱”과 서비스 목록을 확인하고, Linux에서는 systemd를, macOS에서는 로그인 항목과 백그라운드 항목을 확인하세요.
구독 업데이트 후 실행 설정의 mixed-port가 7893에서 7890으로 돌아가지 않았는지 확인하세요.
시스템 프록시, 브라우저 확장 프로그램, 터미널 환경 변수, 로컬 네트워크 장치가 현재 포트를 사용하는지 확인하세요.
9090, 1053, 7891 등 다른 수신 포트도 확인해 한 포트를 해결한 뒤 다음 충돌로 다시 막히지 않도록 하세요.
예를 들어 mixed는 7893, 컨트롤 인터페이스는 9093, DNS는 1053처럼 명확한 포트 계획을 유지해 여러 인스턴스가 포트를 재사용하지 않도록 하세요.

포트 사용 문제는 일정한 순서로 처리해야 합니다. 먼저 로그에서 정확한 포트를 읽고, 시스템 도구로 PID를 확인한 다음, 점유 프로세스를 유지해야 하는지 판단하고 잔여 프로세스를 종료할지 설정을 변경할지 결정하세요. mixed-port를 변경한 뒤에는 시스템 프록시와 모든 수동 프록시 호출 경로도 함께 업데이트해야 합니다. YAML만 바꾸고 호출 포트를 업데이트하지 않으면 “시작 실패”가 “커널은 정상이나 앱이 인터넷에 연결되지 않음”으로 바뀌어 후속 문제 해결이 더 어려워집니다.