Clash LAN 프록시 공유: mixed-port 및 allow-lan 설정 방법

프록시 공유 연결 경로와 사용 범위

LAN 프록시 공유는 다른 기기가 Clash 또는 Clash Meta(mihomo) 코어가 PC에서 열어 둔 프록시 포트에 연결하도록 하는 기능입니다. 요청은 “휴대폰이나 TV → PC의 LAN 주소와 포트 → 코어 규칙 → 해당 아웃바운드” 순서로 전달됩니다. PC가 계속 켜져 있고 클라이언트 코어가 실행 중이어야 하며, PC가 절전 모드에 들어가면 연결이 끊깁니다.

이 글에서는 PC의 IPv4 주소를 192.168.1.20, 혼합 포트를 7890, 홈 네트워크 대역을 192.168.1.0/24로 설정한 예를 사용합니다. 이는 설정 예시일 뿐, 독자의 네트워크를 확인한 결과가 아닙니다. 실제로 설정할 때는 현재 네트워크 어댑터에 할당된 주소로 바꿔야 합니다.

• 적합한 경우: 기기나 앱에서 HTTP 또는 SOCKS5 프록시를 직접 설정할 수 있는 경우
• 필수 조건: 기기에서 PC의 LAN 주소에 직접 접속할 수 있고, PC 방화벽이 해당 인바운드 연결을 허용해야 합니다.
• 주의 사항: Wi-Fi의 HTTP 프록시 설정은 일반적으로 모든 앱에 적용되지 않으며, 기기 전체에 적용되는 투명 프록시와도 다릅니다.
• 차이점: 프록시 포트만 공유할 때는 PC를 기본 게이트웨이로 설정하거나 TUN 모드를 켤 필요가 없습니다.

mixed-port, allow-lan, bind-address

세 필드는 각기 다른 기능을 합니다. 어떤 프로토콜을 수신할지, LAN 기기의 연결을 허용할지, 어느 로컬 주소에 바인딩할지를 각각 지정합니다. 모두 설정 파일의 최상위 항목이며 proxies, proxy-groups, rules와 같은 단계에 둬야 합니다. 특정 프록시 노드 아래에 들여쓰면 안 됩니다.

공유에 필요한 최소 필드

mixed-port: 7890
allow-lan: true
bind-address: "*"

기존 설정에 병합할 필드 예시이며, 구독 설정 전체가 아닙니다. 기존 노드, 정책 그룹, DNS, 규칙은 그대로 유지하세요. 최상위에 mixed-port가 이미 있다면 기존 값을 수정하고 같은 이름의 필드를 추가로 만들지 마세요. port나 다른 리스너가 7890을 중복으로 사용하지 않는지도 확인하세요.

"*"는 별칭 문법으로 해석되지 않도록 반드시 따옴표를 유지해야 합니다. 특정 네트워크 어댑터에만 바인딩하려면 bind-address를 192.168.1.20으로 바꾸세요. 이 방법은 주소가 바뀌지 않는다는 전제가 필요합니다. PC가 네트워크를 전환하거나 DHCP 주소가 달라지면 리스닝에 실패할 수 있으므로 설정도 함께 수정해야 합니다.

external-controller는 제어 인터페이스이며 기기가 연결할 프록시 포트가 아닙니다. 휴대폰에는 mixed-port에 지정된 7890을 입력해야 하며, 제어 인터페이스 포트를 입력하면 안 됩니다. 프록시 공유를 위해 제어 인터페이스를 LAN에 노출할 필요는 없습니다.

PC 설정: 주소 확인, 설정 적용, 리스닝 확인

1. 현재 사용 중인 LAN IPv4 주소 확인

Windows에서는 “설정” → “네트워크 및 인터넷” → “Wi-Fi” → 현재 네트워크 속성으로 이동해 IPv4 주소를 확인합니다. 유선 연결은 “이더넷” 페이지에서 확인하세요. 또는 터미널을 열고 ipconfig를 실행해 현재 연결된 어댑터의 IPv4 주소와 서브넷 마스크를 찾을 수 있습니다.

macOS에서는 “시스템 설정” → “네트워크” → 현재 연결 → “세부사항” → “TCP/IP”로 이동합니다. 루프백 주소 127.0.0.1, 가상 네트워크 어댑터 주소, 연결이 끊긴 어댑터 주소는 사용하지 마세요. 다른 기기에서 사용하는 127.0.0.1은 해당 기기 자신을 가리키며 이 PC를 가리키지 않습니다.

2. 실제 적용 중인 설정 수정

1. 클라이언트에서 현재 활성화된 설정을 확인하고 기존 포트와 LAN 접속 허용 설정을 기록합니다.
2. 클라이언트에서 지원하는 설정 편집, 오버라이드 또는 병합 기능을 사용해 위의 최상위 필드 세 개를 추가합니다.
3. 저장한 뒤 설정을 다시 불러옵니다. 클라이언트에서 코어 재시작을 요구하면 안내에 따라 진행합니다.
4. 실행 로그에서 YAML 파싱 오류나 포트 충돌 오류가 없는지 확인합니다.

클라이언트마다 설정 이름과 오버라이드 우선순위가 다릅니다. 인터페이스의 “LAN 연결 허용”은 보통 allow-lan에 해당하지만, 구독에서 생성된 파일을 직접 편집하면 업데이트 시 변경 내용이 덮어써질 수 있습니다. 해당 클라이언트가 제공하는 영구 오버라이드 기능을 우선 사용한 뒤, 편집기의 원본 구독 내용만 확인하지 말고 최종 실행 설정을 확인하세요.

3. 접근 가능한 주소에서 포트가 리스닝 중인지 확인

Windows PowerShell에서 아래 명령을 실행해 TCP 리스닝 주소를 확인할 수 있습니다. macOS에서는 두 번째 명령을 사용할 수 있습니다.

# Windows PowerShell
Get-NetTCPConnection -State Listen -LocalPort 7890

# macOS
lsof -nP -iTCP:7890 -sTCP:LISTEN

127.0.0.1:7890만 표시된다면 다른 기기는 PC의 LAN IPv4 주소를 통해 이 포트에 접속할 수 없습니다. 모든 IPv4 주소에 바인딩한 경우에는 보통 0.0.0.0:7890으로 표시됩니다. 단일 주소에 바인딩했다면 해당 주소인 192.168.1.20:7890이 보여야 합니다. IPv6 와일드카드 주소로 표시될 경우에는 IPv4의 접근 가능 여부를 시스템의 듀얼 스택 동작과 원격 테스트를 함께 확인해야 합니다. 리스닝 표시 하나만으로 판단할 수 없습니다.

방화벽 및 Wi-Fi 격리 설정

allow-lan: true를 설정해도 운영체제 방화벽이 자동으로 포트를 허용하지는 않습니다. 포트는 리스닝 중인데 다른 기기에서 연결 시간 초과가 발생한다면 먼저 네트워크 프로필, 인바운드 규칙, 무선 네트워크 격리를 확인하세요. 노드부터 바꾸지는 마세요.

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

신뢰할 수 있는 홈 네트워크에서 Windows가 현재 연결을 “사설 네트워크”로 인식하는지 먼저 확인합니다. “Windows 보안” → “방화벽 및 네트워크 보호” → “고급 설정”을 열고 “인바운드 규칙”에서 새 포트 규칙을 만듭니다. TCP, 특정 로컬 포트 7890, 연결 허용을 선택하고 “사설”만 체크하세요. 규칙의 “속성” → “범위”에서 원격 IP 범위를 실제 홈 네트워크 대역으로 제한합니다.

관리자 권한으로 실행한 PowerShell에서 범위를 제한하는 규칙을 만들 수도 있습니다. 아래 예시는 192.168.1.0/24에서 PC 주소 192.168.1.20의 TCP 7890에만 접속하도록 허용합니다. 실행 전에 실제 네트워크 주소에 맞게 수정하세요.

New-NetFirewallRule -DisplayName "Clash LAN TCP 7890" `
  -Direction Inbound -Action Allow -Protocol TCP `
  -LocalAddress 192.168.1.20 -LocalPort 7890 `
  -RemoteAddress 192.168.1.0/24 -Profile Private

이 규칙은 이 글의 HTTP 프록시 연결 테스트를 위한 것입니다. SOCKS5 UDP 포워딩까지 설정된다는 뜻은 아닙니다. 기존에 광범위하게 허용하는 규칙이 있다면 함께 확인하세요. 제한 규칙을 추가해도 다른 허용 규칙이 자동으로 제한되지는 않습니다. 연결 문제를 해결하려고 방화벽 전체를 장기간 꺼 두지 마세요.

macOS 및 라우터 측 점검

• macOS의 “시스템 설정” → “네트워크” → “방화벽” → “옵션”에서 해당 클라이언트 또는 실제 실행 중인 코어의 인바운드 접근 권한을 확인하세요. “모든 수신 연결 차단”이 켜져 있으면 공유가 되지 않을 수 있습니다.
• 휴대폰과 PC가 같은 이름의 Wi-Fi에 연결되어 있어도 게스트 네트워크나 서로 다른 VLAN을 사용하거나 AP 격리로 인해 통신이 차단될 수 있습니다.
• PC는 유선 LAN, 휴대폰은 Wi-Fi를 사용하더라도 반드시 문제가 생기는 것은 아닙니다. 라우터에서 두 기기 간 통신을 허용하는지가 중요합니다.
• 라우터에 공인 포트 포워딩을 설정할 필요가 없으며, 프록시 포트를 DMZ에 추가하지 마세요.

휴대폰·TV·게임기에는 무엇을 입력할까

iPhone 및 iPad: 현재 Wi-Fi의 HTTP 프록시 설정

1. “설정” → “Wi-Fi”로 이동해 현재 네트워크 옆의 정보 버튼을 탭합니다.
2. “프록시 구성”을 열고 “수동”을 선택합니다.
3. 서버에는 192.168.1.20, 포트에는 7890을 입력합니다.
4. 이 글의 기본 설정에는 프록시 인증이 없으므로 인증은 끈 상태로 두고 저장한 뒤 브라우저에서 테스트합니다.

서버 입력란에는 IP 주소만 입력하세요. http://를 붙이거나 포트까지 함께 입력하면 안 됩니다. 이 설정은 현재 Wi-Fi에만 적용됩니다. 모바일 데이터로 전환하면 이 LAN 주소를 계속 사용할 수 없습니다.

Android: 현재 네트워크에서 수동 프록시 설정

일반적인 경로는 “설정” → “네트워크 및 인터넷” → “인터넷” → 현재 Wi-Fi → 수정 → “고급 옵션” → “프록시” → “수동”입니다. 제조사별로 메뉴 이름은 다를 수 있습니다. 프록시 호스트 이름에는 192.168.1.20, 프록시 포트에는 7890을 입력합니다. 테스트 중에는 복잡한 우회 주소 목록을 추가하지 마세요. 테스트 대상 도메인이 제외될 수 있습니다.

Android의 Wi-Fi 프록시도 앱이 시스템 프록시 설정을 따르는 경우에만 적용됩니다. 브라우저는 정상인데 특정 앱만 연결되지 않는다고 해서 바로 포트 설정 오류로 볼 수는 없습니다. 해당 앱이 HTTP 프록시를 지원하는지, 별도의 네트워크 설정을 제공하는지 먼저 확인하세요.

TV 및 게임기: 기기에서 지원하는 프록시 종류 확인

네트워크 설정에 “HTTP 프록시 서버”가 있다면 같은 주소와 포트를 입력하면 됩니다. SOCKS5 설정만 제공하는 경우에도 혼합 포트에서 해당 프록시 요청을 받을 수 있지만, 앱이 실제로 SOCKS5를 지원해야 합니다. 수동 프록시 설정이 없는 기기는 DNS를 수정하는 것만으로 HTTP 프록시를 사용할 수 없습니다.

게임기에서 HTTP 프록시를 설정하면 스토어 화면, 다운로드 또는 로그인 과정에 영향을 줄 수 있지만, 온라인 게임 트래픽이 해당 포트를 거친다는 보장은 없습니다. 특히 UDP 통신은 웹페이지 한 번이 열린 것만으로 게임 트래픽 전체가 프록시를 거친다고 판단할 수 없습니다. PC에서 IP 포워딩, 라우팅, 투명 프록시를 별도로 구성하지 않았다면 PC 주소를 기본 게이트웨이에 입력하지 마세요.

단계별 확인: 포트, 프록시 요청, 규칙 아웃바운드

먼저 연결이 리스닝 포트에 도달하는지 확인한 뒤 대상 사이트와 규칙을 점검합니다. 아래 명령은 다른 LAN 기기에서 실행해야 합니다. 프록시를 실행 중인 PC에서 테스트하면 로컬 경로만 확인할 수 있어 방화벽과 무선 격리를 충분히 검증할 수 없습니다.

# Windows PowerShell: 원격 TCP 포트 확인
Test-NetConnection 192.168.1.20 -Port 7890

# Windows에서는 curl.exe 사용, macOS 또는 Linux에서는 curl 사용
curl.exe -I --connect-timeout 5 --max-time 15 \
  --proxy http://192.168.1.20:7890 https://example.com/

위의 백슬래시 줄바꿈은 일반적인 Unix 셸에서 사용할 수 있습니다. Windows에서는 PowerShell의 줄바꿈 문법 차이를 피하려면 curl 명령을 아래와 같이 한 줄로 작성하세요.

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

https://example.com/은 연결 테스트용 대상이며, 프록시 출구를 전용으로 검증하는 서비스는 아닙니다. 200 Connection established가 표시되면 HTTP CONNECT 터널이 만들어졌다는 뜻일 뿐입니다. 이후 TLS 연결과 대상 서버의 응답도 확인하세요. 그런 다음 클라이언트의 연결 목록에서 출발지 IP, 적용된 규칙, 아웃바운드 경로를 확인해 요청이 DIRECT로 나갔는지 특정 프록시 정책을 거쳤는지 확인합니다.

SOCKS5를 확인하려면 curl --proxy socks5h://192.168.1.20:7890 https://example.com/을 사용할 수 있습니다. socks5h는 도메인 해석을 프록시 측에 맡기지만, socks5는 일반적으로 curl이 로컬에서 도메인을 해석합니다. 두 방식의 결과가 다를 수 있지만, 그것만으로 혼합 포트에 문제가 있다고 볼 수는 없습니다.

규칙, DNS, TUN 및 일상적인 관리

공유 기기도 PC의 규칙을 사용합니다

mode: rule에서 혼합 포트로 들어온 요청은 rules 순서대로 매칭되며, PC의 정책 그룹에서 현재 선택한 아웃바운드를 사용합니다. LAN 공유를 켠다고 휴대폰 전용 규칙이 자동으로 만들어지거나 모든 사이트가 원격 노드를 통과하는 것은 아닙니다. 어떤 경로로 나가는지 확인하려면 PC 클라이언트에 “연결됨”이라고 표시되는지만 보지 말고 해당 요청의 매칭 결과를 확인해야 합니다.

프록시 포트와 DNS 서비스 포트는 다릅니다

휴대폰에서 HTTP 프록시를 설정했다고 DNS 주소까지 무조건 PC IP로 바꿀 필요는 없습니다. mixed-port는 DNS 리스닝 포트가 아닙니다. 내장 DNS의 활성화 여부와 리스닝 주소는 dns.enable, dns.listen 등의 설정으로 제어합니다. LAN에 DNS 서비스를 제공할지는 별도로 결정해야 하며 UDP/TCP 포트와 방화벽도 따로 고려해야 합니다.

HTTPS 요청에서 HTTP CONNECT로 도메인을 전달하면 프록시가 이후의 DNS 조회에 관여하는 경우가 많습니다. 하지만 앱이 직접 DNS를 조회하거나, 직접 연결을 만들거나, 다른 네트워크 스택을 사용할 수도 있습니다. 따라서 수동 HTTP 프록시를 설정했다고 해서 모든 DNS 요청이 코어를 통과한다고 단정할 수는 없습니다.

공유 포트 사용에 TUN은 필요하지 않습니다

TUN은 가상 네트워크 어댑터로 들어오는 트래픽을 가로채며, 주로 PC 자체의 투명 프록시에 사용됩니다. 휴대폰에서 PC의 7890 포트에 접속하게 하는 데 TUN을 추가로 켤 필요는 없습니다. PC에서 TUN을 켜더라도 같은 Wi-Fi의 모든 기기 트래픽이 자동으로 처리되지는 않습니다. 해당 기기의 라우팅에서 트래픽을 적절한 게이트웨이로 보내야 합니다.

주소를 고정하고 복구 방법도 준비하세요

• 라우터에서 PC의 DHCP 주소 예약을 설정하면 PC 재시작 후 휴대폰에 입력한 프록시 주소가 바뀌는 일을 줄일 수 있습니다.
• 구독 업데이트 후에도 영구 오버라이드가 적용되는지 확인하세요. 특히 allow-lan, 리스닝 주소, 포트를 점검해야 합니다.
• 장기간 사용할 경우 클라이언트에서 지원하는 authentication 인증 설정을 확인하세요. TV 등 일부 기기는 인증을 지원하지 않을 수 있으므로 호환성을 먼저 확인해야 합니다.
• 공유를 중단할 때는 기기의 Wi-Fi 프록시를 “끔” 또는 “사용 안 함”으로 되돌린 다음, PC의 allow-lan을 false로 설정하고 다시 불러오세요.
• 더 이상 필요하지 않은 방화벽 인바운드 규칙을 삭제하세요. 그래야 나중에 다른 프로세스가 같은 포트를 사용하더라도 LAN에서 접속할 수 있는 상태로 남지 않습니다.

공유가 정상적으로 완료되었다고 판단하려면 원격 기기에서 지정한 포트에 연결할 수 있어야 하고, 실제 요청이 코어의 연결 목록에 표시되며, 예상한 규칙에 매칭되고, 해당 기기의 앱이 프록시 방식을 지원해야 합니다. 이 네 가지를 따로 확인하면 DNS, TUN, 게이트웨이, 노드를 한꺼번에 바꾸는 것보다 문제를 쉽게 찾을 수 있습니다.