2026-09-27 문제 해결 읽는 시간 약 10분

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

시스템 명령으로 7890 등 포트를 점유한 프로세스를 확인하고, 종료할지 포트를 바꿀지 판단하는 방법과 mixed-port 변경 후 시스템 프록시·브라우저 설정을 동기화하는 방법을 안내합니다.

먼저 확인할 사항: 리스닝에 실패했나요, 프록시 주소가 잘못됐나요?

다음 순서로 확인하세요. 점유 프로세스 확인 → 기존 인스턴스 종료 또는 포트 변경 → 프록시 설정 동기화 → 리스닝 및 요청 확인. 웹페이지가 열리지 않는다고 클라이언트를 바로 재설치하지 마세요. 포트 충돌은 로컬 리스닝 단계에서 발생하며, 일반적으로 구독 만료나 노드 지연과는 직접적인 관련이 없습니다.

7890은 흔히 사용하는 설정값일 뿐, Clash나 mihomo가 반드시 써야 하는 포트는 아닙니다. 현재 적용된 필드에 따라 클라이언트에서 HTTP 프록시 포트나 혼합 포트로 사용할 수 있습니다. 먼저 클라이언트의 로그 화면을 열고 listen, bind, 포트 번호가 포함된 오류를 찾아보세요.

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

위와 같은 오류는 해당 주소의 TCP 포트에 다시 바인딩할 수 없다는 뜻입니다. Windows에서는 “일반적으로 각 소켓 주소는 한 번만 사용할 수 있습니다”라는 메시지가 표시될 수도 있습니다. 로그에 permission denied 또는 “액세스 권한이 없습니다”라고 나오면 포트 예약이나 시스템 정책 등의 제한도 확인해야 합니다. 이 경우 기존 프로세스가 포트를 점유했다고 단정할 수 없습니다.

로그에 바인딩 실패가 명확히 표시됨: 먼저 아래 시스템 명령을 실행해 리스닝 중인 프로세스를 찾으세요.
커널은 정상적으로 리스닝하지만 브라우저에서 프록시 연결 실패가 표시됨: 브라우저와 시스템 프록시가 여전히 이전 포트를 가리키는지 먼저 확인하세요.
일부 웹사이트만 열리지 않음: 규칙, DNS, 노드를 추가로 확인하고 로컬 포트를 반복해서 바꾸지 마세요.

Windows: PID로 7890을 점유한 프로그램 찾기

방법 1: PowerShell에서 리스닝 포트 확인

Windows 10 또는 Windows 11에서 PowerShell을 열고 다음 명령을 실행하세요. 결과가 비어 있으면 이번 조회에서 해당 TCP 포트를 리스닝하는 프로세스를 찾지 못한 것입니다. 권한 부족 메시지가 나오면 관리자 권한으로 터미널을 다시 실행하세요.

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

OwningProcess 열의 프로세스 번호를 기록하세요. 조회 결과가 6420이라고 가정하고 프로세스 이름, 경로, 시작 명령을 확인해 보겠습니다. 이 번호는 예시일 뿐입니다. 실제 작업에는 현재 PC에서 조회한 PID를 사용하세요.

Get-Process -Id 6420 | Select-Object Id, ProcessName, Path
Get-CimInstance Win32_Process -Filter "ProcessId = 6420" |
  Select-Object ExecutablePath, CommandLine

이름에 Clash가 포함되어 있는지만 확인해서는 안 됩니다. 데스크톱 인터페이스와 커널은 별도의 프로세스인 경우가 많습니다. 같은 mihomo.exe도 트레이 클라이언트, Windows 서비스, 직접 실행한 명령에 의해 각각 시작될 수 있습니다. 실행 파일 경로와 시작 인수를 확인하면 어떤 설치본에 속하는지 판단하는 데 도움이 됩니다.

방법 2: 명령 프롬프트에서 확인

netstat -ano -p tcp | findstr ":7890"
tasklist /FI "PID eq 6420"

netstat 결과는 직접 확인해야 합니다. '로컬 주소' 열의 포트가 정확히 7890이고 상태가 LISTENING인 행을 찾으세요. 원격 주소에 7890이 표시된 경우, 상태가 ESTABLISHED인 경우, 로컬 포트가 78901인 경우는 모두 다른 상황입니다.

macOS 및 Linux: 리스닝 프로세스와 백그라운드 서비스 확인

macOS: lsof로 TCP 리스닝 확인

터미널을 열고 7890을 리스닝하는 프로그램을 조회하세요. 일반 사용자 권한으로 전체 정보가 표시되지 않으면 sudo를 추가하세요.

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

결과에서 COMMAND는 프로그램 이름, PID는 프로세스 번호, NAME은 리스닝 주소입니다. 트레이 앱을 종료한 뒤 다시 명령을 실행해 보세요. 그래도 리스닝이 계속되면 별도로 실행 중인 커널이나 백그라운드 서비스가 있을 수 있습니다. 그렇다고 앞서 앱을 종료한 작업이 아무 효과도 없었다는 뜻은 아닙니다.

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

sudo ss -ltnp 'sport = :7890'

-l은 리스닝 소켓만, -t는 TCP만 표시하고, -n은 포트를 숫자로 표시하며, -p는 관련 프로세스를 표시합니다. UDP를 확인하려면 아래 명령을 별도로 실행하세요. TCP와 UDP는 서로 다른 전송 프로토콜이므로 UDP 조회 결과만으로 TCP 포트가 점유됐다고 판단할 수 없습니다.

sudo ss -lunp 'sport = :7890'

프로그램을 종료한 뒤 바로 다시 나타난다면 systemd, 사용자 서비스 또는 다른 프로세스 관리 도구가 자동으로 실행하는지 확인하세요. 실제 서비스 유닛을 확인한 다음 해당 서비스를 중지해야 하며, 강제 종료를 반복해서는 안 됩니다. 컨테이너를 사용한다면 호스트 포트 매핑도 확인하세요. 컨테이너 두 개가 각각 내부 7890을 리스닝하는 것은 가능하지만, 동일한 호스트 주소의 7890을 두 컨테이너에 동시에 매핑할 수는 없습니다.

기존 프로세스를 종료할까요, mixed-port를 7891로 바꿀까요?

판단 기준은 점유 중인 프로세스를 계속 실행해야 하는지입니다. 먼저 시작한 프로세스가 무조건 옳은 것은 아닙니다. 기존 클라이언트가 중복 실행된 경우 트레이 메뉴에서 정상 종료하세요. 계속 실행해야 하는 다른 프록시나 개발 서비스라면 현재 Clash 인스턴스의 포트를 바꾸세요.

확인된 상황	권장 조치	확인할 사항
기존 클라이언트 중복 실행	기존 클라이언트 정상 종료	시작 프로그램 중복 등록 여부 확인
인터페이스를 종료했지만 서비스는 계속 실행 중	확인 후 해당 클라이언트나 서비스 관리 도구에서 중지	서비스가 커널을 자동으로 다시 실행할 수 있음
다른 필수 프로그램이 7890을 리스닝 중	현재 mixed-port를 7891로 변경	7891을 사용할 수 있는지 먼저 확인
리스닝 프로세스가 없는데도 액세스 거부가 표시됨	포트 예약 및 권한 제한 확인	시스템 예약 항목을 무작정 삭제하지 않기

프로세스의 정체를 확인하고 필요한 작업을 저장한 뒤에만 종료를 고려하세요. 먼저 프로그램 자체의 종료 기능을 사용하세요. 명령줄에서 실행한 커널은 해당 터미널에서 Ctrl + C를 누르면 됩니다. Windows의 taskkill /PID 6420 /F는 강제 종료 명령이므로 정상 종료가 실패한 경우에만 사용하세요. 예시 PID를 그대로 복사하지 마세요.

Windows에서 리스닝 프로세스가 검색되지 않는데도 액세스 권한 오류가 계속되면 TCP 제외 포트 범위를 확인하세요. 가상화나 컨테이너 관련 구성 요소가 사용 가능한 포트에 영향을 줄 수 있습니다. 예약 항목이 확인되더라도 시스템 예약 범위를 수정하기보다는 비어 있는 포트를 사용하는 편이 일반적으로 안전합니다.

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

mixed-port 변경: 필드를 올바르게 수정하고 설정을 유지하기

mixed-port는 하나의 리스닝 포트에서 HTTP와 SOCKS 프록시 연결을 모두 받습니다. 구독 주소도, 노드 서버 포트도, 대시보드 제어 인터페이스 포트도 아닙니다. 현재 port나 socks-port를 별도로 사용 중이라면 mixed-port만 변경해도 기존 연결 지점은 바뀌지 않을 수 있습니다.

먼저 7891을 사용할 수 있는지 확인한 다음 현재 설정을 백업하세요. 아래 내용은 설정 파일 최상위에 추가할 수 있는 조각이며, 노드와 규칙을 포함한 전체 구독 설정이 아닙니다. 로컬에서만 사용할 프록시라면 로컬 접근 범위를 유지하세요.

config.yaml: 최상위 리스닝 필드

mixed-port: 7891
allow-lan: false
bind-address: 127.0.0.1

최상위 들여쓰기 유지: mixed-port를 dns:, tun: 또는 노드 정의 안에 넣지 마세요.
기존 키 교체: 파일 끝에 같은 이름의 필드를 추가로 넣지 마세요. 키가 중복되면 파싱 오류나 예상치 못한 동작이 발생할 수 있습니다.
개별 포트 확인: port: 7890이 남아 있으면 기존 HTTP 리스닝 충돌이 계속될 수 있습니다. 필요에 따라 기존 리스닝 필드를 수정하거나 삭제하세요.
제어 포트 구분: external-controller는 클라이언트나 대시보드에서 커널을 제어하는 데 사용하며, 브라우저용 HTTP 프록시 주소로 쓸 수 없습니다.

저장했는데도 7890으로 되돌아가는 이유

그래픽 클라이언트는 전역 포트 설정, 설정 덮어쓰기 또는 설정 병합을 통해 최종 YAML을 생성할 수 있습니다. 구독 파일을 직접 수정한 내용도 다음 업데이트 때 덮어써질 수 있습니다. 따라서 클라이언트에서 제공하는 지속형 포트 설정이나 덮어쓰기 기능을 우선 사용하세요. 메뉴 이름은 클라이언트 버전에 따라 다르므로 특정 클라이언트의 설정 경로를 모든 Clash 클라이언트에 그대로 적용해서는 안 됩니다.

변경 후 클라이언트에서 제공하는 설정 다시 불러오기나 커널 재시작을 실행하고, 로그에 새 리스닝 주소가 표시되는지 확인하세요. 인터페이스에 7891이 표시되는 것은 설정이 저장됐다는 뜻일 뿐, 커널이 해당 포트에 정상적으로 바인딩됐다는 뜻은 아닙니다. 필드의 의미는 YAML 안내서에서 확인할 수 있습니다.

시스템 프록시·브라우저·터미널의 이전 포트 동기화

포트를 7890에서 7891로 바꾸면 커널은 새 연결 지점만 제공하며, 외부 앱의 설정까지 모두 자동으로 바뀌지는 않습니다. 커널은 정상적으로 시작됐지만 Windows 시스템 프록시는 여전히 127.0.0.1:7890을 사용하는 경우가 흔합니다. 이때 시스템 프록시를 따르는 브라우저는 연결 실패를 표시합니다.

시스템 및 브라우저 설정 확인 위치

Windows 11: '설정' → '네트워크 및 인터넷' → '프록시' → '수동 프록시 설정' → '프록시 서버 사용' 옆의 '설정'에서 주소와 포트를 확인하세요. 클라이언트가 시스템 프록시를 관리한다면 먼저 클라이언트에서 '시스템 프록시'를 껐다가 다시 켠 다음, 이 화면에서 적용된 값을 확인하세요.
macOS: '시스템 설정' → '네트워크' → 현재 네트워크 연결의 '세부사항' → '프록시'에서 활성화된 웹 프록시, 보안 웹 프록시 또는 SOCKS 프록시를 각각 확인하세요. 포트는 실제 리스닝 주소와 일치해야 합니다.
Firefox: '설정' → '일반' → '네트워크 설정' → '설정'으로 이동하세요. '시스템 프록시 설정 사용'을 선택하면 시스템 설정을 따릅니다. '수동 프록시 구성'을 선택했다면 포트를 별도로 변경해야 합니다.
Chromium 계열 브라우저: 일반적으로 시스템 프록시를 따르지만, 시작 옵션이나 프록시 확장 프로그램이 설정을 덮어쓸 수 있습니다. 특정 브라우저에서만 문제가 발생한다면 이처럼 별도로 적용되는 설정을 확인하세요.

자동 프록시 설정 스크립트(PAC)를 사용한다면 스크립트가 반환하는 PROXY 127.0.0.1:7890이 이전 값인지도 확인하세요. HTTP 프록시는 HTTPS 사이트 접속을 위한 CONNECT 터널도 지원합니다. 접속 대상이 HTTPS 사이트라고 해서 로컬 프록시 주소를 임의로 https://127.0.0.1:7891로 바꾸지 마세요.

터미널 환경 변수는 별도로 업데이트해야 합니다

터미널 프로그램은 데스크톱 시스템 프록시 대신 HTTP_PROXY, HTTPS_PROXY 또는 ALL_PROXY를 읽을 수 있습니다. PowerShell의 현재 세션에서 HTTP 프록시 주소를 다음과 같이 변경할 수 있습니다.

$env:HTTP_PROXY = "http://127.0.0.1:7891"
$env:HTTPS_PROXY = "http://127.0.0.1:7891"

macOS 또는 Linux에서 흔히 사용하는 셸에서는 다음과 같이 설정할 수 있습니다. 이전에 대소문자가 다른 프록시 변수, ALL_PROXY 또는 도구 자체 설정도 지정했다면 7890이 남아 있는지 확인하세요. 프로그램마다 설정 우선순위가 다를 수 있습니다.

export http_proxy=http://127.0.0.1:7891
export https_proxy=http://127.0.0.1:7891

마지막 확인: 리스닝·요청·재시작 후 상태 점검

새 포트 리스닝 확인: 앞서 사용한 조회 명령에서 7890을 7891로 바꾸고, 리스닝 프로세스가 현재 클라이언트에 속하는지 확인하세요. 이전 포트가 여전히 리스닝 중이라면 계속 유지해야 하는 프로그램인지 판단하세요.
프록시를 명시해 요청 보내기: 브라우저 캐시에 남은 페이지에만 의존하지 마세요. 아래 명령으로 새 주소에 연결할 수 있는지 확인하세요.
설정 유지 여부 확인: 클라이언트를 정상 종료한 뒤 다시 시작하고 포트를 확인하세요. 구독을 업데이트한 뒤에도 지속형 덮어쓰기 설정이 유지되는지 확인하세요.

Windows에서는 curl.exe를 사용하면 일부 PowerShell 환경에서 발생하는 curl 별칭 차이를 피할 수 있습니다. macOS와 Linux에서는 curl을 그대로 사용하세요.

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

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

여기서 5초 연결 시간 초과와 15초 전체 시간 초과는 테스트 한도이며 속도를 보장하지 않습니다. 127.0.0.1:7891에 연결할 수 없다는 메시지가 나오면 리스닝과 설정 적용 여부를 확인하세요. 프록시 터널이 연결된 뒤 TLS, 업스트림 연결 또는 대상 사이트 응답에서 오류가 발생한다면 점검 대상은 노드, 규칙 또는 대상 사이트입니다. 200 Connection established가 표시돼도 요청이 완전히 성공한 것은 아닙니다. 이후 출력도 확인하세요.

프록시를 명시한 요청이 성공하면 명령의 프록시 옵션을 제거하고 브라우저에서 시스템 프록시 경로를 확인하세요. 로컬 연결 포트를 변경해도 규칙 모드의 라우팅 결과가 달라지거나 노드 속도가 빨라지지는 않습니다. 이 점검을 마치면 '로컬 포트 충돌 해결'과 '별도의 네트워크 문제'를 구분해 불필요한 재설치를 피할 수 있습니다. 다른 연결 문제는 문제 해결 안내에서 확인하세요.