1. 공유되는 것은 프록시 연결 지점이지, PC의 전체 네트워크가 아닙니다

Clash LAN 공유는 보통 PC에서 프록시 코어를 실행하고 같은 네트워크에 연결된 휴대폰이나 TV가 PC의 HTTP 프록시 포트에 접속하는 방식입니다. 기기에서 프록시를 지원하는 요청을 PC로 보내면 코어가 현재 규칙, 정책 그룹, 노드에 따라 연결을 처리합니다. PC가 켜져 있어야 하며 Clash 코어도 계속 실행 중이어야 합니다.

이 방식은 PC를 라우터로 설정하는 것과 다릅니다. 휴대폰에서 Wi-Fi 프록시를 설정해도 모든 앱과 모든 프로토콜의 트래픽이 PC를 거치는 것은 아닙니다. 앱이 시스템 프록시 설정을 따라야 합니다. 게임의 UDP 트래픽, 일부 동영상 앱의 독립 네트워크 스택, 자체적으로 연결을 만드는 서비스는 이 경로를 우회할 수 있습니다.

시작하기 전에 세 가지를 확인하세요

  • PC의 LAN IPv4 주소: 아래 예시에서는 192.168.1.20을 사용합니다. 실제 설정에는 PC의 현재 주소를 입력해야 합니다.
  • 프록시 수신 포트: 아래에서는 7890을 사용합니다. 실제 포트는 클라이언트에 표시된 Mixed 또는 HTTP 포트를 확인하세요.
  • PC에서 작동하는 설정: 먼저 PC에서 해당 프록시 포트로 대상 웹사이트에 접속할 수 있는지 확인한 뒤 LAN 공유를 설정하세요.

PC는 유선 LAN, 휴대폰은 Wi-Fi를 사용해도 됩니다. 두 기기가 같은 방식으로 연결될 필요는 없으며, 라우터에서 기기 간 통신을 허용하는지가 중요합니다. 게스트 Wi-Fi, 무선 클라이언트 격리, 기업 VLAN은 연결을 차단할 수 있습니다. 같은 Wi-Fi 이름을 사용한다고 해서 기기끼리 통신할 수 있는 것은 아닙니다.

2. allow-lan, mixed-port, 바인딩 주소 설정

Clash 또는 Clash Meta(현재 이름: mihomo) 기반 클라이언트에는 보통 ‘LAN 연결 허용’ 또는 ‘Allow LAN’ 스위치가 있습니다. 이는 코어 설정의 allow-lan에 해당합니다. 그래픽 클라이언트마다 메뉴 이름과 설정 덮어쓰기 방식이 다르므로 구독 파일의 항목만 확인하지 말고 실제 실행 설정도 살펴보세요.

항목예시 값기능 및 확인 사항
mixed-port7890하나의 포트에서 HTTP와 SOCKS 프록시 연결을 모두 받습니다. 휴대폰 시스템 프록시는 보통 HTTP로 설정합니다.
allow-lantrueLAN 기기의 프록시 연결을 허용합니다. 단, 수신 주소와 방화벽, 코어의 접근 제어 설정에 따라 연결이 제한될 수 있습니다.
bind-address"*"모든 주소에 바인딩합니다. 방화벽에서 접속 출처를 제한하고 실제 수신 상태도 확인해야 합니다.
moderule공유 기기의 요청도 규칙에 따라 분기되며, 모든 연결이 원격 노드를 사용하는 것은 아닙니다.

현재 설정에 항목을 병합하고 구독 설정 전체를 덮어쓰지 마세요

# LAN 공유 관련 항목이며, 완전한 구독 설정이 아닙니다
mixed-port: 7890
allow-lan: true
bind-address: "*"
mode: rule

이 내용에는 노드, 정책 그룹, 규칙이 없으므로 완전한 설정 파일로 가져올 수 없습니다. 클라이언트에서 지원하는 영구 오버라이드나 설정 병합 기능을 사용해 기존 설정을 유지하세요. 다운로드한 구독 파일을 직접 수정하면 다음 구독 업데이트 때 변경 사항이 덮어써질 수 있습니다. 저장 후 클라이언트 안내에 따라 설정을 다시 불러오거나 코어를 재시작하세요.

127.0.0.1은 로컬 기기에서만 접속할 수 있습니다. 실제 수신 주소가 여전히 127.0.0.1:7890이라면 휴대폰은 연결할 수 없습니다. 바인딩 주소를 PC의 LAN 주소로 좁힐 수도 있지만, 192.168.1.20에만 바인딩하면 PC에서 127.0.0.1:7890로 접속하던 프로그램이 작동하지 않을 수 있습니다. 모든 주소에 바인딩할 경우에는 방화벽으로 신뢰할 수 있는 출처만 허용해야 합니다.

설정에 port와 socks-port만 있다면 휴대폰의 HTTP 프록시에는 port에 지정된 포트를 입력하세요. SOCKS 포트가 아닙니다. HTTPS 웹사이트는 보통 HTTP 프록시의 CONNECT 터널을 통해 접속하므로 별도의 인증서를 설치할 필요가 없습니다.

3. PC IP를 확인하고 코어가 실제로 수신 중인지 확인

Windows: 실제 네트워크 어댑터와 7890 포트 확인

PowerShell에서 아래 두 명령을 실행하세요. 첫 번째 명령은 IP 주소를, 두 번째 명령은 수신 상태를 확인합니다. 현재 네트워크에 연결된 ‘이더넷’ 또는 ‘무선 LAN 어댑터 WLAN’을 선택하고 TUN, 가상 머신, 컨테이너 등의 가상 어댑터는 제외하세요.

ipconfig
Get-NetTCPConnection -State Listen -LocalPort 7890 |
  Select-Object LocalAddress, LocalPort, OwningProcess

PC의 Wi-Fi IPv4 주소가 192.168.1.20이라면 휴대폰 프록시 서버에 이 주소를 입력하세요. 수신 주소가 0.0.0.0이면 보통 모든 IPv4 인터페이스에서 연결을 받는다는 뜻입니다. ::가 표시된다면 시스템의 IPv6 및 듀얼 스택 동작도 확인해야 합니다. 이 한 줄만 보고 IPv4로 접속할 수 있다고 단정하지 마세요.

macOS와 Linux: IP 주소와 수신 상태 구분하기

macOS에서는 ‘시스템 설정’ → ‘네트워크’ → 현재 연결 → ‘세부사항’ → ‘TCP/IP’에서 IP를 확인할 수 있습니다. 터미널에서 수신 중인 프로세스도 확인하세요.

lsof -nP -iTCP:7890 -sTCP:LISTEN

Linux에서는 아래 명령으로 인터페이스의 IPv4 주소와 수신 상태를 확인할 수 있습니다. 일부 프로세스 정보는 관리자 권한이 있어야 표시됩니다.

ip -4 addr show
ss -lntp 'sport = :7890'

휴대폰에는 localhost, 127.0.0.1, 0.0.0.0 또는 라우터의 기본 게이트웨이를 입력하면 안 됩니다. 앞의 두 주소는 휴대폰 자체를 가리키고, 세 번째는 수신용 와일드카드 주소이며, 기본 게이트웨이는 보통 라우터를 가리킵니다. 어느 것도 PC 프록시에 접속할 주소가 아닙니다. 재부팅 후 IP가 바뀌지 않도록 라우터의 DHCP 설정에서 PC에 주소를 예약하는 것이 좋습니다.

4. 신뢰할 수 있는 LAN 출처만 방화벽에서 허용

‘LAN 연결 허용’은 코어가 연결을 받을지 결정하고, 운영체제 방화벽은 연결이 코어까지 도달할 수 있는지 결정합니다. 문제 해결을 위해 방화벽 전체를 장시간 끄거나 라우터에서 7890 포트를 인터넷에 포워딩하지 마세요. 기존에 앱을 광범위하게 허용한 규칙이 있다면 함께 확인하고 범위를 좁히세요. 제한 규칙을 새로 추가해도 기존의 광범위한 허용 규칙이 자동으로 취소되지는 않습니다.

Windows: 사설 네트워크에서만 TCP 7890 허용

신뢰할 수 있는 가정용 네트워크에서만 현재 연결을 ‘개인’으로 설정하세요. Windows 11에서 Wi-Fi 설정 경로는 보통 ‘설정’ → ‘네트워크 및 인터넷’ → ‘Wi-Fi’ → 현재 연결의 속성 → ‘네트워크 프로필 유형’입니다. 그런 다음 관리자 권한으로 PowerShell을 열고 다음 규칙을 추가하세요.

New-NetFirewallRule `
  -DisplayName "Clash LAN TCP 7890" `
  -Direction Inbound `
  -Action Allow `
  -Protocol TCP `
  -LocalPort 7890 `
  -Profile Private `
  -RemoteAddress LocalSubnet

이 규칙은 개인 네트워크 프로필에서만 적용되며 로컬 서브넷에서 TCP 7890으로 접속할 수 있도록 허용합니다. 지정된 IP의 휴대폰 한 대만 허용하려면 LocalSubnet을 해당 기기의 실제 IP(예: 192.168.1.30)로 바꿀 수 있습니다. 이 글에서는 HTTP 프록시를 사용하므로 UDP 7890을 추가로 열 필요가 없습니다.

macOS와 Linux: 사용 중인 방화벽 방식에 맞게 설정

macOS에서는 ‘시스템 설정’ → ‘네트워크’ → ‘방화벽’ → ‘옵션’에서 실제로 연결을 받는 클라이언트나 코어 프로그램이 차단되어 있는지 확인하세요. 클라이언트를 업그레이드하거나 코어 파일을 교체한 뒤에는 허용 설정을 다시 확인해야 할 수 있습니다.

Linux에서 UFW를 사용 중이고 가정용 서브넷이 실제로 192.168.1.0/24라면 아래 예시처럼 허용할 수 있습니다. 잘못된 서브넷을 그대로 복사하지 마세요. 원격으로 서버를 관리하는 중이라면 방화벽을 충분히 검토하지 않고 켜거나 초기화하지 마세요.

sudo ufw allow from 192.168.1.0/24 to any port 7890 proto tcp
sudo ufw status numbered

5. 휴대폰과 TV에 HTTP 프록시 설정

iPhone·iPad: 현재 Wi-Fi에 수동 프록시 설정

  1. ‘설정’ → ‘Wi-Fi’로 이동한 다음 현재 네트워크 오른쪽의 정보 버튼을 탭하세요.
  2. ‘프록시 구성’을 찾아 ‘수동’을 선택하세요.
  3. ‘서버’에는 PC의 실제 IP(예: 192.168.1.20)를, ‘포트’에는 7890을 입력하세요.
  4. 프록시 인증을 설정하지 않았다면 ‘인증’을 켜지 마세요. 저장한 뒤 Safari에서 웹페이지를 열어 테스트하세요.

서버 입력란에는 주소만 입력하고 http://나 :7890을 붙이지 마세요. 이 설정은 현재 Wi-Fi에만 적용됩니다. 셀룰러 네트워크나 다른 Wi-Fi로 전환하면 연결 경로가 그대로 유지된다고 볼 수 없습니다.

Android: 현재 네트워크의 고급 설정에서 입력

메뉴 위치는 제조사마다 조금씩 다릅니다. 일반적으로 ‘설정’ → ‘네트워크 및 인터넷’ → ‘인터넷’ → 현재 Wi-Fi → 수정 → ‘고급 옵션’ → ‘프록시’ → ‘수동’ 순서로 이동합니다. 일부 기기는 네트워크 세부정보에서 수정 기능을 먼저 열어야 합니다.

  • 프록시 호스트 이름: PC IP(예: 192.168.1.20)
  • 프록시 포트: 7890
  • 프록시를 사용하지 않을 주소: 처음 테스트할 때는 기본값을 유지하거나 비워 두고, 연결을 확인한 다음 필요한 예외를 설정하세요.

Android 시스템 프록시를 모든 앱이 따르는 것은 아닙니다. 브라우저는 되는데 특정 앱만 작동하지 않는다면 먼저 해당 앱이 시스템 HTTP 프록시를 지원하는지 확인하세요. 곧바로 구독 설정을 바꾸거나 클라이언트를 다시 설치할 필요는 없습니다. 일부 Android 설정 화면에는 사용자 이름과 비밀번호 입력란이 없으므로 프록시 인증을 켜기 전에 기기에서 인증을 처리할 수 있는지 확인하세요.

TV와 TV 박스: 프록시 설정을 찾고 기본 게이트웨이는 변경하지 마세요

Android TV나 제조사 자체 TV 시스템은 ‘설정’ → ‘네트워크 및 인터넷’ → 현재 네트워크 → ‘프록시 설정’에서 ‘수동’ 옵션을 제공할 수 있습니다. PC IP와 HTTP 포트를 입력하면 됩니다. 일부 모델은 특정 네트워크에서만 이 설정을 제공하며, 아예 지원하지 않는 기기도 있습니다.

프록시 옵션이 없다면 PC IP를 ‘게이트웨이’나 ‘DNS’ 입력란에 임의로 넣지 마세요. 게이트웨이 포워딩, DNS 조회, HTTP 프록시는 서로 다른 기능입니다. 게이트웨이 방식으로 구성하려면 라우팅, 포워딩, 접근 제어를 추가로 설정해야 하며 주소 하나를 바꾸는 것만으로는 해결되지 않습니다. TV에서 시스템 프록시를 지원하더라도 특정 동영상 앱은 이를 사용하지 않을 수 있습니다.

6. ‘포트 → 요청 → 규칙’ 순서로 공유 확인

먼저 다른 LAN PC에서 테스트하면 TV 앱을 바로 확인하는 것보다 원인을 파악하기 쉽습니다. Windows에서는 TCP 연결 가능 여부를 확인할 수 있습니다.

Test-NetConnection 192.168.1.20 -Port 7890

TcpTestSucceeded: True는 TCP 연결이 성공했다는 뜻일 뿐, 프록시 인증이나 노드, 트래픽 분기가 정상이라는 뜻은 아닙니다. 이어서 curl로 프록시를 명시한 HTTPS 요청을 보내세요. Windows PowerShell에서는 오래된 환경의 명령 별칭이 간섭하지 않도록 curl.exe를 사용하는 것이 좋습니다.

curl --proxy http://192.168.1.20:7890 --connect-timeout 5 --max-time 20 -I https://example.com/

여기서 5초는 연결 시간 제한, 20초는 명령 전체의 실행 제한 시간이며 성능 측정값이 아닙니다. HTTPS 프록시는 먼저 200 Connection established를 출력할 수 있으므로 대상 사이트의 최종 응답도 확인하세요. 이어서 Clash의 ‘연결’ 또는 로그 화면에서 요청 출처, 대상 도메인, 일치한 규칙, 최종 정책을 확인하세요.

증상우선 확인할 항목해결 방법
연결 시간 초과PC IP, 방화벽, 게스트 네트워크 격리기기 간 통신이 되는지 확인하고 인바운드 규칙과 네트워크 프로필을 살펴보세요.
연결 거부포트 수신 여부, 코어 실행 여부실제 포트와 수신 주소를 확인한 뒤 설정을 다시 불러오세요.
HTTP 407 응답프록시 인증 필요인증을 지원하는 클라이언트에 올바른 인증 정보를 입력하세요.
웹페이지는 열리지만 일부 앱은 작동하지 않음앱이 시스템 프록시를 따르는지 여부앱의 프록시 지원 여부를 확인하고 HTTP 요청과 UDP 트래픽을 구분하세요.
접속은 되지만 외부 IP가 바뀌지 않음DIRECT 또는 다른 정책이 적용됨모드 스위치만 보지 말고 연결 세부정보와 규칙 순서를 확인하세요.
PC가 절전 모드에 들어간 뒤 모든 연결이 끊김호스트와 코어의 실행 상태신뢰할 수 있는 사용 환경에 맞게 전원 설정을 조정하거나 공유를 종료하세요.

규칙 모드에서는 DIRECT에 일치한 연결이 PC에서 대상에 직접 접속하고, 프록시 정책에 일치한 연결만 해당 노드를 거칩니다. 따라서 휴대폰에서 보이는 공인 IP는 요청에 적용된 정책에 따라 달라지며 PC의 모든 앱과 같지 않을 수 있습니다. DNS 경로도 앱, 프록시 프로토콜, 코어 설정에 따라 달라집니다. 브라우저에서 웹페이지가 열린다는 이유만으로 기기의 모든 DNS 요청이 PC를 거친다고 판단할 수는 없습니다.

7. 공유를 마친 뒤 보안 및 설정 복구 확인

가정용 네트워크에도 게스트 기기가 연결될 수 있습니다. 먼저 방화벽에서 특정 출처만 허용하고, 필요한 경우 코어가 지원하는 프록시 인증을 사용하세요. 인증은 네트워크 격리를 대신할 수 없으며 휴대폰과 TV마다 인증 프록시 지원 여부도 다릅니다. 문제 해결을 위한 스크린샷에 구독 주소, 프록시 비밀번호, 제어 인터페이스 인증 정보를 공개하지 마세요.

  1. 네트워크를 바꾸기 전에 공유 끄기: 노트북을 호텔, 회사 또는 공용 Wi-Fi에 연결하기 전에 Allow LAN을 끄고 광범위한 방화벽 허용 규칙도 확인하세요.
  2. 사용을 마친 뒤 기기 설정 복구: PC를 끈 뒤에도 기기에서 이전 주소로 계속 연결을 시도하지 않도록 휴대폰이나 TV의 Wi-Fi 프록시를 ‘끔’ 또는 ‘없음’으로 바꾸세요.
  3. 임시 허용 규칙 삭제: Windows에서는 아래 명령을 실행해 이 글에서 만든 규칙을 삭제할 수 있습니다. Linux에서는 실제로 추가한 내용에 맞춰 해당 UFW 규칙을 삭제하세요.
  4. 업데이트 후 다시 확인: 구독 업데이트, 클라이언트 업그레이드 또는 포트 변경 후 실행 설정과 수신 상태를 다시 확인해 화면에 표시된 값과 코어의 실제 값이 다른지 살펴보세요.
Remove-NetFirewallRule -DisplayName "Clash LAN TCP 7890"

반복해서 확인할 수 있는 공유 연결은 PC 주소 고정, 코어의 올바른 수신 설정, 신뢰할 수 있는 출처의 접속 허용, 기기의 HTTP 프록시 설정, 연결 로그에서 최종 경로 확인 순서로 구성됩니다. 이 순서대로 점검하면 TUN, 전역 모드, DNS 설정을 한꺼번에 바꾸는 것보다 문제를 쉽게 찾을 수 있습니다. 규칙과 네트워크 스택을 더 알아보려면 프로토콜 안내서를, 기본 개념은 개념 빠른 참조를 확인하세요.