혼합 포트와 allow-lan 설정 가이드: 로컬 네트워크 기기와 프록시 공유

먼저 mixed-port, port, socks-port부터 구분하기

mihomo는 HTTP, SOCKS5, 혼합 프록시 진입점을 동시에 제공할 수 있습니다. 최종적으로는 모두 같은 프록시 규칙과 정책 그룹으로 연결되지만, 클라이언트가 접속하는 입구는 서로 다릅니다. 로컬 네트워크에서 프록시를 공유할 때는 보통 mixed-port 하나를 열어 두는 방법이 가장 간단합니다. 휴대폰에서는 HTTP 프록시 포트로 입력할 수 있고, SOCKS5를 지원하는 앱도 같은 포트에 연결할 수 있으며 서버가 접속 프로토콜을 자동으로 식별합니다.

설정 필드	주요 포트	접속 프로토콜	사용 사례
`mixed-port`	`7890`	HTTP 및 SOCKS5	로컬 네트워크 진입점 하나만 관리하려는 경우
`port`	`7890`	HTTP	시스템 프록시, 브라우저, TV 셋톱박스에 HTTP 프록시 입력란만 있는 경우
`socks-port`	`7891`	SOCKS5	앱이 SOCKS5를 지원하거나 UDP 기능이 필요한 경우
`redir-port`	`7892`	투명 전달 진입점	Linux 라우팅 규칙으로 리디렉션하며 휴대폰에 수동 입력하지 않는 경우
`tproxy-port`	`7893`	TPROXY 진입점	라우터에서 투명 프록시를 사용하면서 원래 대상 정보를 유지하는 경우

mixed-port는 HTTP 데이터를 SOCKS5로 변환하는 기능도 아니고, 별도의 전달 계층을 추가로 만드는 기능도 아닙니다. 하나의 리스닝 포트에서 클라이언트 핸드셰이크 유형을 판별할 뿐입니다. “PC에서 Clash를 실행하고 휴대폰에 PC IP와 포트를 입력하는” 환경에서는 포트 충돌과 방화벽 규칙 수를 줄일 수 있습니다.

allow-lan을 켜면 무엇이 달라질까

기본값처럼 루프백 주소에서만 리스닝하면 프록시 진입점은 mihomo가 실행 중인 PC에서만 접근할 수 있습니다. allow-lan: true를 사용하면 로컬 네트워크 기기가 인바운드 프록시에 연결할 수 있지만, 휴대폰 설정을 자동으로 바꾸거나 PC를 기본 게이트웨이로 만들지는 않습니다. 클라이언트에서 프록시 서버 주소를 직접 입력하거나 라우터·투명 프록시 규칙으로 트래픽을 가로채야 합니다.

먼저 검증에 사용할 기본 설정은 다음과 같습니다. PC의 가정용 네트워크 IPv4 주소가 192.168.50.23이고 휴대폰과 PC가 같은 라우터에 연결되어 있으며 포트는 7890이라고 가정합니다.

mixed-port: 7890
allow-lan: true
bind-address: "*"
mode: rule
log-level: info

authentication:
  - "livingroom:change-this-password"

bind-address: "*"는 사용 가능한 주소에서 리스닝한다는 뜻입니다. 실제로 접근 가능한 범위는 운영체제 방화벽, 라우터의 게스트 네트워크 격리, 액세스 포인트의 클라이언트 격리 설정에 따라 달라집니다. PC가 고정된 로컬 네트워크 주소를 장기간 사용한다면 특정 네트워크 인터페이스에 리스닝 주소를 제한할 수도 있습니다. 예시는 다음과 같습니다.

mixed-port: 7890
allow-lan: true
bind-address: 192.168.50.23
mode: rule

authentication:
  - "phone:use-a-long-password"

특정 주소에 바인딩하면 경계를 명확히 관리하기 좋지만, DHCP가 주소를 다시 할당하면 해당 주소가 더 이상 PC에 속하지 않아 mihomo가 시작되지 않을 수 있습니다. 장기간 공유할 때는 라우터 DHCP 설정에서 PC 네트워크 인터페이스에 192.168.50.23을 예약하거나, 모든 주소에서 리스닝하되 운영체제 방화벽으로 허용할 출발지 네트워크를 제한하세요.

GUI 스위치와 YAML의 관계

Clash GUI 클라이언트마다 메뉴 이름은 조금씩 다릅니다. 일반적으로 「설정」→「매개변수 설정」→「로컬 네트워크 연결 허용」에서 찾을 수 있으며, 같은 영역에 “혼합 포트” 또는 “포트” 항목이 표시됩니다. 스위치를 켠 뒤에는 설정이나 실행 로그에서 최종값이 allow-lan: true인지 확인하고 실제 포트도 기록하세요. 일부 클라이언트는 구독을 다시 불러와도 전역 매개변수를 유지하지만, 일부는 오버라이드 설정을 우선하므로 구독 파일의 필드만 확인해서는 안 됩니다.

프록시 포트와 제어 포트도 구분해야 합니다. external-controller: 127.0.0.1:9090은 패널이나 API 제어용이며 휴대폰에서 사용하는 HTTP 프록시가 아닙니다. 휴대폰 프록시 입력란에 9090을 넣으면 대개 연결 실패나 HTTP 상태 오류가 발생합니다.

PC의 올바른 로컬 네트워크 주소 찾기

휴대폰에는 127.0.0.1이나 통신사가 할당한 공인 주소가 아닌 PC의 로컬 네트워크 주소를 입력해야 합니다. 휴대폰에서 127.0.0.1은 휴대폰 자체를 가리킵니다. 가정용 네트워크에서 흔히 사용하는 주소 대역은 192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12입니다.

Windows 11에서 주소 확인

「설정」→「네트워크 및 인터넷」을 엽니다.
현재 사용하는 「Wi-Fi」 또는 「이더넷」을 선택합니다.
「하드웨어 속성」으로 이동해 “IPv4 주소”를 찾습니다.
192.168.50.23과 비슷한 주소를 기록하고 기본 게이트웨이 192.168.50.1은 입력하지 마세요.

터미널에서 ipconfig를 실행해 현재 연결에 사용하는 네트워크 인터페이스의 “IPv4 주소”를 확인할 수도 있습니다. 유선, 무선, 가상 머신, VPN 인터페이스가 동시에 있다면 휴대폰과 같은 서브넷에 있는 물리 인터페이스를 선택하세요. 휴대폰이 192.168.50.88이라면 PC도 보통 192.168.50.x 주소를 사용해야 합니다.

macOS에서 주소 확인

「시스템 설정」→「네트워크」를 엽니다.
상태가 “연결됨”인 Wi-Fi 또는 이더넷을 선택합니다.
「세부사항」→「TCP/IP」를 클릭합니다.
IPv4 주소를 확인합니다. 예: 192.168.50.23

휴대폰과 TV 셋톱박스에서 프록시 설정하기

iPhone 및 iPad

「설정」→「Wi-Fi」로 이동합니다.
현재 네트워크 오른쪽의 정보 버튼을 탭합니다.
아래로 스크롤해 「프록시 구성」에서 「수동」을 선택합니다.
서버에 PC 주소를 입력합니다. 예: 192.168.50.23
포트에 7890을 입력합니다.
authentication을 설정했다면 인증을 켜고 해당 사용자 이름과 비밀번호를 입력합니다.

iOS의 Wi-Fi 수동 프록시는 주로 HTTP 프록시 설정이며 시스템 전체에 적용되는 TUN과는 다릅니다. 시스템 프록시를 따르는 대부분의 앱은 연결할 수 있지만, 자체 네트워크 스택을 사용하거나 시스템 프록시를 무시하거나 UDP만 전송하는 앱은 PC를 거치지 않을 수 있습니다. 브라우저는 정상적으로 접속되는데 특정 게임이나 스트리밍 앱이 직접 연결되는 이유도 여기에 있습니다.

Android 및 TV 셋톱박스

「설정」→「네트워크 및 인터넷」→「인터넷」 또는 현재 Wi-Fi를 엽니다.
네트워크 편집을 선택하고 「고급 옵션」을 펼칩니다.
프록시를 「수동」으로 변경합니다.
프록시 호스트 이름에 192.168.50.23, 프록시 포트에 7890을 입력합니다.
필요하다면 제외 목록에 로컬 네트워크 도메인을 입력하고 저장한 뒤 앱을 다시 열어 테스트하세요.

Android 제조사별 UI에서는 「Wi-Fi」→「연결된 네트워크」→「네트워크 수정」에 설정이 있을 수 있습니다. TV 셋톱박스에 “프록시 서버”와 “프록시 포트”만 있다면 PC 주소와 혼합 포트를 동일하게 입력하세요. 일부 TV 앱은 시스템 HTTP 프록시를 따르지 않으므로 셋톱박스의 Wi-Fi 프록시만 변경해서는 모든 트래픽을 처리할 수 없습니다.

게임, UDP, 스마트 TV 앱, 시스템 프록시를 읽지 않는 프로그램까지 일괄적으로 분기하려면 mihomo를 메인 라우터나 보조 라우터에 배포하거나, 전달 설정이 가능한 Linux 호스트에서 TPROXY/TUN을 구성해야 합니다. PC에 IP 포워딩, NAT, 투명 프록시 규칙을 활성화하지 않은 상태에서 휴대폰의 기본 게이트웨이만 PC 주소로 바꿔도 사용할 수 있는 경로가 자동으로 만들어지지는 않습니다.

공유 후에도 출구는 PC의 규칙이 결정합니다

로컬 네트워크 기기가 mixed-port에 연결되면 요청은 PC의 mihomo로 들어갑니다. 구독의 노드, 정책 그룹, DNS 설정, rules는 모두 PC에 현재 로드된 설정을 따릅니다. 휴대폰에서 구독을 다시 가져올 필요는 없으며, PC의 규칙 모드를 우회해 직접 노드를 선택할 수도 없습니다.

예를 들어 설정이 mode: rule이면 트래픽은 위에서 아래 순서로 규칙과 대조됩니다. 라우터 관리 페이지, NAS, 화면 공유 기기에 접근할 때 프록시 노드로 전송되지 않도록 로컬 네트워크 주소는 보통 직접 연결로 처리해야 합니다.

rules:
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - DOMAIN-SUFFIX,example.com,Proxy
  - MATCH,Proxy

설정에서 Fake-IP를 사용하면 휴대폰이 HTTP 프록시로 도메인에 접속할 때 도메인 처리는 대개 프록시 측에서 이루어집니다. 하지만 프록시를 거치지 않는 휴대폰 자체의 DNS 요청은 현재 Wi-Fi의 DNS를 계속 사용합니다. “웹페이지는 열리는데 앱 내부 도메인 해석에 문제가 생기는” 경우에는 먼저 해당 앱이 실제로 시스템 프록시를 사용하는지 확인하고, 곧바로 구독 노드를 변경하지 마세요.

재현 가능한 방식으로 먼저 검증하기

먼저 PC에서 127.0.0.1:7890을 통해 대상 웹사이트에 접속할 수 있는지 확인합니다.
테스트 트래픽이 모바일 네트워크로 우회하지 않도록 휴대폰의 셀룰러 데이터를 끕니다.
휴대폰에 192.168.50.23:7890을 입력한 뒤 이전에 캐시되지 않은 웹페이지를 엽니다.
Clash 연결 목록에서 출발지 주소에 휴대폰 IP(예: 192.168.50.88)가 표시되는지 확인합니다.
해당 연결에 적용된 규칙, 정책 그룹, 최종 노드를 확인합니다.

같은 Wi-Fi에서 휴대폰과 PC 사이의 로컬 네트워크 왕복 지연 시간은 보통 1–10 ms 정도여야 합니다. 지속적으로 50 ms를 초과한다면 먼저 무선 신호, 2.4GHz 혼잡, PC 절전 상태를 점검하세요. 이 지연 시간은 로컬 네트워크 경로만 반영하며 프록시 노드의 외부 네트워크 품질을 의미하지 않습니다.

인증, 방화벽, 리스닝 범위

로컬 네트워크에서 리스닝을 허용하면 같은 네트워크에서 해당 포트에 도달할 수 있는 모든 기기가 연결을 시도할 수 있습니다. 가정 내 기기가 적더라도 사용자 이름과 긴 비밀번호를 설정하고 운영체제 방화벽으로 출발지를 제한하는 것이 좋습니다. 회사, 기숙사, 호텔처럼 사용자가 많은 네트워크에서는 프록시를 전체 서브넷에 직접 노출하지 않는 편이 안전합니다.

mihomo 인바운드 인증

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

authentication:
  - "phone:V7k9m2Qp4s8L"
  - "tvbox:R6w3n8Hx5c2A"

기기마다 별도의 계정을 배정하면 특정 기기의 사용을 중지할 때 해당 항목만 삭제하면 됩니다. 비밀번호는 YAML에 저장되므로 PC에서 설정 파일을 읽을 수 있는 권한을 제한해야 합니다. GUI 클라이언트가 실행 설정을 자동으로 생성한다면 구독 업데이트 후 필드가 사라지지 않도록 “오버라이드” 또는 “전역 확장 설정” 기능에서 관리하세요.

시스템 방화벽은 가정용 네트워크 대역만 허용하기

Windows 방화벽에서 인바운드 규칙을 만들 때 TCP와 로컬 포트 7890을 선택하고, 프로필은 “개인”만 활성화한 뒤 원격 IP 주소에서 192.168.50.0/24로 제한할 수 있습니다. 문제를 확인한다는 이유로 방화벽 전체를 장시간 끄지 마세요. macOS에서 타사 방화벽이나 pf를 사용하더라도 네트워크 대역과 포트를 조건으로 허용해야 합니다.

mixed-port로 일반 HTTP 및 SOCKS TCP 연결을 받으려면 최소한 TCP 포트가 필요합니다. SOCKS5로 UDP를 사용한다면 클라이언트 기능, mihomo 리스닝 설정, 운영체제 방화벽의 UDP 규칙도 확인해야 합니다. TV 셋톱박스의 HTTP 프록시는 보통 SOCKS UDP를 사용하지 않으므로 TCP 7890만 열어도 기본적인 웹 및 앱 검증을 진행할 수 있습니다.

연결 실패를 단계별로 점검하는 순서

1단계: mihomo가 실제로 리스닝 중인지 확인

먼저 클라이언트 실행 로그와 포트 설정을 확인합니다. Windows에서는 netstat -ano | findstr :7890을, macOS 또는 Linux에서는 lsof -nP -iTCP:7890 -sTCP:LISTEN을 실행할 수 있습니다. 127.0.0.1:7890만 보이면 서비스가 로컬 PC로 제한된 상태입니다. 0.0.0.0:7890, *:7890 또는 PC의 로컬 네트워크 주소가 보여야 원격 접속이 가능합니다.

2단계: 로컬 네트워크와 방화벽 확인

휴대폰과 PC가 게스트 네트워크가 아닌 같은 일반 Wi-Fi에 연결되어 있는지 확인합니다.
DHCP 갱신으로 PC 주소가 바뀌지 않았는지 확인합니다.
Windows의 현재 네트워크가 “공용 네트워크”로 인식되어 개인 네트워크 허용 규칙이 적용되지 않는지 확인합니다.
라우터에서 AP 격리, 클라이언트 격리 또는 서로 다른 VLAN 간 차단을 사용 중인지 확인합니다.
다른 프로세스가 포트를 사용해 Clash가 실제로 다른 포트로 변경되지 않았는지 확인합니다.

3단계: “접속 불가”와 “잘못된 규칙 적용” 구분하기

휴대폰에 프록시 서버 연결 거부가 즉시 표시된다면 보통 리스닝 주소, 포트 또는 방화벽 문제입니다. Clash 연결 목록에 요청이 보이지만 웹사이트가 시간 초과된다면 노드, DNS, 규칙 적용 결과를 계속 확인해야 합니다. 407 Proxy Authentication Required가 반환되면 프록시에는 도달했지만 사용자 이름이나 비밀번호가 없거나 잘못 입력된 상태입니다.

특정 앱만 실패한다면 먼저 브라우저를 기준으로 테스트하세요. 브라우저가 정상이라면 로컬 네트워크 경로, HTTP 프록시, 인증은 대체로 정상입니다. 실패하는 앱은 시스템 프록시를 읽지 않거나 QUIC/UDP를 사용하거나 자체 네트워크 설정을 사용할 수 있습니다. 이때 allow-lan을 반복해서 전환해도 결과가 달라지지 않는 경우가 많습니다.

장기간 사용할 때의 구성 선택

휴대폰 한 대를 PC에 임시로 연결하려면 mixed-port: 7890, allow-lan: true, 인증, 로컬 네트워크용 방화벽 규칙이면 충분합니다. PC는 절전 모드에 들어가지 않아야 하고 Clash 클라이언트도 계속 실행되어야 합니다. PC가 절전 상태가 되거나 Wi-Fi를 전환하거나 코어가 종료되면 하위 기기는 즉시 프록시 연결을 잃습니다.

여러 대의 TV, 게임 콘솔, IoT 기기를 안정적으로 분기하려면 PC 공유는 전원 상태, 주소 변경, 앱의 프록시 호환성에 제약을 받습니다. 이 경우 라우터나 보조 라우터에서 mihomo를 실행하고 TUN, REDIR 또는 TPROXY로 전달을 가로챈 뒤 출발지 IP, 대상 도메인, 규칙 세트에 따라 트래픽을 분기하는 편이 적합합니다. 수동으로 프록시를 지정해야 하는 기기에는 혼합 포트를 계속 사용할 수 있지만, 더 이상 가정 전체 네트워크의 유일한 진입점으로 운영하지 않는 것이 좋습니다.

최종 점검은 네 가지로 정리할 수 있습니다. 프록시 포트가 기기에 입력한 값과 일치해야 하고, allow-lan과 리스닝 주소가 원격 연결을 허용해야 하며, 운영체제 방화벽은 신뢰할 수 있는 네트워크 대역만 허용해야 합니다. 또한 규칙 모드에서는 사설 주소를 직접 연결로 유지해야 합니다. 포트, DNS, TUN, 구독을 한꺼번에 바꾸기보다 네 항목을 각각 검증하는 편이 문제를 찾기 쉽습니다.