「address already in use」가 뜨는 이유

TCP(또는 유사 리스닝 소켓)는 동일 주소+포트에 하나의 수신자만 둘 수 있는 경우가 대부분입니다. Clash·Mihomo Core가 127.0.0.1:7890 같은 mixed-port에 바인드하려는데, 이미 다른 프로세스(옛 clash·mihomo·v2rayN·스마트 DNS·개발용 로컬 서버)가 잡고 있으면, 운영체제는 EADDRINUSE를 돌려주고 GUI에는 영어·한글 섞인 “bind: address already in use”·“Only one usage of each socket address” 류가 뜹니다. 이는 구독 404/403·노드 품질이 아니라 로컬 점유 이슈입니다. 코어를 올리기 전·직후 최초 기동이 실패하는지 로그 첫 몇 줄을 먼저 읽는 편이 분석이 빠릅니다.

IPv4 vs IPv6(0.0.0.0 vs ::)나 allow-lan·bind-address를 바꾸면, 같은 “포트 숫자”라도 서로 다른 소켓이 될 수 있어, 겉으론 비슷한 숫자인데 둘 다 떠 있거나, 반대로 한쪽만 막혀 다른 주소에서 다시 bind 실패가 날 수 있습니다. LAN 공유·bind를 켠 뒤에만 터지면, 내부/외부 인터페이스 중 어디에 겹쳤는지 의심하세요(합법·허가된 사설망 전제).

ℹ 참고: external-controller·external-ui·DNS 인바운드(dns.listen 일부)도 따로 포트를 씁니다. 메시지에 어느 포트에서 났는지가 찍혀 있으면 그 숫자만 우선 추적하세요.

mixed-port·port·SOCKS·external-controller 순서

구버전·간단 템플릿은 port(HTTP)와 socks-port를 따로 쓰고, Meta 계열이 권장하는 조합은 mixed-port에 HTTP+SOCKS를 한꺼번에 열는 패턴이 많습니다. 둘 다 켜 둔 YAML이면(예: mixed-port: 7890과 동시에 port: 7890) 의도와 다르게 한 숫자가 중복돼 시작 단계에서 쓰러질 수 있으니, 러닝 파일에서 port/socks-port/mixed-port 세 줄을 먼저 훑는 습관이 좋습니다. GUI(예: Clash Verge Rev) 쪽 최신 템플릿은 Windows 11 Clash Verge Rev·TUN 글 흐름으로 구독을 넣는 경우가 많은데, 그때 클라이언트가 external-controller: 127.0.0.1:9090 류를 이미 켜 둔 다른 서비스와 겹쳤는지도 같이 봅니다. 터미널·Docker가 같은 포트에 붙이려 할 때 흐름은 비슷합니다.

코어 키 이름이 헷갈릴 때는 Clash Meta·Mihomo 업그레이드로 필드·버전을 먼저 맞추는 편이, “YAML은 맞는데 왜” 같은 시간을 줄여 줍니다.

Windows 11: netstat·PowerShell·작업 관리자로 PID

관리자/일반 PowerShell이나 cmd에서 netstat -ano | findstr :7890 처럼(숫자는 본인 설정으로) LISTENING 행 끝의 PID를 읽습니다. Get-NetTCPConnection -LocalPort 7890 -State Listen + Get-Process -Id …로도 이름까지 이어갈 수 있어, 숨은 clash·clash-meta·winws·다른 툴을 빠르게 식별합니다. 작업 관리자 → 세부 정보에서 PID로 찾은 뒤, 트레이에 남은 옛 아이콘 없이도 백그라운드로 붙잡는 경우를 종료(트리 주의)합니다.

Windows에서 WSL2·호스트 Clash는 다른 인터페이스에서 같은 포트를 쓰는지 자주 겹칩니다. WSL2가 localhost로 호스트 7890을 본다면, 호스트 쪽 리스닝이 하나만 확실한지(호스트·WSL 각각 netstat)를 나눠 보면, “WSL에선 되는데 UI에선” 같은 착시를 줄일 수 있습니다.

Windows: 중복 인스턴스·WSL2·흡수 경로

대표적인 실수는 (1) Clash for Windows 잔류 + Verge + 수동 mihomo가 같은 config.yaml·같은 포트를 동시에 올리려는 경우, (2) 개발·테스트 툴이 7890을 미리 쓰는 경우입니다. (1)이면 한 종류만 켜 두는 것이 정석이고, (2)면 개발 서버·클라 포트를 한쪽이 양보해야 합니다. 서비스·스케줄러·시작프로그램에 옛 Clash가 남아 있으면, 재로그인 때마다 다시 7890을 잡는 경우도 있으니, 작업에서 시작 위치(작업·서비스)까지 확인하세요.

방화벽은 보통 리스닝 점유를 막는 원인이 아닙니다(접속 거부 vs bind 실패는 로그 뉘앙스가 다름). 로그가 이미 뜬 뒤 아웃바운드에서 막힌다면 timeout·TLS 쪽이고, 시작 직후 한 줄이면 포트 쪽이 우선입니다.

macOS: lsof·netstat·활성 상태 표시기

터미널에서 lsof -nP -iTCP:7890 -sTCP:LISTEN (포트는 본인 값)로 PID·프로세스명이 한 번에 보입니다. sudo lsof -i :7890 는 권한·시스템 인터페이스가 섞인 경우에 유용할 수 있으나, 불필요한 sudo는 피하세요. netstat -anv -p tcp | grep 7890로 LISTEN을 교차해도 됩니다. 활성 상태 표시기에서 해당 프로세스를 강제 종료하기 전, 메뉴에 정상 종료(Quit)가 있으면 그것이 더 안전합니다. TUN·NE와 섞이면 macOS TUN·시스템 프록시 글의 맥락과 겹쳐 보일 수 있으나, bind 오류는 먼저 동일 IP:포트 점유부터 끊는 편이 좋습니다.

앱이 삭제됐는데도 포트가 남는다면(드물게), 빠른 사용자 전환·백그라운드 보조 프로세스·다른 클론(Preview 빌드)이 있는지, Activity Monitor의 샘플·퍼딧으로 프로세스 경로를 확인하세요. 재부팅은 마지막이지만, 개발/테스트 머신에선 가장 빠른 “전역 리셋”이 되기도 합니다.

mixed-port(및 socks-port) 옮기기·핫 리로드

점유 프로세스를 닫는 것이 맞다면(본인 Clash 중복·개발용 서버) 그렇게 하고, 정당히 둘 다 필요하다면 Clash 쪽 mixed-port: 7891 처럼 숫자를 옮깁니다. 로컬 Merge·GUI Override에만 적어 두는 경우, 구독이 덮어써 옛 7890이 남는지 최종 러닝 덤프로 확인하세요—흐름은 Meta mixin 글과 같이 읽는 편이 안전합니다. 숫자를 바꾼 뒤 시스템 프록시·브라우저·스크립트가 같이 옛 포트를 가리키면, UI는 연결된 것처럼 보이나 응답이 없는 상태가 됩니다. 종료 뒤 망/프록시 잔류는 포트 숫자를 바꾼 직후 딱 겹쳐 자주 터집니다.

hot-reload가 먹는다면 재시작 말로도 되고, “포트는 바꿨는데 코어가 재기동 안 했다”면 트레이·클라이언트의 다시 읽기·완전 종료를 누릅니다. Web UI·API가 9090을 쓰는데, 거기를 다른 앱이 먹고 있으면 대시보드는 열리지 않아도, mixed 7890은 열릴 수 있으니(또는 반대) 문구에 찍힌 포트별로 나눠 점검하세요.

Example: mixed-port in YAML (illustration) 
mixed-port: 7891
# port: 7890    # if unused, consider removing to avoid double-bind
# socks-port: 7891
external-controller: 127.0.0.1:9090
bind-address: '*'

(주석·키 이름은 사용 중인 코어·GUI 버전 문서에 맞춥니다. 위는 개념 예시입니다.)

검증: curl, Web UI, 로그

기동 성공 후(로그에 error 없이 listen 메시지가 보이는지), curl -I -x http://127.0.0.1:7891 http://www.gstatic.com/generate_204 같이(포트 맞출 것) HTTP 프록시 경로가 살아 있는지, 또는 SOCKS5면 curl의 --socks5-hostname로 같은 의미의 검증을 합니다. 웹에서만 안 되면 확장/프로파일 고정 프록시·PAC를 의심하고, 전 OS가 막히면 시스템 프록시·TUN 이중을 앞의 quit 글로 걷어갑니다. 이미 뜬 뒤 끊기면 연결 로그가 힌트고, 아예 안 뜨면 bind 쪽이 우선입니다.

external-controller·Secret이 맞다면, Yacd/Metacubexd로 정상 응답이면 코어는 돌고 있는 것이니, “브라우저만 7890”은 로컬 프록시 설정·확장을 의심합니다. 구독/캐시가 끼어 빈 노드·이상 URL로 리로드만 반복해도, 그건 구독 404/403과 연결됩니다(시작 성공 후 증상).

준수 알림

⚠ 정책·법률: 회사·학교·국가·서비스 약관이 요구하는 절차·승인 없이, 타인·공용·업무 PC에서 포트·프로세스를 강제 종료·프록시를 켤 수 있게 조작하는 것은 대상이 아닙니다. 본인 기기·허용된 네트워크에서만 적용하세요.

맺음말

Address already in use는 「왜 안 붙지?」보다 「누가 먼저 그 포트를 잡고 있나」에 답이 있습니다. Windows 11은 netstat·Get-NetTCPConnection로, macOS는 lsof로 PID를 잡고, mixed-port를 옮기거나 점유 프로세스를 정리한 뒤, curl·Web UI·로그로 다시 확인하면 반복이 줄어듭니다. 구독·TLS로 헷갈릴 땐 구독·캐시·연결 로그와 축을 나누세요.

→ Clash V.CORE를 사이트에서 내려받은 뒤, 한 포트씩 겹치지 않게 잡는 습관을 들이면, 기동 첫 화면만으로도 “오늘은 점유” vs “오늘은 망/노드”를 빨리 갈릴 수 있습니다(합법·본인 PC 전제).