Clash 혼합 포트와 LAN 프록시: 휴대폰 및 다른 기기에서 공유 설정하기

프록시 공유 작동 경로

Clash 또는 Mihomo를 컴퓨터에서 실행하면 하나 이상의 로컬 프록시 수신 포트가 생성됩니다. 일반적으로 이 포트는 해당 컴퓨터의 애플리케이션만 사용하지만, LAN 접근을 활성화하면 같은 네트워크의 휴대폰, 태블릿, TV 박스 또는 다른 컴퓨터도 이 수신 포트로 요청을 보낼 수 있습니다. 이후 Clash가 실행 중인 호스트가 규칙을 매칭하고 노드로 트래픽을 전달합니다.

전체 경로는 다음과 같습니다. 클라이언트 기기가 요청을 보내면 가정용 라우터나 LAN 스위치가 데이터를 Clash 호스트로 전달하고, Clash가 현재 모드와 규칙에 따라 프록시 노드를 사용할지 직접 연결할지 결정합니다. 응답은 같은 경로를 따라 돌아옵니다. 원격 기기는 Clash 설정 파일을 읽거나 구독에 포함된 노드에 직접 연결할 필요가 없으며, 호스트의 LAN IP, 수신 포트와 프록시 프로토콜만 알면 됩니다.

이 방식은 컴퓨터를 완전한 라우터로 바꾸는 것과는 다릅니다. HTTP 프록시를 수동으로 입력하면 시스템 프록시 설정을 따르는 애플리케이션만 Clash를 거칩니다. 시스템 프록시를 무시하거나 직접 연결을 만들거나 자체 VPN 인터페이스를 사용하는 앱은 계속 직접 연결할 수 있습니다. 기기의 모든 트래픽을 처리하려면 Wi-Fi 프록시 항목에만 의존하지 말고 별도 라우터, 투명 프록시 또는 기기 자체에 TUN을 지원하는 클라이언트를 배포해야 합니다.

mixed-port는 HTTP와 SOCKS5를 동시에 수신합니다

mixed-port는 혼합 프록시 포트입니다. HTTP 프록시 연결과 SOCKS5 프록시 연결을 하나의 포트로 받을 수 있어 port와 socks-port를 따로 관리할 필요가 줄어듭니다. 흔히 7890을 사용하지만 이는 관례적인 설정값일 뿐 필수는 아닙니다. 다른 프로그램이 사용하지 않는 포트라면 다른 번호로 바꿀 수 있습니다.

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

이 설정은 7890 포트에서 HTTP와 SOCKS5 요청을 받고, LAN 기기의 연결을 허용하며, 규칙 모드로 트래픽을 처리한다는 뜻입니다. YAML은 들여쓰기와 문자 형식에 민감하므로 콜론 뒤의 공백을 유지해야 합니다. 별표는 YAML 별칭 문법으로 해석되지 않도록 따옴표 안에 넣는 것이 좋습니다.

설정에 port, socks-port, mixed-port를 함께 유지한다면 클라이언트 화면에서 최종적으로 커널에 기록하는 값을 먼저 확인하세요. 여러 포트를 동시에 사용할 수 있지만 휴대폰에 입력한 포트는 실제로 수신 중인 포트와 일치해야 합니다. 그래픽 클라이언트의 ‘혼합 포트’와 ‘LAN 연결 허용’ 옵션은 보통 이 필드에 매핑되며, 변경 후 설정 적용이나 커널 재시작이 필요할 수 있습니다.

HTTP와 SOCKS5 중 무엇을 선택해야 할까요?

휴대폰 Wi-Fi 설정의 ‘프록시’는 보통 HTTP 프록시를 의미하므로 Clash 호스트의 LAN IP와 mixed-port 값을 입력하면 됩니다. 브라우저가 HTTPS 사이트에 접속할 때는 HTTP CONNECT로 터널을 만들므로 이 포트를 계속 사용할 수 있습니다. SOCKS5를 지원하는 앱은 같은 주소와 포트를 SOCKS5 서버로 사용할 수 있습니다.

HTTP 프록시는 시스템 네트워크 설정으로 배포하기 쉽지만 모든 앱이 이를 따르는 것은 아닙니다. SOCKS5는 더 다양한 애플리케이션 계층 연결을 전달하고 프록시 측에서 도메인을 해석할 수 있지만, 시스템 설정 화면에는 SOCKS5 항목이 없는 경우가 많아 앱 자체에서 프록시를 설정해야 합니다. 공유 경로만 확인하려는 경우에는 HTTP 프록시부터 테스트하는 것이 가장 직관적입니다.

공유 요청도 규칙 시스템을 거칩니다

원격 기기가 혼합 포트에 연결해도 요청이 자동으로 전역 프록시로 전환되지는 않습니다. Clash는 현재의 규칙 모드, 전역 모드 또는 직접 연결 모드에 따라 트래픽을 처리합니다. 규칙 모드에서는 도메인, 대상 IP, 프로세스를 확인할 수 없는 네트워크 특성, 설정된 규칙 순서가 최종 정책에 영향을 줍니다. 테스트 사이트가 DIRECT에 매칭되면 공유 설정이 올바르더라도 출구 주소가 바뀌지 않을 수 있습니다.

점검할 때는 페이지가 열리는지만으로 프록시 작동 여부를 판단하지 말고 연결 목록이나 로그에서 규칙 매칭 결과를 잠시 확인하세요. 확인이 끝나면 평소 사용하는 모드로 되돌려 전역 모드가 규칙 설정 문제를 가리지 않도록 해야 합니다.

LAN 접근 허용과 바인딩 주소

allow-lan: true는 다른 기기가 프록시 포트에 접근할 수 있는지 제어합니다. 혼합 포트만 설정하고 LAN 접근을 허용하지 않으면 커널이 로컬 연결만 받을 수 있어 휴대폰에서는 연결 시간이 초과되거나 즉시 거부됩니다. 그래픽 클라이언트에서는 보통 ‘LAN 허용’, ‘LAN 연결’ 또는 ‘Allow LAN’이라는 이름으로 표시됩니다.

bind-address는 어떤 로컬 주소에서 수신할지 결정합니다. "*"는 커널 구현에 따라 사용 가능한 주소에서 수신하도록 하며, 호스트 주소가 바뀔 수 있는 가정용 네트워크에 적합합니다. IPv4만 공유하려면 0.0.0.0을 사용해 모든 IPv4 인터페이스에서 수신할 수도 있습니다. 수신 범위를 줄이려면 192.168.1.20처럼 호스트의 현재 LAN IPv4 주소를 입력할 수 있지만 DHCP로 주소가 다시 할당되면 설정도 함께 수정해야 합니다.

클라이언트 기기에는 127.0.0.1, localhost, 0.0.0.0을 입력하면 안 됩니다. 휴대폰에서 127.0.0.1은 휴대폰 자체를 가리킵니다. 0.0.0.0은 수신용 와일드카드 주소이며 연결 대상이 아닙니다. 휴대폰의 프록시 서버 항목에는 Clash가 실행 중인 컴퓨터의 현재 LAN 주소를 입력해야 합니다.

호스트의 LAN IP 찾기

• Windows에서는 ipconfig를 실행한 뒤 현재 Wi-Fi 또는 이더넷 어댑터의 IPv4 주소를 확인합니다.
• macOS에서는 네트워크 설정에서 연결된 인터페이스의 IP를 확인하거나 ipconfig getifaddr en0을 사용할 수 있습니다. 인터페이스가 en0이 아니라면 실제 인터페이스에 맞게 바꿔야 합니다.
• Linux에서는 ip addr를 실행하고 현재 연결된 인터페이스에서 LAN 주소를 찾습니다.

가정용 네트워크 주소는 대개 192.168., 10., 172.16.~172.31.로 시작합니다. 호스트에는 유선·무선 네트워크 카드, 가상 머신 네트워크 카드, VPN 가상 인터페이스가 동시에 존재할 수 있으므로 휴대폰과 같은 LAN에 연결된 물리 인터페이스의 주소를 선택해야 합니다. 두 기기의 게이트웨이와 네트워크 대역을 비교하는 것이 가장 간단한 확인 방법입니다.

방화벽 허용과 Wi-Fi 클라이언트 격리

커널이 LAN 주소에서 수신 중이라고 해서 데이터가 반드시 포트에 도달하는 것은 아닙니다. Windows Defender 방화벽, macOS 방화벽, Linux의 nftables, iptables 또는 firewalld가 인바운드 연결을 차단할 수 있습니다. 허용 규칙은 실제 사용하는 TCP 포트를 대상으로 설정하고, 가능하면 출발지를 가정 또는 사무실 LAN 대역으로 제한해야 합니다.

Windows에서 관련 클라이언트를 처음 실행하면 어떤 네트워크에서 통신을 허용할지 시스템이 물을 수 있습니다. 일반적으로 ‘개인 네트워크’만 허용하면 됩니다. 현재 Wi-Fi가 공용 네트워크로 인식되면 앱에 개인 네트워크 권한이 있어도 연결이 차단될 수 있습니다. 먼저 네트워크 프로필 유형을 확인한 뒤 앱 규칙이나 포트 규칙이 현재 커널 프로세스에 적용되는지 점검하세요.

Linux 호스트에서는 먼저 수신 상태를 확인한 다음 방화벽을 처리하세요. 예를 들어 다음 명령으로 7890 포트를 확인할 수 있습니다.

ss -lnt | grep 7890

결과에 127.0.0.1:7890만 표시되면 문제는 여전히 Clash의 수신 설정에 있습니다. 0.0.0.0:7890, 호스트의 LAN 주소 또는 해당 IPv6 수신 주소가 표시되면 방화벽과 라우터 격리 설정을 계속 확인하세요. 테스트를 위해 모든 방화벽을 바로 끄지 말고, 범위가 명확한 임시 인바운드 규칙을 만들면 원인을 파악하기 쉽고 테스트 후 되돌리기도 편합니다.

같은 Wi-Fi에서도 서로 연결되지 않을 수 있습니다

일부 라우터는 게스트 네트워크에 AP 격리, 클라이언트 격리 또는 무선 단말 격리를 활성화합니다. 이 경우 휴대폰과 컴퓨터가 같은 라우터에 연결된 것으로 보여도 LAN 연결을 직접 맺을 수 없습니다. 기업, 호텔, 공용 핫스팟에서도 비슷한 정책을 사용하는 경우가 많습니다. 다른 컴퓨터에서 프록시 포트에 접속해 보거나 휴대폰이 호스트의 다른 LAN 서비스에 연결되는지 확인해 보세요.

듀얼 밴드 Wi-Fi 자체가 통신을 차단하는 경우는 드물지만, 일부 라우터는 게스트 SSID, IoT SSID와 기본 네트워크를 서로 다른 대역으로 분리합니다. 기기 주소가 같은 네트워크 대역에 있지 않다면 라우터가 대역 간 접근을 허용하는지 확인하세요. allow-lan만 활성화해서는 라우터의 접근 제어를 우회할 수 없습니다.

휴대폰, 태블릿 및 다른 컴퓨터 설정 방법

iPhone 및 iPad

1. Clash 호스트와 같은 Wi-Fi에 연결하고 단말 간 통신이 허용되는지 확인합니다.
2. 현재 Wi-Fi의 세부 설정을 열고 HTTP 프록시로 이동한 다음 설정 방식을 수동으로 변경합니다.
3. 서버에는 Clash 호스트의 LAN IP를 입력하고, 포트에는 mixed-port 값을 입력합니다.
4. 커널에 프록시 인증을 설정했다면 해당 사용자 이름과 비밀번호를 입력하고, 설정하지 않았다면 인증을 끕니다.
5. 저장한 뒤 브라우저에서 프록시 규칙에 매칭될 것으로 예상되는 사이트를 열고 Clash 연결 목록도 함께 확인합니다.

iOS와 iPadOS의 수동 HTTP 프록시는 Wi-Fi 네트워크별로 저장됩니다. 모바일 데이터나 다른 Wi-Fi로 전환하거나 현재 네트워크를 끄면 설정이 자동으로 이전되지 않습니다. 일부 앱은 시스템 HTTP 프록시를 무시할 수 있으므로 브라우저 테스트 성공이 모든 앱이 같은 경로를 사용한다는 뜻은 아닙니다.

Android 기기

1. 현재 Wi-Fi의 네트워크 수정 또는 고급 설정 화면으로 이동합니다.
2. 프록시 방식을 수동으로 변경하고 프록시 호스트 이름에 컴퓨터의 LAN IP를 입력합니다.
3. 프록시 포트에는 혼합 포트를 입력합니다. 예: 7890.
4. 저장한 뒤 Wi-Fi에 다시 연결하고 브라우저와 Clash 로그로 요청을 확인합니다.

Android 제조사마다 설정 화면의 명칭이 다르며, 일부 시스템에서는 Wi-Fi 이름을 길게 눌러야 프록시 옵션이 표시됩니다. 시스템 수준의 Wi-Fi HTTP 프록시는 일반적으로 모든 앱을 대상으로 하지 않으며 VPN이나 TUN과도 다릅니다. SOCKS5가 필요한 앱은 앱 내부에 같은 호스트 주소와 혼합 포트를 입력하고 SOCKS5 프로토콜을 선택해야 합니다.

다른 컴퓨터

Windows, macOS, Linux에서는 시스템 네트워크 프록시에 HTTP 프록시를 입력하거나 브라우저, 터미널, 개발 도구에만 설정할 수 있습니다. curl로 HTTP 프록시를 확인하려면 다음 명령을 실행합니다.

curl -x http://192.168.1.20:7890 https://example.com

SOCKS5를 확인하고 프록시 측에서 도메인을 해석하게 하려면 다음 명령을 사용할 수 있습니다.

curl --socks5-hostname 192.168.1.20:7890 https://example.com

예시의 IP는 실제 호스트 주소로 바꿔야 합니다. 첫 번째 명령은 성공하지만 시스템 앱이 실패한다면 앱이 시스템 프록시를 읽는지, 프록시 우회 목록이 설정되어 있는지, 앱이 별도의 네트워크 터널을 직접 만드는지 집중적으로 확인하세요.

접근 제어, 인증 및 노출 범위

모든 인터페이스에서 수신하도록 설정하면 연결 가능한 네트워크의 다른 기기가 프록시 포트에 접속을 시도할 수 있습니다. 신뢰할 수 있는 가정용 네트워크에서는 방화벽으로 출발지 대역을 제한할 수 있습니다. 구성원이 많은 사무실이나 기숙사 네트워크, 공용 핫스팟에서는 수신 주소를 더 제한하거나 커널이 지원하는 프록시 인증 기능을 사용해야 합니다.

Mihomo 등의 구현에서는 설정을 통해 HTTP 및 SOCKS 진입점에 사용자 이름과 비밀번호를 지정할 수 있습니다. 일반적인 설정 형식은 다음과 같습니다.

authentication:
  - "lanuser:replace-with-a-strong-password"

인증 필드 지원 여부는 커널과 클라이언트 버전에 따라 다르므로 수정하기 전에 현재 클라이언트가 실제로 사용하는 커널을 확인해야 합니다. 사용자 이름과 비밀번호는 프록시에 접근하는 기기에 전달되므로 LAN 접근 제어의 일부로 사용할 수 있지만, 방화벽의 출발지 제한과 함께 적용해야 합니다. 프록시 포트를 라우터의 공인 주소로 포트 매핑하지 말고, 클라우드 호스트 보안 그룹에서 인터넷에 개방하지도 마세요.

집에서 가끔 공유하는 경우 사용이 끝난 뒤 ‘LAN 허용’을 끄거나 임시 방화벽 규칙을 철회할 수 있습니다. 장기 공유 시에는 호스트 IP를 고정하고 포트 용도를 기록하며, 개발 서버·데이터베이스·기타 로컬 서비스와 같은 포트를 사용하지 않도록 하세요.

공유 실패 시 점검 순서

점검은 수신 측에서 클라이언트 방향으로 계층별 진행해야 합니다. 한 번에 하나의 변수만 변경하고 각 단계의 현상을 기록하세요. 노드를 계속 바꾸거나 클라이언트를 재설치하는 것만으로는 LAN 연결 문제를 찾기 어렵습니다.

1단계: 커널 실행 및 포트 점유 확인

먼저 호스트 자체에서 127.0.0.1과 혼합 포트를 사용해 프록시를 테스트합니다. 로컬에서도 연결되지 않으면 커널 실행 여부, 설정 로드 성공 여부, 다른 프로그램의 포트 점유 여부, 로그의 YAML 파싱 또는 수신 실패 메시지를 확인하세요. 포트 충돌이 발생하면 사용하지 않는 새 포트를 선택하고 원격 기기의 설정도 함께 수정해야 합니다.

2단계: 수신 범위 확인

allow-lan이 true인지 확인한 다음 포트가 실제로 어떤 주소에서 수신 중인지 확인하세요. 루프백 주소만 수신한다면 네트워크 카드에서 요청이 들어올 수 없습니다. 그래픽 클라이언트의 옵션을 변경한 뒤에는 활성 설정에 기록되었는지, 단순히 사용하지 않는 설정 파일만 수정된 것은 아닌지 확인해야 합니다.

3단계: IP, 포트 및 네트워크 확인

휴대폰에 입력한 주소가 게이트웨이 주소, 가상 네트워크 카드 주소 또는 이전 연결의 오래된 주소가 아닌 현재 호스트의 LAN IP인지 확인하세요. 두 기기가 서로 통신할 수 있는 네트워크에 연결되어 있는지 확인하고, 네트워크 경로를 바꿀 수 있는 모바일 데이터 지원 기능을 끈 뒤 다시 테스트합니다. 라우터에서 게스트 격리가 활성화되어 있다면 기본 네트워크로 전환하거나 격리 정책을 조정하세요.

4단계: 방화벽 확인

포트는 수신 중이지만 원격 연결이 시간 초과된다면 인바운드 방화벽이 원인인 경우가 많습니다. 로컬 네트워크 대역에서 대상 TCP 포트로만 접근하도록 규칙을 만든 뒤 다른 컴퓨터에서 포트 연결을 테스트하세요. Windows에서는 원격 PowerShell에서 다음을 실행할 수 있습니다.

Test-NetConnection 192.168.1.20 -Port 7890

TcpTestSucceeded가 true이면 TCP 포트에 도달할 수 있다는 뜻일 뿐, 프록시 규칙과 노드가 작동한다는 의미는 아닙니다. false이면 주소, 수신 설정, 방화벽과 네트워크 격리를 계속 확인해야 합니다.

5단계: 연결 및 규칙 매칭 확인

포트에는 도달하지만 웹 페이지가 열리지 않는다면 Clash의 실행 로그나 연결 목록을 엽니다. 새 연결이 전혀 보이지 않으면 클라이언트 앱이 시스템 프록시를 사용하지 않거나 프록시 설정이 저장되지 않았을 수 있습니다. 연결은 보이지만 실패한다면 도메인 해석, 노드 상태, 정책 그룹 선택과 규칙 매칭 결과를 계속 확인하세요.

규칙 모드에서는 테스트 대상이 직접 연결에 매칭될 수 있습니다. 전역 모드에서는 현재 전역 정책이 사용할 수 없는 노드를 가리킬 수 있고, 직접 연결 모드에서는 모든 요청이 프록시 노드를 우회합니다. 모드와 정책 그룹은 전달 계층의 문제이므로 LAN 포트에 도달할 수 있는지와 분리해서 판단해야 합니다.

6단계: HTTP, DNS 및 UDP 제한 구분

휴대폰 Wi-Fi의 HTTP 프록시는 주로 HTTP 프록시 방식의 TCP 요청을 처리합니다. 앱이 직접 보내는 DNS, QUIC, 게임 UDP 또는 시스템 프록시를 읽지 않는 트래픽은 해당 포트로 들어오지 않을 수 있습니다. ‘브라우저는 되지만 특정 앱은 안 되는’ 경우 공유가 실패했다고 바로 판단하지 말고 해당 앱이 어떤 프록시 방식을 지원하는지 먼저 확인하세요.

SOCKS5 클라이언트에 ‘도메인 원격 해석’ 옵션이 있다면 활성화하여 프록시 측에서 대상 도메인을 처리하도록 할 수 있습니다. HTTP CONNECT 요청도 도메인을 프록시 측에 전달할 수 있지만 구체적인 동작은 클라이언트 구현에 따라 다릅니다. UDP를 사용하는 앱은 클라이언트, 진입 프로토콜, 노드와 방화벽이 모두 지원해야 하므로 일반 웹 페이지 테스트 결과로 대신할 수 없습니다.

설정 완료 후 검증 목록

1. 호스트에서 mixed-port를 통해 정상적으로 네트워크에 접속할 수 있습니다.
2. allow-lan이 활성화되어 있고 포트가 127.0.0.1에서만 수신하지 않습니다.
3. 휴대폰에 호스트의 현재 LAN IP와 올바른 포트를 입력했습니다.
4. 방화벽은 필요한 로컬 네트워크 대역에 대해서만 인바운드 연결을 허용합니다.
5. 라우터에서 두 기기의 클라이언트 격리가 활성화되어 있지 않습니다.
6. Clash 연결 목록에서 LAN 기기에서 들어온 새 요청을 확인할 수 있습니다.
7. 테스트 대상이 예상한 규칙과 정책 그룹에 매칭되며 의도치 않게 직접 연결되지 않습니다.
8. 사용이 끝나면 필요에 따라 LAN 접근을 끄거나 제한된 규칙을 유지합니다.

혼합 포트 공유의 핵심은 단일 스위치가 아니라 진입, 네트워크, 전달의 세 계층이 동시에 충족되는지에 있습니다. Clash가 올바르게 수신하고, LAN에서 접근할 수 있으며, 규칙과 노드가 후속 연결을 완료해야 합니다. 이 순서대로 확인하면 ‘휴대폰이 프록시에 연결되지 않음’ 문제를 포트·노드·시스템 설정 사이의 반복적인 시행착오가 아니라 명확한 설정 항목으로 나누어 해결할 수 있습니다.