어떤 증상부터 의심하나
PC 브라우저에서는 Clash가 잘 도는데, 같은 집 Wi‑Fi에 붙은 휴대폰만 프록시 설정을 넣으면 타임아웃이 나거나 아예 연결이 안 됩니다. 혹은 프록시는 붙는 것 같은데 특정 사이트만 하얀 화면이거나 스트리밍 앱만 끊깁니다. 이때 첫 번째로 확인할 것은 “노드가 죽었다”가 아니라 PC가 LAN에서 프록시 포트를 열고 있는지, 그리고 운영체제 방화벽이 외부 기기의 접속을 허용하는지입니다. Clash 계열은 기본적으로 보안을 위해 루프백(127.0.0.1)만 듣는 설정이 흔하고, LAN 공유를 켜지 않으면 폰이 아무리 올바른 IP를 쳐도 패킷이 애초에 들어오지 않습니다.
이 글은 합법적인 네트워크·서비스 약관 범위 안에서 자신이 소유하거나 사용 권한이 있는 기기를 점검하는 전제를 둡니다. 회사·학교망, 타인의 공유기에 무단으로 프록시를 노출하는 행위는 정책 위반이 될 수 있으니 해당 환경에서는 IT 가이드를 따르세요.
0단계: PC 쪽에서 “주소·포트”를 먼저 확정한다
모바일에 입력할 값은 보통 PC의 LAN IP + mixed-port 또는 HTTP/SOCKS 포트 조합입니다. Windows 11에서는 설정 → 네트워크 및 인터넷 → 속성에서 IPv4 주소를 확인하거나, PowerShell에서 ipconfig로 확인합니다. 이때 노트북이 유선·무선을 동시에 쓰면 인터페이스가 두 개라 휴대폰이 실제로 붙어 있는 쪽 서브넷과 같은 IP 대역인지 꼭 맞춰야 합니다. 예를 들어 PC는 이더넷이 192.168.1.x이고 휴대폰은 게스트 Wi‑Fi로 192.168.50.x에만 붙어 있으면, 아무리 포트를 열어도 서로 다른 브로드캐스트 도메인에 가깝게 동작해 실패합니다. 먼저 휴대폰과 PC의 서브넷이 동일한지부터 확인하세요.
포트 번호는 프로필에 따라 다릅니다. Mihomo(Clash Meta) 계열 YAML에는 mixed-port로 HTTP와 SOCKS를 한 포트에서 받는 경우가 많고, GUI는 이를 그대로 표시합니다. 반면 port와 socks-port를 나눈 구성이라면 모바일 프록시 앱에 프로토콜에 맞는 번호를 넣어야 합니다. 혼동이 잦으므로 클라이언트의 “연결 정보” 화면에 표시된 숫자를 기준으로 삼는 편이 안전합니다.
1단계: allow-lan과 바인드 주소(bind-address)
Clash 코어에서 LAN 기기가 접속하려면 보통 allow-lan: true가 필요합니다. 이 값이 false이거나 설정 파일에 아예 없으면(기본이 false인 빌드도 있음) 외부 인터페이스로는 듣지 않습니다. GUI 클라이언트라면 “LAN 허용”, “로컬 네트워크에서 접속 허용” 같은 스위치가 이 옵션과 연결되는 경우가 많습니다. 설정을 바꾼 뒤에는 코어를 재시작해 실제로 적용됐는지 확인하세요. 로그에 RESTful API listening만 뜨고 프록시 포트가 127.0.0.1에 묶여 있으면 아직입니다.
다음으로 중요한 것이 바인드 주소입니다. bind-address: '*' 또는 0.0.0.0 계열이면 모든 인터페이스에서 수신하지만, 127.0.0.1만 지정되어 있으면 LAN에서 오는 SYN 패킷은 OS 단계에서 거절됩니다. 일부 배포판은 보안상 기본을 루프백으로 두므로, “allow-lan은 켰는데도 안 된다”면 바인드 줄을 반드시 다시 봅니다. 특정 LAN IP 하나만 열고 싶다면 그 주소에만 바인딩하는 방식도 가능하지만, DHCP로 PC IP가 바뀌면 매번 깨지므로 예약 DHCP나 고정 IP를 함께 쓰는 편이 덜 헷갈립니다.
# Minimal LAN listen sketch — comments in English per project convention
allow-lan: true
bind-address: '*'
mixed-port: 7890
# port: 7890
# socks-port: 7891위는 이해를 돕는 예시이며, 키 이름·기본값·지원 범위는 사용 중인 코어 버전과 GUI 문서를 반드시 대조해야 합니다.
2단계: Windows 11 방화벽 인바운드 규칙
allow-lan과 바인드가 맞아도, Windows Defender 방화벽이 해당 TCP 포트에 대한 인바운드를 차단하면 외부 기기에서는 여전히 연결할 수 없습니다. Clash 실행 파일이 이미 규칙을 추가했더라도, 수동으로 바꾼 프로필·도메인 네트워크 분류·보안 소프트웨어가 덮어쓴 경우가 있습니다. 점검 순서는 다음과 같습니다. (1) Windows 보안 → 방화벽 및 네트워크 보호 → 고급 설정 → 인바운드 규칙에서 해당 포트(예: 7890) TCP 허용 규칙이 있는지 확인합니다. (2) 없으면 “새 규칙”으로 포트 형식을 선택하고, 범위에 mixed-port 번호를 넣고 연결을 허용합니다. (3) 프로필에서 도메인/개인/공용 중 실제로 PC가 분류된 프로필에 체크가 들어가 있는지 확인합니다. 카페 등 공용 Wi‑Fi에 붙어 있으면 공용 프로필이 켜져 있어 허용이 안 먹는 경우가 있습니다.
빠른 분기 테스트로는 방화벽을 일시적으로 끄지 말고, 규칙만 추가한 뒤 휴대폰에서 같은 포트로 다시 시도하는 방법이 안전합니다. 전체 방화벽 해제는 다른 위협 노출 면이 커지므로 비권장입니다. 또한 서드파티 백신·제로트러스트 에이전트가 WFP 필터를 추가하면 Windows 규칙만으로는 부족할 수 있으니, 그런 제품을 쓰는 PC에서는 해당 제품 콘솔에서도 예외 경로를 확인해야 합니다.
3단계: 공유기 AP 격리·게스트 Wi‑Fi·클라이언트 분리
많은 가정용 공유기는 AP 격리(무선 단말 간 통신 차단) 옵션을 켜 두면 스마트폰에서 PC로의 직접 TCP 연결을 막습니다. “같은 SSID인데도 ping이 안 된다”면 이쪽을 의심하세요. 관리 페이지에서 무선 고급 설정을 찾아 격리를 끄거나, PC를 유선으로 공유기에 붙이고 휴대폰만 무선으로 쓰는 등 동일 L2 브리지 안에서 서로 보이는지를 먼저 확인합니다. 게스트 네트워크는 상위 라우터와 다른 NAT 뒤에 있을 수 있어, PC와 휴대폰이 서로 다른 홉에 있으면 LAN 프록시 시나리오가 성립하지 않습니다.
Mesh나 리피터를 쓰는 집에서는 백홀 구성에 따라 이중 NAT가 생기기도 합니다. 이때는 “PC IP가 진짜로 휴대폰이 보는 게이트웨이와 같은 브로드캐스트 도메인인가”를 traceroute나 간단한 내부 웹 서버 테스트로 확인하는 것이 빠릅니다.
4단계: 연결 검증 순서(휴대폰 ↔ PC)
설정이 맞았는지 확인할 때는 추측 대신 층을 나눕니다. (1) 휴대폰 브라우저에서 http://PC_LAN_IP:포트 형태로 접근할 수 있는지(일부 환경에서는 응답이 없어도 연결 거부 메시지가 다르면 포트는 열린 것입니다). (2) 프록시 앱에서 동일 IP·포트를 넣고 테스트 URL을 연다. (3) 그래도 실패하면 PC에서 netstat -ano | findstr :7890처럼 리슨 상태가 0.0.0.0 또는 LAN IP인지 확인합니다. 127.0.0.1만 뜨면 아직 바인드 문제입니다.
HTTPS 사이트만 안 열리는데 HTTP는 된다면, 프록시가 CONNECT를 제대로 처리하지 못하거나 TLS 스니핑·인증서 이슈일 수 있습니다. 반면 아무 것도 안 되면 방화벽·라우터 격리 쪽으로 다시 돌아가는 편이 맞습니다.
“일부만 된다”일 때: DNS·규칙·TUN과 구분
LAN 연결 자체는 성공했는데 특정 도메인만 실패하면 원인이 달라집니다. 노드 지역, 규칙 매칭 순서, DNS 모드(fake-ip vs redir-host), 스니퍼 설정이 겹치면 “구글은 되는데 특정 CDN만 안 된다” 같은 패턴이 납니다. 이 축은 Fake-IP·Redir-Host 트러블슈팅 글과 DNS 유출 방지 가이드에서 이어서 다루는 것이 효율적입니다. PC에서 TUN 모드를 쓰는 경우에는 LAN 클라이언트 트래픽이 PC의 라우팅·DNS 정책과 어떻게 만나는지도 변수이므로, Windows TUN 가이드의 DNS·라우팅 절을 함께 참고하세요.
모바일·OTT 쪽에서 자주 막히는 것
안드로이드·iOS 프록시 앱은 배터리 최적화로 백그라운드에서 끊기거나, VPN 권한과 프록시만 켠 상태가 충돌하기도 합니다. OTT 박스는 시스템 프록시 UI가 없어 앱별 설정이 필요한 경우가 많습니다. 이런 기기별 UX는 안드로이드 완전 가이드나 iPhone 구독·첫 연결 가이드에서 환경별로 정리되어 있으니, LAN만 열어도 “앱이 프록시를 안 탄다”면 그쪽을 대조하면 됩니다.
투명성·다운로드 채널
코어 동작과 이슈 추적은 Mihomo GitHub 저장소에서 확인할 수 있습니다. 다만 설치 패키지는 공식 다운로드 페이지를 거치는 편이 배포·검증 관점에서 분명합니다.
정리
휴대폰이 PC의 Clash 프록시에 붙지 않을 때는 ① allow-lan, ② bind-address가 LAN에서 듣도록 되어 있는지, ③ Windows 방화벽 인바운드, ④ 공유기 AP 격리·서브넷 일치 순으로 좁히면 대부분 원인이 드러납니다. “전부 안 됨”과 “일부 사이트만 안 됨”을 먼저 갈라 쓰면, 전자는 네트워크·방화벽 축이고 후자는 DNS·규칙·노드 축으로 디버깅을 전환할 수 있습니다. Clash는 규칙 기반으로 트래픽을 정교하게 나눌 수 있어, LAN만 열어도 최종 체감은 설정 품질에 크게 좌우됩니다. 같은 도구라도 프로필을 정리해 두면 스마트폰·PC·박스를 오가며 훨씬 덜 지치게 쓸 수 있습니다.
처음 전체 흐름을 익히려면 Clash 사용 문서의 기본 연결 설명을 먼저 보고, 이 글의 LAN·방화벽 순서를 덧붙이면 재현과 복구가 훨씬 빨라집니다.