어떤 메시지가 뜰 때 이 가이드를 쓰면 되나

Clash for Windows(또는 Mihomo 코어를 붙인 동일 계열 GUI)를 설치하거나 새 버전으로 교체한 뒤, 트레이 아이콘을 눌러도 코어가 올라오지 않거나 로그에 listen tcp … address already in use, bind: Only one usage of each socket address, 한글 환경에서는 각 소켓 주소에 대해 하나의 사용만 허용됩니다 같은 문구가 반복되는 경우가 있습니다. 또 다른 증상으로는 대시보드 API나 로컬 제어용 패널만 열리지 않고, 브라우저로 127.0.0.1의 특정 포트에 접속해도 연결이 거부되는 형태로 나타납니다.

이때 흔한 오해는 「구독이 깨졌다」거나 「노드 풀만 문제다」로 바로 넘어가는 것입니다. 그 전에 같은 포트를 이미 다른 프로세스가 쥐고 있는지를 확인해야 합니다. 예전에 백그라운드에 남은 Clash·프록시 클라이언트, 다른 VPN·개발 서버(예: 로컬 7890, 9090 대역), 혹은 업데이트 과정에서 이전 인스턴스가 완전히 종료되지 않은 경우가 대표적입니다. 본문에서는 Windows netstat으로 점유를 확인하고, 필요하면 external-controller나 mixed-port 등 제어 포트·프록시 포트를 바꿔 충돌을 피하는 순서를 한국어로만 정리했습니다. 시스템 프록시가 켜졌는데도 특정 앱만 직접 나가는 문제는 Windows 11 시스템 프록시·UWP 쪽 점검과 결이 다르므로, 우선은 포트 바인딩 실패부터 분리해 보세요.

Clash 쪽에서 먼저 의심할 포트들

설정 파일(보통 config.yaml)에는 여러 개의 리슨 포트가 등장합니다. 환경마다 이름과 기본값이 조금씩 다르지만, Windows 사용자가 자주 만나는 축은 다음과 같습니다. 첫째, mixed-port 또는 별도로 나뉜 port(HTTP)와 socks-port로 들어오는 로컬 프록시입니다. 둘째, 외부에서 코어를 제어하거나 대시보드가 붙기 위한 external-controller(예: 127.0.0.1:9090)입니다. 셋째, DNS 쪽을 Clash가 받도록 열어 둔 dns.listen 포트 등 부가 항목이 더해질 수 있습니다.

오류 메시지에 구체적인 포트 번호가 찍히면 그 번호만 집중해서 추적하면 됩니다. 번호가 보이지 않으면, 클라이언트 GUI의 설정 화면이나 최근에 수동으로 바꿔 둔 값을 확인한 뒤, 그 포트들을 순서대로 Windows netstat에 넣어 보면 됩니다. 한 가지 기억할 점은 127.0.0.1에만 바인딩한 포트와 0.0.0.0(모든 인터페이스)에 연 포트는 표시 형태가 다르게 나올 수 있다는 것입니다. 동일 PC 안에서의 충돌이 목적이라면 PID만 확실히 집어도 충분합니다.

ℹ️
참고: external-controller는 REST API로 전환·로그 조회 등을 할 때 쓰는 제어 포트입니다. 대시보드나 유틸이 이 주소를 가정해 두었다면, 포트를 바꾼 뒤에는 같은 주소로 맞춰 주어야 합니다. 반면 시스템 프록시로 쓰는 127.0.0.1:7890 같은 값은 설치·기본 문서와 함께 구독을 불러온 뒤에야 완성되는 경우가 많으니, 전체 흐름은 구독 가져오기 가이드와 짝지어 생각하면 덜 혼란스럽습니다.

1단계: 관리자 권한 없이도 되는 netstat 확인

가장 단순한 방법은 명령 프롬프트(cmd.exe)나 PowerShell을 연 뒤, 의심되는 포트 번호를 넣어 보는 것입니다. 예를 들어 제어용으로 9090을 쓰고 있다면 다음과 같이 실행합니다.

netstat -ano | findstr :9090

-a는 모든 연결·리슨 상태를, -n은 숫자 주소로, -o는 PID를 표시합니다. 출력의 마지막 열이 PID입니다. 한 행에 LISTENING과 함께 127.0.0.1:9090 또는 0.0.0.0:9090이 보이면 그 PID가 현재 포트를 사용 중인 프로세스입니다. findstr은 Windows에 기본 포함되어 있어 별도 설치가 없습니다.

PowerShell을 선호한다면 다음처럼 특정 로컬 포트만 필터링할 수도 있습니다.

Get-NetTCPConnection -LocalPort 9090 -ErrorAction SilentlyContinue | Format-Table -AutoSize

여기서 OwningProcess 값이 PID에 해당합니다. 여러 줄이 나오면 LISTEN 상태인 항목을 우선 확인하세요. 방화벽 제품이나 다른 프록시가 같은 포트를 잡고 있으면 이름만으로는 Clash인지 구분이 안 될 수 있으므로, 다음 단계에서 작업 관리자나 tasklist로 이미지 이름을 확인하는 것이 좋습니다.

2단계: PID가 가리키는 프로그램 확인과 종료

netstat으로 얻은 PID를 작업 관리자의「세부 정보」탭에서 찾거나, 명령 프롬프트에서 다음처럼 확인합니다.

tasklist /FI "PID eq 12345"

12345 부분은 실제 PID로 바꿉니다. 여기서 예상대로 이전 Clash·Mihomo·다른 GUI가 보이면, 트레이에서 완전히 종료한 뒤에도 남아 있을 수 있으니 다음 명령으로 강제 종료할 수 있습니다.

taskkill /PID 12345 /F
⚠️
주의: PID를 잘못 종료하면 다른 응용 프로그램이 갑자기 끊길 수 있습니다. 반드시 tasklist로 프로세스 이름을 확인한 뒤 진행하세요. 시스템 프로세스를 임의로 죽이지 않도록 합니다.

종료 후 다시 netstat -ano | findstr :원하는포트를 실행해 LISTENING 행이 사라졌는지 확인합니다. 사라졌다면 Clash 클라이언트를 다시 띄워 봅니다. 이때도 같은 오류가 난다면, 다른 포트 번호가 충돌 중이거나 설정 파일에 중복 리슨이 있을 수 있으니 로그에 나온 다음 포트를 같은 방식으로 반복하면 됩니다.

3단계: 설정에서 external-controller와 프록시 포트 바꾸기

잘 쓰지 않는 다른 프로그램이 아니라 본인이 예전에 지정한 포트가 계속 겹치는 환경이라면, 충돌이 덜한 번호로 바꾸는 편이 빠릅니다. 텍스트 편집기로 프로필 YAML을 열어 다음 항목들을 검토합니다.

  • external-controller: 예를 들어 127.0.0.1:9090을 127.0.0.1:9091처럼 여유 있는 포트로 변경합니다. 외부 노출을 막기 위해 127.0.0.1에만 바인딩하는 것이 일반적입니다.
  • mixed-port 또는 port / socks-port: 시스템 프록시나 앱이 가리키는 로컬 포트와 일치해야 하므로, 여기를 바꾼 뒤에는 Windows의 수동 프록시 설정이나 브라우저·클라이언트의 프록시 주소도 같이 맞춥니다.

GUI 기반 클라이언트는 메뉴의「설정」「코어 설정」처럼 이름이 다를 수 있으나, 저장 시 결국 동일한 키가 YAML에 반영됩니다. 저장 후에는 코어 재시작 또는 앱 완전 종료 후 재실행을 한 번 거쳐야 합니다. 포트를 바꾼 뒤에는 예전 주소(http://127.0.0.1:9090 등)로 붙어 있던 북마크나 스크립트가 있다면 함께 고쳐야 합니다.

업그레이드 직후 이전 버전의 사용자 데이터 폴더에 남은 두 개의 설정이 서로 다른 포트를 가리키며 충돌하는 경우도 있습니다. 이때는 클라이언트가 실제로 읽는 프로필 경로를 확인하고, 편집 중인 파일이 맞는지 한 번만 점검하면 재발을 줄일 수 있습니다. 메이저 버전 마이그레이션 맥락은 Clash Meta 업그레이드 가이드와 연결해 읽으면 도움이 됩니다.

4단계: 정상 기동 여부 확인하기

다음 체크리스트는 복사해 두고 순서대로만 지나가도 됩니다. 첫째, 트레이 메뉴에서 코어가「실행 중」으로 바뀌었는지 봅니다. 둘째, 로그 창에 더 이상 같은 포트 오류가 반복되지 않는지 확인합니다. 셋째, 브라우저나 curl로 로컬 프록시 포트(예: mixed-port로 쓰는 7890)에 맞는 테스트 요청을 해 볼 수 있습니다. 넷째, external-controller를 바꿨다면 새 주소로 API 문서에 나온 간단한 엔드포인트(예: 버전 정보)를 호출해 응답이 오는지 봅니다.

이 과정까지 끝났는데도 간헐적으로만 같은 메시지가 남는다면, 다른 보안 소프트웨어가 동일 포트를 가로채거나, 예약된 작업 스크립트가 주기적으로 서버를 띄우는지 의심해 볼 수 있습니다. 반대로 한번 포트를 정리한 뒤에는 같은 문제가 크게 줄어드는 경우가 많아, Clash 포트 충돌 검색으로 이 페이지를 연 사용자에게는「재부팅 전에 netstat 한 번」이 가장 비용 대비 효과가 큽니다.

한눈에 보는 순서

  1. 로그에서 포트 번호를 확인하거나, 설정에 적힌 external-controller·mixed-port 등 후보를 적는다.
  2. netstat -ano | findstr :포트로 PID를 찾고, tasklist로 프로세스 이름을 확인한다.
  3. 이전 Clash·타 프로그램이면 taskkill 또는 트레이에서 완전 종료 후 netstat로 LISTENING이 사라졌는지 본다.
  4. 필요하면 YAML에서 제어·프록시 포트를 바꾸고, 시스템 프록시·북마크 주소를 동일하게 맞춘 뒤 재실행한다.
✅
팁: 자주 쓰는 포트 번호를 메모장에 적어 두고, 업데이트 후에는 그 목록만 순서대로 netstat에 넣어 보면 원인 분리 시간이 줄어듭니다.

맺음말

Clash 계열 클라이언트는 규칙·구독·대시보드를 한곳에 모아 두기 때문에, 포트만 정상적으로 열리면 이후 단계는 비교적 직관적으로 이어집니다. 그런 의미에서 address already in use는 설정 품질 문제라기보다 운영체제 자원(포트) 경합에 가깝습니다. Windows netstat으로 점유를 확인하고, external-controller를 포함한 리슨 주소를 정리하면 같은 증상을 빠르게 넘길 수 있습니다.

동일한 PC에서 여러 프록시 도구를 번갈아 쓰는 경우에도 이 절차는 반복됩니다. GUI로 상태와 로그를 한 화면에서 볼 수 있다는 점은 다른 방식보다 원인 파악에 유리한 편입니다. 최신 빌드와 설치 패키지는 Clash 공식 다운로드 페이지에서 받을 수 있습니다. → Clash를 무료로 내려받아 Windows 환경에서 포트 설정을 맞춘 뒤 다시 실행해 보세요.