Clash 혼합 포트와 로컬 네트워크 프록시 공유: 수신 주소, 방화벽 및 기기 연결

먼저 결론: 프록시 공유는 네 가지 조건을 모두 충족해야 합니다

한 컴퓨터에서 Clash를 실행한 뒤 같은 로컬 네트워크의 스마트폰, 태블릿 또는 다른 컴퓨터가 이를 통해 프록시에 연결하려면 단순히 ‘로컬 네트워크 연결 허용’만 켜서는 안 됩니다. 전체 연결 경로에는 네 가지 조건이 필요합니다. Clash 코어가 다른 기기에서 접근할 수 있는 네트워크 인터페이스 주소를 수신해야 하고, 로컬 네트워크 접근 허용이 활성화되어야 하며, 호스트 방화벽이 해당 포트의 인바운드 연결을 허용해야 합니다. 또한 연결하는 기기에는 호스트의 올바른 로컬 네트워크 주소와 포트를 입력해야 합니다. 어느 한 단계라도 충족되지 않으면 클라이언트에는 시간 초과, 연결 거부 또는 일부 앱만 작동하는 현상이 나타납니다.

관리하기 쉽고 흔히 사용하는 방법은 mixed-port 하나를 활성화해 HTTP 프록시와 SOCKS5 프록시가 같은 포트를 공유하도록 하는 것입니다. 스마트폰 시스템의 Wi-Fi 수동 프록시에는 보통 HTTP 프록시를 입력합니다. SOCKS5를 지원하는 데스크톱 프로그램이나 네트워크 도구는 같은 포트에 연결한 뒤 SOCKS5 프로토콜로 핸드셰이크를 수행할 수 있습니다. 혼합 포트는 진입점만 통합할 뿐 일반 HTTP 요청과 SOCKS5 요청을 혼동하지 않습니다. 코어가 연결 프로토콜을 식별해 트래픽을 처리합니다.

기본 설정은 다음과 같이 작성할 수 있습니다. 그래픽 클라이언트에 따라 화면의 토글로 이 필드가 생성되기도 하고, 구독 업데이트 후 설정이 다시 덮어써지기도 합니다. 따라서 수정한 뒤에는 구독 원본만 확인하지 말고 실제 실행 중인 설정을 다시 열어 결과를 확인해야 합니다.

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

mixed-port는 프록시 진입 포트를 지정하고, allow-lan은 로컬 호스트 외부에서 들어오는 로컬 네트워크 연결을 허용하며, bind-address는 어떤 로컬 주소에서 수신할지 결정합니다. 별표를 사용하면 사용 가능한 인터페이스에서 수신하므로 설정은 간단하지만 범위가 넓어집니다. 더 엄격하게 구성하려면 Clash가 실행되는 로컬 네트워크 인터페이스의 주소(예: 192.168.1.20)에 바인딩할 수 있습니다. 단, 해당 주소가 안정적으로 유지되어야 합니다.

혼합 포트가 해결하는 문제

기존 Clash 설정에서는 port와 socks-port를 따로 선언할 수 있습니다. 전자는 HTTP 프록시 진입점이고 후자는 SOCKS5 프록시 진입점입니다. 두 프로토콜을 별도로 제어하기에는 편리하지만 연결 기기가 많아지면 두 포트를 기억해야 하고 시스템 프록시 설정에 잘못 입력하기도 쉽습니다. mixed-port는 두 진입점을 하나의 TCP 포트로 통합하므로 가정용 로컬 네트워크, 테스트 기기와 임시 공유에 적합합니다.

혼합 포트가 로컬 네트워크 기기의 모든 트래픽을 자동으로 가로채는 것은 아닙니다. 연결하는 기기에서 HTTP 또는 SOCKS5 프록시를 직접 설정하거나, 해당 기기의 앱이 프록시에 능동적으로 연결해야 합니다. 스마트폰 Wi-Fi 설정의 ‘수동 프록시’는 일반적으로 시스템 HTTP 프록시 설정을 따르는 앱에만 적용됩니다. 일부 앱은 독립적인 네트워크 스택을 사용하거나 대상 주소에 직접 연결하거나 시스템 프록시를 무시하므로 Clash를 거치지 않을 수 있습니다. ‘브라우저는 되는데 특정 앱은 안 되는’ 경우에는 노드나 규칙을 바로 바꾸기보다 먼저 해당 앱이 시스템 프록시를 지원하는지 확인하세요.

SOCKS5의 UDP 포워딩 기능은 연결하는 앱, 코어 버전과 구체적인 프로토콜 구현의 영향을 받습니다. TCP 요청이 혼합 포트를 통해 성공했다고 해서 모든 UDP 트래픽도 같은 방식으로 처리된다고 볼 수는 없습니다. 게임, 실시간 통신과 QUIC에 의존하는 앱은 별도로 검증해야 합니다. 한 기기의 대부분의 네트워크 트래픽을 가로채려는 목적이라면 원격 혼합 포트를 완전한 가상 네트워크 인터페이스처럼 사용하지 말고, 해당 기기에서 호환되는 TUN 모드를 사용하세요.

혼합 포트와 규칙 모드의 관계

포트는 연결을 수신하는 역할만 하며, 최종적으로 직접 연결할지, 프록시 노드를 사용할지, 연결을 거부할지는 Clash의 실행 모드, 규칙 집합과 정책 그룹이 결정합니다. rule 모드에서는 로컬 네트워크 기기에서 들어온 도메인이나 대상 주소가 동일한 규칙 매칭 과정을 거칩니다. 전역 모드에서는 트래픽이 일반적으로 전역 정책 그룹으로 전달되고, 직접 연결 모드에서는 기기가 혼합 포트에 성공적으로 연결했더라도 요청이 대상에 직접 접속할 수 있습니다.

따라서 공유 프록시를 테스트할 때는 현재 모드와 정책 그룹 선택을 함께 기록해야 합니다. 스마트폰에서 웹페이지가 열리지만 외부 IP 주소가 바뀌지 않는다면 규칙이 DIRECT에 매칭되었는지, 대상 도메인이 로컬 DNS에서 예상과 다른 주소로 해석되었는지 확인하세요. 포트 연결 성공은 연결 경로가 성립했다는 뜻일 뿐, 특정 프록시 규칙이 적용되었다는 의미는 아닙니다.

allow-lan과 수신 주소를 함께 확인해야 합니다

allow-lan: true는 다른 호스트가 프록시 리스너에 접근할 수 있도록 허용한다는 뜻이지만, 실제로 어느 네트워크 인터페이스에서 연결을 받을지는 수신 주소에 따라 달라집니다. 프로세스가 127.0.0.1에서만 수신한다면 해당 포트는 로컬 루프백 인터페이스에만 열려 있으므로 다른 기기는 컴퓨터에 ping을 보낼 수 있어도 프록시에 연결할 수 없습니다. 0.0.0.0에서 수신하거나 설정의 별표로 모든 인터페이스를 덮어쓰면 여러 IPv4 인터페이스에 포트가 열립니다. 특정 로컬 네트워크 IP에 바인딩하면 해당 인터페이스를 통해서만 서비스가 제공됩니다.

더 안정적인 설정은 먼저 공유 범위를 정하는 것입니다. 가정용 네트워크 인터페이스가 하나뿐이고 네트워크 환경을 통제할 수 있다면 모든 인터페이스에서 수신한 뒤 방화벽으로 출발지 서브넷을 제한할 수 있습니다. 컴퓨터가 회사 VPN, 가상 머신 인터페이스, 컨테이너 네트워크와 핫스팟에 동시에 연결되어 있다면 실제 로컬 네트워크 주소에 바인딩하는 것이 좋습니다. 필요하지 않은 인터페이스에 프록시 진입점이 노출되는 것을 막을 수 있습니다. 특정 주소에 바인딩한 뒤 DHCP가 IP를 다시 할당하면 Clash가 기존 주소에서 계속 수신하지 못할 수 있으므로 라우터에서 DHCP 주소 예약을 설정하거나 주소 변경 후 설정도 함께 수정해야 합니다.

다른 기기에 입력할 주소 찾기

• Windows에서는 네트워크 설정에서 현재 Wi-Fi 또는 이더넷의 IPv4 주소를 확인할 수 있습니다. 또는 ipconfig를 실행해 현재 사용 중이며 기본 게이트웨이가 표시된 네트워크 인터페이스를 찾으세요.
• macOS에서는 시스템 네트워크 설정에서 현재 연결의 세부 정보를 확인할 수 있습니다. 또는 ifconfig로 활성 인터페이스의 주소를 점검하세요.
• Linux에서는 ip address를 실행하고, ip route에 표시되는 기본 경로를 함께 확인해 실제 외부 연결에 사용되는 인터페이스를 판단할 수 있습니다.

스마트폰에 127.0.0.1을 입력하지 마세요. 루프백 주소는 항상 현재 기기 자체를 가리킵니다. 스마트폰에서 127.0.0.1:7890에 접속하면 Clash가 실행 중인 컴퓨터가 아니라 스마트폰 자체의 서비스를 찾게 됩니다. 연결 기기가 실제로 해당 네트워크에 있는 경우가 아니라면 가상 머신, Docker, VPN 또는 임시 핫스팟 인터페이스의 주소도 우선 사용하지 마세요.

코어가 실제로 수신 중인지 확인하기

그래픽 인터페이스에 ‘로컬 네트워크 허용’이 표시된다고 해서 시스템 수준의 수신 상태 확인을 대신할 수는 없습니다. Windows에서는 PowerShell로 포트를 조회할 수 있고, macOS와 Linux에서는 수신 소켓을 확인할 수 있습니다. 출력에 루프백 주소만 있다면 원격 기기는 여전히 연결할 수 없습니다. 로컬 네트워크 주소나 와일드카드 주소가 보이면 다음으로 방화벽을 확인하세요.

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

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

# Linux
ss -lntp | grep 7890

다른 프로그램이 포트를 사용 중이면 Clash가 실행에 실패하거나 클라이언트 기본 포트로 자동 변경하거나 로그에 수신 오류를 기록할 수 있습니다. 문제를 확인할 때는 현재 코어 로그와 시스템 소켓 조회 결과를 기준으로 판단해야 합니다. 포트를 변경했다면 모든 연결 기기도 함께 수정해야 하며, 기존 Wi-Fi 프록시 설정이 새 포트를 자동으로 찾지는 않습니다.

필요한 네트워크와 포트만 방화벽에서 허용하기

Clash가 이미 로컬 네트워크 인터페이스에서 수신 중인데 다른 기기에서 연결 시간이 초과된다면 호스트 방화벽을 다음으로 확인해야 합니다. 방화벽 규칙은 혼합 포트의 TCP 인바운드 연결을 허용하되 현재 가정 또는 사무실 서브넷으로 범위를 제한하는 것이 좋습니다. 예를 들어 컴퓨터 주소가 192.168.1.20이고 서브넷 마스크가 255.255.255.0이라면 흔한 출발지 범위는 192.168.1.0/24입니다. 실제 네트워크 대역은 라우터와 시스템 네트워크 정보에 따라 정해야 하며 예시를 그대로 적용해서는 안 됩니다.

Windows에서는 먼저 현재 연결이 개인 네트워크로 인식되는지 공용 네트워크로 인식되는지 확인해야 합니다. 인바운드 규칙은 Clash 클라이언트 프로그램에 연결할 수도 있고 특정 TCP 포트에 연결할 수도 있습니다. 포트 규칙은 검증하기 쉽지만 포트가 바뀔 때마다 관리해야 합니다. 규칙의 범위는 모든 원격 주소가 아니라 로컬 서브넷 또는 명시적인 주소로 제한해야 합니다. macOS는 처음 인바운드 연결을 받을 때 시스템 알림을 표시할 수 있으므로 현재 사용하는 클라이언트 프로세스에 대한 허용인지 확인하세요. Linux에서는 실제로 사용하는 nftables, firewalld, ufw 또는 배포판 방화벽 설정에 맞춰 인바운드 정책을 구성해야 합니다.

방화벽에서 허용한 뒤 다른 기기에서 TCP 연결을 테스트할 수 있습니다. TCP 연결은 성립하지만 프록시 요청이 실패한다면 문제는 대개 네트워크 계층에서 프록시 프로토콜, 인증, 규칙 또는 상위 노드 문제로 넘어간 것입니다. 완전히 시간 초과되는 경우에는 방화벽이 패킷을 버리거나 클라이언트 격리가 적용되었거나 주소를 잘못 입력했을 가능성이 큽니다. 즉시 ‘연결이 거부됨’이 반환되면 대상 주소에는 도달했지만 해당 포트에서 프로세스가 수신 중이지 않을 가능성이 높습니다.

라우터의 클라이언트 격리도 연결을 차단할 수 있습니다

게스트 Wi-Fi, 무선 클라이언트 격리와 일부 기업용 무선 네트워크는 같은 액세스 포인트에 연결된 기기 간 통신을 차단합니다. 이 경우 스마트폰은 인터넷에 접속할 수 있고 컴퓨터와 비슷한 네트워크 대역도 확인되지만 컴퓨터의 포트에는 연결할 수 없습니다. 두 기기가 동일한 주 네트워크에 연결되어 있는지, 한 기기가 게스트 네트워크에 있는지, 라우터에서 AP 격리가 활성화되어 있는지 확인하세요. 이중 라우터 환경에서는 두 개의 서브넷이 만들어지고 상위 네트워크에서 하위 네트워크로만 단방향 라우팅되어 기기 간 직접 연결이 불가능할 수도 있습니다.

스마트폰과 컴퓨터를 혼합 포트에 연결하는 방법

연결하기 전에 Clash가 실행 중인 컴퓨터의 로컬 네트워크 IPv4 주소, 혼합 포트와 현재 네트워크 이름을 기록하세요. 컴퓨터 주소가 192.168.1.20이고 혼합 포트가 7890이라고 가정하면 다른 기기는 같은 라우터에 연결한 뒤 프록시 서버에 192.168.1.20, 포트에 7890을 입력해야 합니다. 예시 주소를 그대로 사용하지 말고 실제로 Clash가 실행 중인 호스트에서 주소를 확인하세요.

Android 및 iOS의 Wi-Fi 수동 프록시

1. 현재 Wi-Fi 네트워크의 상세 설정을 열고 자동 구성 스크립트가 아닌 수동 프록시를 선택하세요.
2. 서버 또는 호스트 이름에는 Clash 호스트의 로컬 네트워크 주소를 입력하고, 포트에는 혼합 포트를 입력하세요.
3. 저장한 뒤 먼저 일반 HTTPS 웹사이트를 브라우저로 열고, Clash의 연결 목록과 로그에 해당 기기의 요청이 나타나는지 확인하세요.
4. 테스트가 끝나면 수동 프록시를 끄세요. 현재 네트워크를 벗어난 뒤에도 연결할 수 없는 내부 주소에 계속 접속을 시도하는 일을 막을 수 있습니다.

모바일 시스템의 Wi-Fi 수동 프록시는 주로 HTTP 및 HTTPS 연결을 대상으로 합니다. HTTPS 요청은 일반적으로 HTTP CONNECT 터널을 통해 전달되므로 Clash가 웹페이지 내용을 복호화하지 않아도 대상 호스트와 규칙을 기준으로 연결을 처리할 수 있습니다. 일부 앱은 시스템 프록시 설정을 읽지 않고, 다른 앱은 UDP 또는 사용자 지정 전송 방식을 사용합니다. 따라서 단일 앱의 결과로 전체 시스템을 판단해서는 안 됩니다.

Windows, macOS 및 Linux 연결

다른 데스크톱 컴퓨터에서는 시스템 네트워크 설정에 HTTP 프록시를 입력하거나 브라우저, 터미널 도구 또는 특정 앱에서만 프록시를 설정할 수 있습니다. SOCKS5를 지원하는 앱은 프로토콜을 SOCKS5로 선택하고 같은 호스트 주소와 혼합 포트를 사용하면 됩니다. 명령줄 도구가 시스템 프록시를 읽는지는 도구 구현에 따라 다르므로, 필요하면 현재 터미널 세션에서 프록시 환경 변수를 설정하세요.

HTTP_PROXY=http://192.168.1.20:7890
HTTPS_PROXY=http://192.168.1.20:7890
ALL_PROXY=socks5://192.168.1.20:7890

이 변수는 형식 예시일 뿐입니다. 도구마다 대문자와 소문자 변수, socks5와 socks5h를 처리하는 방식이 다릅니다. 이 중 socks5h는 일반적으로 도메인 이름 해석도 프록시 측에 맡긴다는 뜻입니다. 사용하기 전에 해당 도구의 문서를 확인하고, 서로 충돌하는 시스템 프록시와 앱 프록시를 동시에 설정하지 마세요.

DNS는 어떻게 처리되는가

로컬 네트워크 기기가 혼합 포트에 연결할 때 DNS 경로는 프록시 프로토콜과 앱의 동작에 따라 달라집니다. HTTP 프록시 요청은 일반적으로 대상 호스트 이름을 프록시 서버에 전달해 처리하게 합니다. SOCKS5 클라이언트는 도메인 이름을 보낼 수도 있고, 먼저 로컬에서 IP로 해석한 뒤 연결을 요청할 수도 있습니다. 프록시를 거치지 않는 스마트폰 앱은 계속 시스템 DNS를 사용합니다. Clash 설정의 DNS 모듈은 혼합 포트를 열었다고 해서 자동으로 전체 네트워크의 DNS 서버가 되지 않으며, Clash의 DNS 수신 포트와 혼합 프록시 포트를 혼동해서도 안 됩니다.

규칙이 도메인에 의존하는데 클라이언트가 도메인을 미리 IP로 해석하면 코어가 규칙 매칭에 사용할 수 있는 정보가 달라질 수 있습니다. mihomo는 스니핑, DNS와 규칙 기능을 조합해 일부 환경을 개선할 수 있지만, 활성화 여부는 설정 출처와 개인정보 보호 범위를 고려해 결정해야 합니다. 기본적인 공유 환경에서는 먼저 HTTP 프록시를 안정적으로 작동시킨 다음 특정 앱의 도메인 식별 문제를 처리하세요.

네트워크 계층별로 연결 실패 점검하기

효율적인 문제 해결의 핵심은 노드를 반복해서 바꾸는 것이 아니라 계층별로 검증하는 것입니다. 먼저 컴퓨터 자체에서 혼합 포트를 통해 접속할 수 있는지 확인하고, 이어서 포트의 수신 주소, 로컬 네트워크 연결과 방화벽, 마지막으로 Clash 규칙과 상위 프록시를 점검하세요. 다음 순서로 대부분의 문제를 구분할 수 있습니다.

1. 코어 실행 상태를 확인합니다. 현재 설정이 정상적으로 로드되었고 혼합 포트에 충돌이 없으며 로그에 수신 실패나 YAML 구문 오류가 없는지 확인하세요.
2. 로컬 호스트 프록시를 확인합니다. Clash가 실행 중인 컴퓨터에서 127.0.0.1:7890에 연결하세요. 로컬에서도 실패한다면 로컬 네트워크 설정을 계속 조정하지 말고 먼저 코어, 설정과 노드를 처리해야 합니다.
3. 실제 수신 주소를 확인합니다. 포트가 루프백 인터페이스가 아니라 로컬 네트워크 IP 또는 와일드카드 주소에서 수신 중인지 확인하세요.
4. 두 기기의 네트워크를 확인합니다. IP, 서브넷 마스크, 기본 게이트웨이와 Wi-Fi 이름을 확인하고 게스트 네트워크, 클라이언트 격리와 이중 라우터 문제를 배제하세요.
5. 호스트 방화벽을 확인합니다. 현재 네트워크 범위에서 지정한 TCP 포트에 접근하도록 허용하고, 규칙이 올바른 네트워크 프로필에 적용되었는지 확인하세요.
6. 연결 기기의 입력 형식을 확인합니다. 서버 항목에는 IP 또는 호스트 이름만 입력하고 포트는 숫자로 따로 입력하세요. http://, 경로와 포트를 호스트 이름 필드에 모두 넣지 마세요.
7. 연결 목록을 확인합니다. 기기의 요청이 보인다면 로컬 네트워크 경로는 대체로 정상입니다. 이후 대상 도메인, 적용된 규칙, 정책 그룹과 오류 로그를 기준으로 다음 문제를 추적하세요.

설정이 구독 업데이트로 덮어써지면 어떻게 하나요

구독은 일반적으로 프록시 노드, 정책 그룹과 규칙을 제공하지만 로컬 네트워크 수신은 이 컴퓨터의 실행 매개변수입니다. 클라이언트마다 구독 설정을 병합하는 방식이 다릅니다. 어떤 클라이언트는 화면에서 설정한 포트와 로컬 네트워크 허용을 유지하고, 어떤 클라이언트는 구독 필드를 그대로 사용하며, 또 다른 클라이언트는 오버라이드, 설정 패치 또는 전역 설정으로 최종 설정을 생성합니다. mixed-port, allow-lan과 bind-address는 클라이언트가 제공하는 오버라이드 기능으로 관리하고, 업데이트할 때마다 임시 파일을 직접 수정하는 방식은 피하세요.

수정하기 전에 현재 정상 작동하는 설정을 복사하고 클라이언트에 표시된 실제 설정 경로를 기록하세요. 구독을 업데이트한 뒤 수신 상태와 연결 로그를 다시 확인하면 노드가 변경된 것인지 로컬 수신 매개변수가 초기화된 것인지 빠르게 판단할 수 있습니다. Clash Meta(mihomo) 코어를 사용한다면 클라이언트 버전과 코어 버전이 지원하는 설정 범위도 확인해야 합니다. 다른 클라이언트의 화면 명칭만 보고 동작이 완전히 같다고 추정해서는 안 됩니다.

TUN 모드는 로컬 네트워크 수신 설정을 대신할 수 없습니다

TUN 모드는 주로 Clash가 실행되는 컴퓨터의 트래픽을 가로채는 문제를 해결합니다. 가상 네트워크 인터페이스, 라우팅과 DNS를 함께 사용해 더 많은 앱 트래픽을 처리합니다. 호스트에서 TUN을 켠다고 해서 로컬 네트워크의 다른 기기가 자동으로 이 컴퓨터로 트래픽을 보내는 것은 아니며 게이트웨이 포워딩도 자동으로 구성되지 않습니다. 다른 기기에서 혼합 포트를 사용하려면 여전히 프록시를 설정해야 합니다. 컴퓨터를 로컬 네트워크 게이트웨이로 사용하려면 IP 포워딩, 라우팅, NAT와 DNS를 포함한 별도의 네트워크 설계가 필요하며 복잡도와 보안 범위도 크게 달라집니다.

가정 환경에서 스마트폰 브라우저나 테스트 기기에 일시적으로 프록시를 제공하는 목적이라면 혼합 포트와 수동 프록시만으로도 충분한 경우가 많습니다. 여러 기기를 장기간 연결해야 한다면 호스트 주소를 고정하고 방화벽의 출발지 범위를 제한하며 포트 변경 사항을 기록하고 현재 이 진입점을 사용하는 기기를 정기적으로 확인하세요. 이렇게 하면 문제를 수신, 네트워크, 프록시 프로토콜과 규칙이라는 명확한 네 계층으로 한정할 수 있습니다.