증상: 스위치는 켰는데 휴대폰만 안 붙는 이유

많은 사용자가 겪는 패턴은 비슷합니다. 데스크톱에서는 브라우저가 잘 열리고, Clash 대시보드에도 녹색 표시가 뜨는데, 휴대폰 Wi‑Fi 설정에 PC의 IP와 포트를 넣으면 타임아웃이거나 즉시 거절됩니다. 이때 원인은 종종 출구 노드가 아니라 휴대폰이 PC의 프록시 포트에 물리적으로 닿지 못하는 로컬 조건입니다. 원격 연결이 실패할 때 쓰는 로그 기반 절차와는 다른 축이지만, 둘 다 「증상만 보고 추측하지 말고 층을 나눈다」는 점은 같습니다.

Clash LAN 프록시·로컬 네트워크 허용 같은 표현은 클라이언트마다 메뉴 이름이 조금씩 다릅니다. 공통점은 「같은 유선·무선 대역에 있는 다른 기기가, PC가 연 HTTP 프록시나 SOCKS 포트에 접속할 수 있게 한다」는 취지입니다. 그런데도 안 되면, 스위치 다음 단계인 리슨 주소와 방화벽, 그리고 휴대폰이 정말 같은 브로드캐스트 도메인에 있는지부터 의심하는 편이 빠릅니다.

ℹ 용어 정리: 이 글에서 말하는 「프록시 포트」는 보통 Mixed(HTTP+SOCKS) 포트, 또는 분리된 HTTP·SOCKS 중 사용자가 휴대폰에 입력한 번호를 가리킵니다. 클라이언트 설정 화면에 표시된 숫자와 휴대폰에 적은 숫자가 한 자라도 다르면 전부 헛수고가 됩니다.

「LAN 허용」이 실제로 바꾸는 것

일부 Clash 계열 앱에서 로컬 네트워크 허용을 켜면, 설정 파일의 allow-lan 같은 항목이 true로 바뀌고, 동시에 UI가 「외부에서 접속 가능한 주소」를 안내하기도 합니다. 하지만 이 스위치만으로 운영체제 방화벽이 자동으로 모든 인바운드 연결을 허용한다는 뜻은 아닙니다. Windows Defender 방화벽, macOS 애플리케이션 방화벽, Linux의 ufw·firewalld·iptables 계열 규칙은 여전히 별개의 층입니다. 그래서 「앱 안에서는 LAN이 열렸다」고 뜨는데도 패킷이 PC에 도착하기 전에 막히는 상황이 자주 나옵니다.

또 한 가지, 설정 파일에 bind-address나 유사 항목이 127.0.0.1로 고정돼 있으면 LAN 허용을 켜도 의미가 없습니다. 이 경우 코어는 여전히 루프백에만 귀를 기울이고, 무선 LAN 인터페이스로 들어오는 SYN을 받지 않습니다. GUI에서 LAN을 허용했다면, 동시에 고급 설정·YAML 쪽에서 바인드가 어디로 잡혀 있는지 반드시 확인하세요. 여러 프로필을 오가는 사용자라면 플랫폼별 클라이언트마다 설정 저장 위치가 다르다는 점도 염두에 두는 것이 좋습니다.

바인드 주소: 127.0.0.1 과 모든 인터페이스

일반적으로 LAN 공유를 하려면 프록시 데몬이 모든 IPv4 인터페이스에서 해당 포트를 열어야 합니다. 표기는 구현마다 다르지만, 0.0.0.0에 바인드한다는 말과 통합니다. 반대로 127.0.0.1만이면 같은 기기 안의 앱만 붙을 수 있고, 휴대폰에서 오는 연결은 OS 수준에서 거절되거나 아예 도달하지 않습니다. Mixed 포트 한 개만 쓰는 구성이라도, 바인드가 루프백이면 「PC 브라우저는 되는데 휴대폰만 안 된다」가 정확히 설명됩니다.

IPv6·이중 스택 환경

일부 네트워크는 휴대폰이 IPv6 우선으로 이름을 풀고, PC는 IPv4만 열어 둔 경우 혼선이 생길 수 있습니다. 의심될 때는 휴대폰에 PC의 IPv4 주소를 직접 숫자로 넣고, 프록시 스킴이 HTTP인지 SOCKS5인지 클라이언트 표시와 일치하는지 다시 확인하세요. IPv6 전용 주소로 접속을 시도하는데 서버가 IPv4 소켓만 듣고 있으면, 증상은 역시 「아무 반응 없음」에 가깝습니다.

PC의 LAN IP·포트 번호 다시 확인하기

휴대폰에 넣어야 하는 것은 공인 IP가 아니라, 같은 LAN 안에서 라우터가 PC에 준 사설 주소입니다. Windows에서는 ipconfig, macOS·Linux에서는 ip addr 또는 GUI의 네트워크 세부 정보로 확인합니다. 이더넷과 Wi‑Fi를 동시에 쓰는 노트북은 인터페이스가 둘 이상이라, 휴대폰이 붙어 있는 쪽과 같은 서브넷에 해당하는 어댑터의 주소를 골라야 합니다. VPN이나 가상 스위치가 켜져 있으면 표시되는 주소가 헷갈리기 쉬우니, 테스트할 때는 잠시 끄거나 분리해 보는 것도 방법입니다.

Windows에서 IPv4 예시(출력 일부) 
Wireless LAN adapter Wi-Fi:
   IPv4 Address. . . . . . . . . . . : 192.168.0.42

포트 번호는 Clash 클라이언트의 「포트」「Mixed Port」「HTTP Port」에 표시된 값과 동일해야 합니다. 사용자가 수동으로 YAML을 만진 적이 있다면, UI에 보이는 숫자와 실제 실행 중인 프로세스가 듣는 포트가 어긋나 있을 수 있으므로, 가능하면 앱을 재시작한 뒤 다시 읽습니다.

Windows·macOS·Linux 방화벽에서 인바운드 허용

운영체제 방화벽은 「나가는 연결」은 허용하면서도 들어오는 TCP 연결을 기본 차단하는 경우가 많습니다. Clash 실행 파일이나 백그라운드 서비스에 대해, Mixed/HTTP/SOCKS에 해당하는 TCP 포트를 프로필별(개인·공용 네트워크)로 허용 규칙을 추가해야 합니다. Windows에서는 고급 보안이 포함된 Windows Defender 방화벽의 인바운드 규칙에서 특정 포트를 열거나, 앱 단위 허용을 줄 수 있습니다. 공용 Wi‑Fi 프로필로 잡혀 있으면 더 엄격해지므로, 집에서 테스트할 때는 네트워크 위치가 「개인」인지도 함께 봅니다.

macOS는 「들어오는 연결 허용」 프롬프트가 뜨는 경우가 있으나, 항상 그렇지는 않습니다. 방화벽을 켠 상태에서 특정 바이너리에 대한 예외가 없으면 조용히 막힐 수 있어, 시스템 설정에서 Clash 관련 앱을 허용 목록에 넣거나, 개발·고급 사용자는 포트 단위로 임시 예외를 추가합니다. Linux 데스크톱에서는 배포판에 따라 ufw allow .../tcp 한 줄로 끝나기도 하고, 서버용 최소 설치라면 iptables-nft 쪽을 직접 봐야 합니다.

⚠ 보안 참고: LAN 전체에 프록시 포트를 열면 같은 Wi‑Fi에 붙은 누구나 이론적으로 그 포트로 접속을 시도할 수 있습니다. 신뢰할 수 있는 가정·사무 네트워크에서만 켜고, 불필요할 때는 LAN 허용을 끄거나 방화벽 규칙을 되돌리세요.

같은 서브넷·게이트웨이·DNS 한 줄 점검

휴대폰과 PC가 같은 무선 SSID를 쓴다고 해서 반드시 같은 L2 세그먼트에 있다는 뜻은 아닙니다. 그래도 가장 먼저 볼 것은 IP 대역입니다. 예를 들어 PC가 192.168.0.0/24이고 휴대폰이 192.168.1.0/24이면 서로 다른 서브넷이므로, 단순 사설 주소만으로는 프록시에 닿지 않습니다. 게이트웨이 주소가 동일한지, 서브넷 마스크가 기대와 같은지 비교해 보세요. VPN 클라이언트가 휴대폰 쪽에 별도 터널 IP를 만들고 있다면 표가 달라질 수 있습니다.

DNS는 프록시 연결 자체와 직접 관련이 없어 보일 수 있지만, 휴대폰이 특정 캡티브 포털이나 제한된 확인자만 쓰도록 잠겨 있으면 브라우저 증상이 「프록시가 안 된다」처럼 보이기도 합니다. 우선은 HTTP 프록시 포트에 TCP 연결이 성립하는지부터 분리하는 편이 낫습니다. 연결 레벨에서 막히는 문제와 애플리케이션 레벨의 이름 확인 문제를 한꺼번에 섞어 해석하면 시간만 늘어납니다. DNS·연결 일반 질문은 자주 묻는 질문과 함께 보셔도 좋습니다.

공유기 AP 격리·게스트 Wi‑Fi·이중 NAT

많은 가정용 공유기에는 AP 격리(클라이언트 간 통신 차단) 옵션이 있습니다. 켜져 있으면 휴대폰에서 PC로의 직접 TCP 연결이 막혀, 프록시 포트가 열려 있어도 전혀 닿지 않습니다. 반대로, 게스트 Wi‑Fi는 의도적으로 메인 LAN과 분리되는 경우가 많아, PC는 메인 SSID에만 있고 휴대폰은 게스트에 붙어 있으면 같은 「인터넷은 된다」처럼 보여도 서로를 못 봅니다.

이중 NAT 환경(공유기 아래 또 공유기)에서는 PC의 「윗쪽」 주소와 실제 휴대폰이 있는 대역이 어긋나기 쉽습니다. 이 경우 포트 포워딩 없이는 외부에서 내부 서비스에 닿지 않는 것과 비슷하게, 단순 LAN 공유 가정이 깨질 수 있습니다. 가능하면 같은 스위치·같은 서브넷으로 단순화한 뒤 다시 시도하세요.

PC 핫스팟·테더링일 때 자주 틀리는 설정

Windows 모바일 핫스팟이나 일부 USB 테더링에서는 호스트 PC가 미니 DHCP 서버 역할을 하며, 휴대폰은 192.168.137.x 같은 별도 대역을 받는 경우가 있습니다. 이때 PC 쪽으로 프록시를 넣으려면, 노트북 무선이 아니라 핫스팟 인터페이스에 할당된 게이트웨이 IP를 써야 합니다. 표시되는 주소가 헷갈리면, 핫스팟을 켠 뒤 ipconfig로 「Microsoft Wi-Fi Direct Virtual Adapter」 또는 유사 이름의 IPv4를 다시 확인하세요.

반대로 휴대폰이 LTE만 쓰고 PC는 유선 LAN에 붙어 있다면, 애초에 같은 Layer 2 네트워크가 아니므로 사설 주소로는 서로를 찾을 수 없습니다. 이 경우에는 PC가 만든 핫스팟에 휴대폰을 붙이거나, 둘 다 같은 Wi‑Fi에 올려야 합니다. 「핫스팟 공유」라는 키워드로 검색해 이 글을 찾은 경우, 어느 쪽이 AP인지부터 다시 그리면 절반은 정리됩니다.

휴대폰 쪽 프록시 입력 순서와 흔한 오타

iOS·Android 모두 Wi‑Fi 항목의 고급 설정이나 별도 앱에서 HTTP/SOCKS 프록시를 넣을 수 있습니다. 흔한 실수는 서버 칸에 http://까지 같이 넣는 것, 포트를 HTTPS(443)로 착각하는 것, SOCKS5인데 HTTP로 고른 것입니다. Clash 쪽이 Mixed 포트를 쓰면 둘 다 받을 수 있는 경우가 많지만, 클라이언트 표기와 휴대폰 UI의 조합이 맞아야 합니다. 사용자 이름·비밀번호가 비어 있는데 빈 칸을 강제로 채운 경우도 인증 실패로 이어질 수 있습니다.

가능하면 같은 LAN의 다른 PC나 터미널에서 curl로 프록시 포트에 대한 TCP 연결을 먼저 시험해 보세요. 휴대폰만 특이한 경우에는 OS 버전·프로필·Private DNS 설정을 의심합니다. 규칙·분류 자체를 손보는 단계는 규칙 라우팅 가이드가 도움이 되지만, 그 전에 로컬 포트에 물리적으로 닿는지부터 확인하는 것이 순서입니다.

한 번에 도는 체크리스트

아래 순서는 한 단계씩 「LAN 연결 실패」 범주를 줄여 나갑니다. 중간에 원격 노드 문제와 섞이면 연결 로그 글의 절차로 넘어가면 됩니다.

  1. Clash에서 LAN 허용과 실제 바인드 주소가 모두 LAN에 열려 있는지 확인한다.
  2. PC의 올바른 인터페이스 IPv4와 클라이언트에 표시된 포트 번호를 휴대폰에 그대로 옮긴다.
  3. OS 방화벽 인바운드에서 해당 TCP 포트를 허용하거나 앱 예외를 준다.
  4. 휴대폰과 PC의 IP가 같은 서브넷이고 게이트웨이가 일치하는지 본다.
  5. 공유기에서 AP 격리·게스트 SSID를 끄거나, 둘 다 메인 LAN에 붙인다.
  6. PC 핫스팟을 쓰면 핫스팟용 게이트웨이 주소를 사용한다.
  7. 휴대폰 프록시 종류(HTTP vs SOCKS5)와 빈 인증 필드를 다시 맞춘다.

마무리

Clash 로컬 네트워크 허용은 LAN 공유의 첫 스위치일 뿐이고, 그 뒤에는 바인드 주소·방화벽·서브넷·AP 정책이라는 운영체제와 물리 네트워크 층이 있습니다. 이 층이 맞으면 휴대폰은 PC의 프록시 포트에 먼저 닿고, 그 다음에야 규칙·노드·DNS 이야기가 이어집니다. 반대로 여기서 막히면 아무리 좋은 구독을 써도 휴대폰 화면만 멈춰 있게 됩니다. 같은 증상이라도 원인 층을 나누어 보면 재설치와 무작정 노드 교체에 쓰던 시간을 줄일 수 있습니다.

데스크톱에서 검증한 분류와 포트 표시가 일관되게 보이는 클라이언트를 쓰면, LAN 테스트와 원격 연결 테스트를 오가며 설정이 덜 어긋납니다. 여러 도구를 섞어 쓸 때보다 한 코어·한 UI에 맞추는 편이 장기적으로는 더 안정적인 경우가 많습니다.

→ LAN 점검을 마친 뒤, Clash를 무료로 받아 데스크톱과 모바일을 같은 흐름으로 맞춰 보세요.