Clash Allow LAN을 켰는데 휴대폰이 LAN 프록시를 못 쓸 때: 바인딩·혼합 포트·방화벽 순서 점검

PC는 되는데 휴대폰만 “프록시만 켜면 인터넷이 죽는” 이유

Clash Allow LAN은 같은 유선·무선 LAN에 있는 다른 기기가, PC에서 돌아가는 Clash의 HTTP·SOCKS 포트에 붙을 수 있게 해 주는 스위치에 가깝습니다. 그런데도 휴대폰에서 수동으로 192.168.x.x:7890 같은 주소를 넣었을 때 아예 연결이 안 되거나, 잠깐 됐다가 끊기면 원인은 대개 다음 셋 중 하나로 수렴합니다. 첫째, 데몬이 127.0.0.1에만 리슨하고 있어 LAN에서 물리적으로 닿을 수 없는 경우입니다. 둘째, mixed-port와 구버전 포트 필드가 헷갈려 휴대폰이 “없는 포트”를 찍는 경우입니다. 셋째, Windows 방화벽·macOS 방화벽이나 보안 제품이 인바운드를 막는 경우입니다. 여기에 라우터의 AP 격리·게스트 네트워크까지 겹치면 “설정은 맞는 것 같은데 안 된다”는 느낌이 배가됩니다.

이 가이드는 법령·서비스 약관을 준수하는 개인·가정 내 네트워크 튜닝을 전제로, 확인 순서를 고정해 두었습니다. Clash Verge Rev 같은 GUI를 쓰는 분은 Clash Verge Rev 완벽 사용 가이드로 기본 화면부터 익힌 뒤 이 체크리스트를 적용하면 훨씬 빠릅니다. 휴대폰 단독으로 구독을 쓰는 흐름이 궁금하다면 FlClash 안드로이드 가이드iPhone Stash 구독 가이드가 별도 트랙입니다. 본문은 “PC Clash를 공유 AP처럼 쓰고 싶다”는 요구에 집중합니다.

개념 정리: 루프백 리슨과 LAN 리슨은 다릅니다

Clash 코어는 기본적으로 로컬 루프백에서 시스템 프록시·브라우저 확장과 통신하는 경우가 많습니다. 이 상태에서 Allow LAN을 켜도, 실제 YAML이나 바인딩 옵션이 127.0.0.1에 고정돼 있으면 외부 기기의 SYN 패킷은 PC에 도달해도 애플리케이션이 받지 않습니다. 반대로 0.0.0.0처럼 “모든 인터페이스”에 열어 두면 같은 서브넷의 휴대폰이 붙을 수 있습니다. 다만 0.0.0.0 바인딩은 편의와 보안 사이의 트레이드오프이므로, 공용 Wi-Fi나 다중 사용자 PC에서는 신중해야 합니다.

또 하나, “시스템 프록시가 켜졌다”는 표시는 본 PC의 트래픽만 Clash 쪽으로 보낸다는 뜻이지, 자동으로 휴대폰까지 터널링해 주지는 않습니다. 휴대폰은 Wi-Fi 설정에서 수동 프록시를 넣거나, 별도 PAC·프로필이 필요합니다. TUN으로 PC 전체를 가로채는 방식과도 다릅니다. 전역 터널 개념은 TUN 모드 가이드를 참고하되, LAN 공유 시나리오에서는 우선 HTTP/SOCKS 포트가 열려 있는지부터 보는 것이 순서에 맞습니다.

0단계: “같은 LAN”인지부터 숫자로 확인

흔한 실수는 PC는 유선, 휴대폰은 “집 Wi-Fi”인데 실제로는 메시 노드·중계기·이동통신 테더링으로 서브넷이 갈라진 경우입니다. PC의 사설 IPv4(예: ipconfig·ifconfig·시스템 설정)와 휴대폰의 Wi-Fi 상세 정보를 나란히 놓고, 앞의 세 옥텟이 같은지 확인하세요. 다르면 방화벽 이전에 라우팅 자체가 안 되는 케이스입니다. 게스트 SSID에 휴대폰만 붙어 있는 경우도 마찬가지로, 게스트 VLAN이 메인과 분리돼 있으면 mDNS로 PC 이름이 잡혀 보여도 프록시 포트는 막힐 수 있습니다.

동일 서브넷임이 확실하면, 휴대폰 브라우저가 아니라 핑 도구나 터미널 앱으로 PC IP에 ICMP가 되는지(일부 라우터는 ICMP를 막기도 함)와, telnet IP 포트에 가까운 TCP 연결 테스트를 해 보면 “3계층까지는 되는데 7계층 프록시만 실패”인지 가늠하기 쉽습니다. 여기서조차 안 되면 아래 방화벽·AP 격리를 우선 의심합니다.

1단계: Allow LAN과 바인딩 주소를 한 번에 맞추기

GUI 클라이언트에서는 Allow LAN 토글이 보이지만, 실제로는 코어 설정의 allow-lanbind-address·인터페이스 선택이 짝을 이뤄야 합니다. 토글만 켜고 바인딩이 루프백이면 증상은 변하지 않습니다. 설정 파일을 직접 볼 수 있다면 allow-lan: true와 함께 외부에서 붙을 주소가 열려 있는지 확인하세요. 일부 배포판은 “안전 기본값”으로 루프백을 유지한 채 Allow LAN 문구만 노출하는 경우가 있어, 대시보드나 로그의 Listening 줄을 보는 것이 가장 확실합니다.

노트북이 유선·Wi-Fi를 동시에 쓰는 경우, 휴대폰이 붙은 쪽과 다른 NIC의 IP를 프록시 주소로 넣으면 당연히 실패합니다. 지금 휴대폰이 사용 중인 AP와 같은 인터페이스의 IPv4를 골라 적으세요. IPv6만 잡히는 환경이라면 IPv4가 꺼져 있지 않은지도 함께 봅니다.

2단계: mixed-port와 “옛날 포트 이름” 헷갈림 방지

Clash·Mihomo 계열은 mixed-port 하나로 HTTP와 SOCKS를 같이 받는 구성이 흔합니다. 그런데 예전 문서나 스크린샷을 따라 7890은 HTTP, 7891은 SOCKS처럼 포트를 둘로 쪼개 둔 설정을 기억하고 있으면, 실제로는 한 포트만 열려 있어 연결이 거절됩니다. 대시보드의 Ports 섹션에서 mixed가 몇 번인지, 별도의 port·socks-port가 살아 있는지 확인한 뒤, 휴대폰 Wi-Fi 수동 프록시에 같은 번호를 넣어야 합니다.

외부에서 REST API·대시보드만 열어 두고 프록시 포트는 다른 값인 경우도 있습니다. “웹 패널은 되는데 프록시만 안 된다”면 이런 착시에 가깝습니다. 구독 URL이나 프로필 구조가 헷갈릴 때는 구독 링크 추가·가져오기 가이드와 병행해, “공유용 포트”만 따로 메모해 두는 습관을 추천합니다.

3단계: 휴대폰 수동 프록시 화면에서 자주 틀리는 입력

iOS·Android 모두 Wi-Fi 항목에 HTTP 프록시·수동 메뉴가 있습니다. 여기서 서버 칸에 PC의 게이트웨이 주소나 공유기 IP를 넣는 실수가 잦습니다. 반드시 Clash가 떠 있는 PC의 LAN IPv4를 넣어야 합니다. 포트는 앞 단계에서 확인한 mixed-port(또는 명시된 HTTP/SOCKS 포트)와 일치해야 하고, 프록시 타입이 SOCKS라면 OS 설정이 SOCKS를 지원하는지도 확인하세요. 일부 환경에서는 HTTP만 수동 설정이 되므로, mixed의 HTTP 쪽을 사용하는 편이 호환성이 좋습니다.

프록시를 켠 순간 DNS만 타임아웃하는 패턴은, 수동 프록시가 HTTP CONNECT 경로만 타게 되어 있거나, Clash 쪽 DNS 스택과 휴대폰의 질의 경로가 엇갈릴 때 나올 수 있습니다. 이때는 잠시 “프록시 우회” 목록을 비우고, 규칙에서 국내 DNS가 DIRECT로 가는지 등을 점검합니다. 증상이 복잡하면 우선 단순 HTTP 사이트 하나로 연결만 확인하고 범위를 넓히세요.

4단계: Windows Defender 방화벽 인바운드 규칙

Windows 10·11에서 Clash 실행 파일이 개인 네트워크로 분류되지 않았거나, 첫 실행 시 방화벽 팝업에서 차단을 눌렀다면 LAN에서 들어오는 TCP가 막힙니다. 제어판의 Windows Defender 방화벽 → 고급 설정에서 인바운드 규칙을 연 뒤, 해당 클라이언트 실행 파일(또는 코어 바이너리)에 대해 프로필: 개인 범위에서 허용 규칙이 있는지 확인하세요. “퍼블릭” 프로필만 허용돼 있고 현재 Wi-Fi가 퍼블릭으로 잡혀 있으면, 카페망과 집망을 오갈 때 증상이 갈리는 패턴이 나옵니다.

보안 제품이 WFP 필터를 추가로 거는 경우, Windows 기본 화면만으로는 안 보이는 차단이 있을 수 있습니다. 이때는 해당 제품의 방화벽 로그에서 차단된 대상 포트가 Clash mixed-port와 같은지 대조합니다. 임시로 방화벽을 꺼 테스트하는 것은 진단용으로만 짧게 쓰고, 원인이 확인되면 다시 켜는 것이 안전합니다.

5단계: macOS 방화벽·로컬 네트워크 권한

macOS는 시스템 설정의 네트워크 방화벽이 켜져 있으면, 앱별로 인바운드 연결 허용을 묻습니다. Clash 계열 GUI를 처음 실행할 때 놓쳤다면 설정에서 다시 허용 목록을 확인하세요. 최근 버전은 로컬 네트워크 권한을 별도로 요구하기도 합니다. 꺼져 있으면 같은 Wi-Fi의 휴대폰이라도 mDNS·로컬 HTTP가 막혀 “앱은 떠 있는데 포트만 안 열린다”는 느낌이 납니다.

회사 정책으로 MDM 프로필이 방화벽을 강제하는 Mac이라면, 개인 설정만으로는 한계가 있을 수 있습니다. 이 경우 IT 정책 허용 범위 안에서 예외를 요청해야 합니다.

6단계: 라우터 AP 격리·게스트 Wi-Fi·무선 클라이언트 분리

소비자용 공유기에는 AP 격리(무선 단말끼리 통신 금지), 무선 분리, 게스트 네트워크 같은 옵션이 있습니다. 이게 켜져 있으면 휴대폰에서 PC IP로 ping조차 안 되는 것이 정상입니다. 관리자 페이지에서 해당 항목을 끄거나, PC와 휴대폰을 같은 메인 SSID·같은 VLAN에 두세요. 메시 시스템에서는 백홀 유닛이 다르면 논리적으로 분리된 것처럼 보일 수 있으니, 가능하면 동일 노드 아래에서 재현 여부를 비교합니다.

테더링으로 PC만 유선 LTE를 쓰고 휴대폰은 집 Wi-Fi를 쓰는 구성은 애초에 “같은 LAN”이 아닙니다. 이런 때는 USB 테더링으로 PC와 휴대폰을 직접 묶거나, 휴대폰에 클라이언트 앱을 설치하는 편이 구조적으로 단순합니다.

참고: 일부 캠퍼스·기숙사망은 클라이언트 간 통신 자체를 금지합니다. 이 환경에서는 Allow LAN과 방화벽을 아무리 맞춰도 물리적으로 막혀 있으므로, 정책을 확인해야 합니다.

7단계: 여전히 간헐적이면 전원 관리·절전·가상화

노트북이 배터리 모드에서 NIC 절전으로 잠깐 꺼졌다 켜지면, 휴대폰 쪽은 오래된 ARP 캐시를 들고 있어 몇 분간 실패하는 경우가 있습니다. 이때는 휴대폰 Wi-Fi를 껐다 켜거나, PC에서 인터페이스를 잠깐 비활성화했다가 복구해 보세요. Parallels·VMware처럼 가상 NIC가 여럿인 PC에서는 바인딩이 가상 쪽으로 잡혀 실제 Wi-Fi 대역과 어긋나기도 합니다. 리슨 줄에 표시된 IP가 기대한 것과 같은지 다시 대조합니다.

그래도 안 되면: 로그 한 줄로 좁히기

Clash 로그에 connection refused만 찍히면 포트·바인딩 문제에 가깝고, timeout이면 방화벽·라우터·서브넷 문제에 가깝습니다. TLS 핸드셰이크 전에 끊기면 경로 문제, 핸드셰이크 이후에야 실패하면 규칙·DNS·업링크 노드 쪽을 의심합니다. 이 단계까지 왔다면 mixed-port 번호를 다시 적어 두고, Windows·macOS 방화벽 화면을 스크린샷으로 남겨 커뮤니티에 올릴 때도 도움이 됩니다.

주의: Allow LAN과 0.0.0.0 바인딩은 편리하지만, 신뢰할 수 없는 네트워크에 노트북을 연결한 채로 켜 두면 의도치 않은 단말에서 프록시를 탈 수 있습니다. 사용 후에는 끄거나, 신뢰하는 홈 네트워크에서만 유지하세요. 프록시·VPN 기능은 소속 지역 법령과 약관을 준수하는 범위에서만 사용해야 합니다.

정리

Clash Allow LAN으로 휴대폰에 LAN 프록시를 나눠 줄 때는, 토글 하나보다 리슨 주소·mixed-port·OS 방화벽·라우터 격리가 한 세트로 맞아야 합니다. 순서를 지키면 “대시보드는 되는데 휴만 안 된다”는 말이 포트 착시인지, 방화벽인지, 애초에 다른 서브넷인지 빠르게 갈라낼 수 있습니다.

비슷한 도구들과 비교해 보면, Clash·Mihomo 계열은 구독과 규칙을 한곳에서 관리하면서도 로컬 포트 공유만으로 멀티 디바이스를 묶을 수 있어 유지 비용이 낮은 편입니다. 한 번 체크리스트를 몸에 익혀 두면 이후에는 헛수고하는 시간을 크게 줄일 수 있습니다.

지금 쓰는 OS에 맞는 클라이언트로 바로 점검해 보시려면 Clash를 무료로 다운로드한 뒤, Allow LAN과 방화벽 예외를 함께 맞춰 보시기 바랍니다.