같은 Wi-Fi에서 PC Clash를 프록시로 쓰기: allow-lan·mixed-port·bind-address와 Windows 방화벽 인바운드 (2026)

1. 이 시나리오에서 막히는 이유

PC에서 Clash를 켜 두면 브라우저는 종종 시스템 프록시나 localhost 쪽으로만 잘 붙습니다. 그런데 스마트폰은 PC의 127.0.0.1을 자기 안의 루프백으로 해석하므로, 「PC와 똑같이 127.0.0.1:7890」을 넣는 순간 전혀 다른 기기를 가리키게 됩니다. 따라서 같은 Wi-Fi에 있는 다른 장치는 반드시 PC의 LAN 주소(예: 192.168.0.23)와 Clash가 실제로 그 인터페이스에서 리슨하는 포트를 조합해야 합니다. 여기에 Windows가 기본으로 막아 두는 외부에서 들어오는 TCP 연결까지 풀어 주지 않으면, 설정을 아무리 맞춰도 SYN 패킷이 애플리케이션에 닿지 않습니다. 사용자 입장에서는 「allow-lan도 켰는데 왜 폰만 안 되지?」로 보이지만, 원인은 바인드 주소·방화벽 프로필·잘못된 IP 입력 중 하나인 경우가 대부분입니다.

mihomo를 코어로 쓰는 GUI 클라이언트들도 결국 설정 파일이나 고급 옵션에 위 키들이 반영됩니다. 이름만 「Allow LAN」으로 바뀌었을 뿐, 뒤에서는 allow-lan: true와 bind-address가 함께 움직인다고 이해하면 디버깅이 수월합니다. 구독 URL을 아직 넣지 않았다면 구독 가져오기 페이지의 흐름을 먼저 끝낸 뒤 이 글의 순서를 밟는 것이 좋습니다. 프록시 포트는 열려 있어도 아웃바운드 노드가 없으면 연결 테스트만 성공하고 실제 사이트는 열리지 않을 수 있으니, PC 단에서 한 번 정상 동작하는지 확인하는 단계를 건너뛰지 마세요.

2. Clash 쪽: allow-lan·bind-address·mixed-port

mixed-port는 한 포트에서 HTTP CONNECT와 SOCKS를 함께 받는 방식으로, 스마트폰의 「HTTP 프록시」 설정에 넣기에 특히 편합니다. 예전처럼 port와 socks-port를 나눠 쓰는 프로필도 있지만, 가정용 LAN 공유에서는 mixed-port 하나만 열고 방화벽도 그 포트만 허용하는 편이 관리가 쉽습니다. allow-lan: true는 「같은 라우터 아래 다른 기기의 접속을 허용한다」는 스위치이고, bind-address는 실제로 어느 주소에 소켓을 붙일지를 정합니다. 127.0.0.1에만 바인드되어 있으면 PC 자기 자신에서만 연결되고, LAN 기기의 패킷은 도달하지 않습니다. 보통은 '*' 또는 0.0.0.0(IPv4 전체 인터페이스)처럼 모든 IPv4 인터페이스에 리슨하도록 두는 예가 많습니다. 배포판·클라이언트 버전에 따라 키 이름이 조금 다를 수 있으니, 고급 YAML을 직접 편집한다면 공식 스키마와 주석을 함께 확인하세요.

# Example fragment — adjust port to your profile
mixed-port: 7890
allow-lan: true
bind-address: '*'

GUI에서 「Allow LAN」만 켜고도 동작하는 경우가 많은 이유는 앱이 내부적으로 위 조합을 넣어 주기 때문입니다. 반대로 체크는 켰는데도 외부에서 안 붙는다면, 별도의 오버라이드 YAML이 bind-address를 다시 127.0.0.1로 덮어쓰고 있지 않은지 로그와 최종 머지 결과를 확인해 보세요. 또한 두 개의 Clash 계열 프로세스가 같은 포트를 경쟁하면 한쪽만 리슨에 성공하고 나머지는 실패할 수 있으므로, 작업 관리자에서 중복 실행 여부도 짧게 점검하는 것이 좋습니다.

3. Windows에서 LAN IP(게이트웨이 옆 주소) 확인

다른 기기의 프록시 서버 주소란에는 Clash가 돌아가는 PC의 사설 IP를 넣습니다. PowerShell이나 명령 프롬프트에서 ipconfig를 실행하고, 지금 Wi-Fi에 쓰는 어댑터(무선 LAN 어댑터 Wi-Fi 등) 아래의 IPv4 주소를 읽으면 됩니다. 보통 192.168.x.x 또는 10.x.x.x 형태입니다. 유선으로 붙은 PC라면 해당 이더넷 어댑터 쪽 숫자를 써야 하고, VPN 가상 어댑터의 주소를 잘못 고르는 실수도 흔하니 어댑터 이름을 꼭 대조하세요. PC가 수면 모드로 들어가면 ARP 캐시가 흔들리거나 무선이 끊기므로, 공유를 쓰는 동안에는 전원·절전 정책을 잠시 완화하는 편이 덜 답답합니다.

공유기 DHCP가 주소를 자주 바꾼다면, 해당 PC에 DHCP 예약을 걸어 두거나 고정 IP를 배정하면 폰 설정을 매번 고칠 필요가 줄어듭니다. 듀얼 밴드 라우터에서 2.4GHz와 5GHz가 서로 다른 서브넷으로 나뉘는 구성은 드물지만, 게스트 네트워크에 폰만 붙어 있고 PC는 메인 LAN에 있으면 서로 다른 브로드캐스트 도메인이라 직접 TCP가 안 될 수 있습니다. 그럴 때는 라우터 설정에서 클라이언트 격리(무선 단절) 옵션이 켜져 있는지도 함께 확인하세요.

4. Windows Defender 방화벽 인바운드 규칙

Clash 프로세스가 리슨만 하고 있어도, Windows Defender 방화벽이 인바운드 TCP를 막으면 LAN의 폰에서 온 연결은 여기서 끊깁니다. 해결 절차는 대개 다음과 같습니다. 제어판 또는 설정 앱에서 「Windows Defender 방화벽」을 연 뒤, 고급 설정으로 들어갑니다. 인바운드 규칙 → 새 규칙 → 포트를 선택하고, 프로토콜은 TCP, 특정 로컬 포트에 앞서 정한 mixed-port(예: 7890)를 입력합니다. 동작은 연결 허용으로 두고, 프로필은 최소한 현재 Wi-Fi가 속한 개인 네트워크에 체크합니다. 이름은 예를 들어 「Clash mixed-port LAN」처럼 나중에 찾기 쉽게 붙여 두면 재설치 후에도 혼동이 줄어듭니다.

네트워크가 공용 프로필로 분류되어 있으면 규칙이 있어도 사용자의 기대와 다르게 동작할 수 있습니다. Wi-Fi 속성에서 해당 SSID를 「개인」으로 바꾸거나, 방화벽 규칙에서 공용 프로필까지 허용할지는 신뢰할 수 있는 집 네트워크인지에 따라 결정하세요. 회사망이나 카페 공용 AP에서는 LAN 공유 자체를 권장하지 않습니다. SOCKS만 따로 쓰는 구성이라면 TCP 포트를 하나 더 열어야 하므로, 방화벽 규칙도 포트 수만큼 맞춰야 합니다. 반대로 mixed-port만 쓰면 인바운드는 사실상 한 줄이면 충분합니다.

5. 폰·다른 PC에서 넣는 프록시 주소

iOS·Android 무선 LAN 설정에는 보통 프록시 없음 / 수동 / 자동 구성 URL 항목이 있습니다. 수동을 고르면 서버에 PC의 IPv4, 포트에 mixed-port, 인증은 대부분 비워 둡니다(로컬 프록시 인증을 켠 경우에만 ID·비밀번호 필요). 다른 Windows PC라면 설정 → 네트워크 → 프록시에서 동일한 주소·포트를 넣거나, 특정 브라우저만 프록시를 쓰도록 확장을 쓰는 방법도 있습니다. HTTPS 프록시 항목이 따로 있는 OS는 안내에 맞게 같은 호스트를 넣되, Clash mixed-port가 HTTP CONNECT를 처리하는지 확인하세요. 연결 테스트는 PC에서 먼저 통과한 뒤, 폰 브라우저로 검색 한 번, 이어서 앱 스토어나 메신저처럼 시스템 프록시를 무시하는 앱이 있는지 구분하면 원인 파악이 빨라집니다.

DNS 이슈는 별도입니다. 폰이 여전히 공용 DNS만 쓰고 있다면, 일부 지역 제한 사이트는 프록시를 타도 이름 해석 단계에서 어긋날 수 있습니다. Clash의 스니핑·규칙 기반 DNS는 PC 코어에 적용되므로, 폰은 HTTP 프록시만 맡기고 이름 해석은 프록시 터널 안에서 끝나는지 로그로 확인하는 편이 안전합니다. 고급 분기·도메인 규칙을 더 다듬고 싶다면 규칙 라우팅 가이드와 함께 보는 것을 권합니다.

6. 보안: 공용 Wi-Fi와 노출 범위

bind-address: '*'는 편리하지만, 의도치 않게 이더넷·다른 가상 인터페이스까지 노출할 수 있습니다. 신뢰할 수 있는 가정망이라도, 공유기 관리자 비밀번호·PC 로그인·Clash 대시보드(있다면)까지 계층적으로 보호하는 것이 좋습니다. 게스트 네트워크에 프록시 PC를 두지 말고, 가능하면 방화벽 규칙을 특정 서브넷만 허용하도록 좁히는 고급 구성도 고려할 만합니다. mihomo를 서비스 형태로 상시 기동한다면, OS 부팅 순서와 자동 재시작 정책을 Linux 서버 글의 원리와 비슷하게 생각해 두면 장애 대응이 수월합니다. 다만 본문의 초점은 Windows 데스크톱이므로, 서버 배포 시에는 추가로 인증 프록시·ACL을 검토하세요.

7. 여전히 안 될 때 체크리스트

첫째, PC 자기 자신에서 http://127.0.0.1:7890 대신 http://<LAN-IP>:7890으로 접속해 보아 같은 서비스가 보이는지 확인합니다. 둘째, PowerShell에서 Test-NetConnection -ComputerName <LAN-IP> -Port 7890을 다른 기기가 아닌 PC 로컬에서 돌려 리슨 여부를 먼저 본 뒤, 폰에서 동일 포트로 시도합니다. 셋째, 방화벽 규칙이 잘못된 프로필에만 열려 있지 않은지, 넷째, Clash 로그에 폰 IP에서 온 CONNECT가 찍히는지 봅니다. 로그에 아예 없다면 여전히 네트워크 경로나 방화벽 이전 단계 문제이고, 로그는 있는데 응답이 없다면 규칙·노드·DNS 쪽을 의심합니다. 다섯째, 백신 제품의 네트워크 방화벽 모듈이 Windows 방화벽 앞에서 추가 차단을 걸고 있지 않은지 확인합니다.