증상: “같은 Wi-Fi인데 왜 프록시만 안 될까?”
한 대의 Windows PC나 노트북에서 Clash·mihomo 계열 클라이언트를 실행해 구독과 규칙이 잘 동작하는데, 스마트폰·태블릿·옆자리 맥/리눅스에서 HTTP·SOCKS 프록시로 같은 주소를 넣으면 타임아웃이 나거나 “연결할 수 없음”만 반복되는 경우가 흔합니다. 이때 흔한 오해는 “구독이나 노드 문제”인데, 실제로는 랜에서 포트가 열려 있지 않거나 OS·공유기가 기기 간 트래픽을 막고 있는 경우가 많습니다. 본문에서는 allow-lan, bind-address, mixed-port(또는 분리된 HTTP·SOCKS 포트)와 Windows 방화벽, AP 격리까지 한 줄기로 점검하는 순서를 잡아 드립니다. 단일 PC 설치 흐름은 Windows 튜토리얼과 맞춰 보시고, 시스템 전체를 코어에 태우는 주제는 TUN 모드 가이드를 참고하면 전체 그림이 분리됩니다.
1단계: 코어가 어디에 “귀를 기울이고” 있는가 (bind-address)
프록시 포트는 기본적으로 127.0.0.1(루프백)에만 바인딩되는 경우가 많습니다. 이 상태에서는 본기기 안의 앱만 접속할 수 있고, 같은 공유기에 붙은 다른 기기의 패킷은 도달하지 않습니다. 랜 공유를 하려면 LAN IP(예: 192.168.0.23) 또는 모든 인터페이스를 의미하는 *에 바인딩해야 합니다. 설정 키 이름은 bind-address로 쓰이는 경우가 많으며, GUI 클라이언트에는 “로컬만 허용” 같은 토글로 숨겨져 있을 수 있습니다. bind-address를 LAN 쪽으로 넓혔다면, 동시에 신뢰할 수 있는 가정·사무실 네트워크인지 다시 생각해 보세요. 카페·기숙사 공용 Wi-Fi처럼 낯선 단말이 같은 세그먼트에 있으면, 프록시 포트를 열어두는 것 자체가 위험해질 수 있습니다.
# Sketch — expose proxy on all interfaces (adjust port to your profile)
mixed-port: 7890
bind-address: '*'
mixed-port는 하나의 포트에서 HTTP와 SOCKS를 함께 받는 구성으로, 모바일·데스크톱에서 “프록시 주소 + 포트”만 넣기에 편합니다. 일부 구성에서는 HTTP용 port와 SOCKS용 socks-port가 나뉘어 있으니, 기기 쪽 설정 화면이 어떤 프로토콜을 요구하는지와 맞춰야 합니다. 기능 개요는 문서 개요에서 함께 확인해 보세요.
2단계: allow-lan으로 “외부에서의 접속”을 허용하는지
바인딩 주소를 넓혀도, 코어 설정에 allow-lan: false가 남아 있으면 랜에서 들어오는 연결을 거절하는 동작을 하는 빌드·템플릿이 있습니다. 반대로 allow-lan: true로 두면 같은 서브넷의 기기가 프록시 포트에 붙을 수 있게 됩니다. YAML을 직접 고칠 때는 들여쓰기와 상위 키 위치를 클라이언트가 덮어쓰지 않는지 확인하세요. GUI에서 “LAN 허용”을 켠 뒤에도 안 되면, 실제로 적용된 런타임 설정(프로필 미리보기·로그에 찍힌 설정)을 한 번 더 확인하는 것이 좋습니다.
allow-lan: true
mixed-port: 7890
bind-address: '*'
3단계: PC에서 리스닝이 열렸는지 확인
Clash를 실행한 뒤, 프록시를 띄운 PC에서 운영체제 도구로 해당 포트가 0.0.0.0 또는 LAN IP에 LISTEN 상태인지 확인합니다. Windows에서는 리소스 모니터의 네트워크 탭이나 netstat 계열 출력으로 빠르게 볼 수 있습니다. 127.0.0.1:7890만 보이면 다른 기기는 절대 붙지 않으니, 앞 단계의 bind-address·GUI 옵션을 다시 조정해야 합니다. 반대로 0.0.0.0:7890 또는 192.168.x.x:7890이 보이면 코어 쪽은 통과한 것이고, 다음은 방화벽·공유기 쪽입니다.
4단계: Windows Defender 방화벽 인바운드 규칙
Windows는 기본적으로 들어오는 연결을 막는 정책이 강합니다. Clash 실행 파일이나 코어 바이너리 이름으로 인바운드 TCP 허용 규칙을 추가해야 랜의 다른 기기가 프록시 포트에 SYN을 보낼 수 있습니다. “개인 네트워크” 프로필에만 적용하고 공용 프로필에서는 막는 식으로 좁히면 조금 더 안전합니다. 방화벽을 잠시 끄면 연결이 되고 켜면 안 된다면, 원인이 거의 확실히 인바운드 규칙입니다. 회사 PC는 그룹 정책으로 사용자 규칙 추가가 막혀 있을 수 있으니, 그 경우 IT 정책을 따르는 것이 맞습니다.
macOS·Linux 방화벽과 보안 소프트웨어
맥에서 방화벽이나 Little Snitch류 앱이 켜져 있으면, Clash 프로세스에 대해 수신 연결 허용이 필요합니다. 리눅스에서는 ufw, firewalld, 혹은 클라우드 이미지에 기본으로 깔린 iptables 규칙이 동일한 역할을 합니다. 백신·엔드포인트 보안 제품이 “로컬 서버” 형태의 리스닝을 차단하는 사례도 있으니, 방화벽을 통과했는데도 안 되면 그 계열도 의심해 보세요.
5단계: 공유기 AP 격리·게스트 Wi-Fi·이중 NAT
최신 공유기에는 AP 격리(클라이언트 간 통신 차단), 게스트 네트워크 전용 SSID가 있습니다. PC는 메인 SSID, 휴대폰은 게스트에 붙어 있으면 서로 ping도 안 되고 프록시도 당연히 안 됩니다. 또한 리피터·메시 노드 뒤에 이중으로 NAT이 걸린 토폴로지에서는 “같은 Wi-Fi 같아 보여도” 브로드캐스트·직접 IP 경로가 기대와 다를 수 있으니, 가능하면 PC와 테스트 기기를 동일 SSID·동일 서브넷에 두고, PC의 IPv4 주소를 고정하거나 DHCP 예약으로 바뀌지 않게 하는 편이 디버깅에 유리합니다.
다른 기기에서 넣을 주소와 프로토콜
Wi-Fi 설정의 “프록시 구성”에 넣을 호스트는 127.0.0.1이 아니라 Clash가 돌아가는 PC의 LAN IP입니다. 포트는 mixed-port에 맞추고, 앱이 SOCKS5만 지원하면 SOCKS 쪽 포트를 쓰거나 mixed가 SOCKS를 함께 받는지 확인합니다. 브라우저 확장만 프록시를 쓰고 시스템 프록시는 비워 둔 상태라면, 다른 앱 트래픽은 여전히 직접 나가므로 “일부만 된다”는 느낌이 날 수 있습니다.
DNS는 별도 채널입니다
프록시만 맞춰 두고 DNS가 여전히 캐리어 기본값이면, 일부 환경에서 도메인 해석 단계에서 막히거나 누출 분석이 꼬일 수 있습니다. 랜 공유 시나리오에서는 “프록시를 통한 DNS”를 클라이언트가 지원하는지, 혹은 수동으로 안전한 DNS를 지정할지까지 함께 설계하는 편이 좋습니다. 다만 본 글의 초점은 TCP 연결이 프록시 포트에 닿는지이므로, DNS 세부는 프로필과 클라이언트별 옵션을 따로 맞추면 됩니다.
한눈에 보는 체크리스트
- bind-address가 루프백 전용이 아닌지, 실제로 LAN 또는
*로 열렸는지 - allow-lan이 true인지(또는 GUI 동등 옵션)
- 모바일에 입력한 IP·포트가 PC의 현재 LAN 주소·mixed-port와 일치하는지
- Windows 방화벽·타 OS 방화벽·백신이 인바운드를 막지 않는지
- 공유기 AP 격리·게스트 SSID·서브넷 불일치가 없는지
정리: 랜 공유는 “코어 설정 + OS + 공유기” 세 층입니다
Clash 한 대로 집·소규모 사무실의 여러 기기를 묶어 쓰고 싶을 때, 가장 많이 걸리는 건 구독이 아니라 리스닝 주소와 방화벽입니다. allow-lan과 bind-address를 올바르게 연 뒤에도 안 되면 Windows라면 거의 항상 인바운드 규칙을 의심하고, 그다음은 공유기 격리를 보면 대부분 원인이 좁혀집니다. 같은 계열 도구들과 비교해 보면 Clash·mihomo 쪽은 규칙과 포트 구성을 YAML과 GUI 양쪽에서 다루기 쉬워, “한 번 맞춰 두면” 재현성이 좋은 편입니다.
→ Clash 공식 클라이언트 무료 다운로드 — 최신 빌드에서 LAN 옵션과 mixed 포트를 직접 맞춰 보면, 문서만 읽을 때보다 훨씬 빨리 “다른 기기에서 붙는 감각”이 잡힙니다.