Clash를 한 대의 컴퓨터에서만 사용하는 환경과 집 안의 여러 기기에 공유하는 환경은 설정의 범위가 다릅니다. 데스크톱에서 시스템 프록시만 활성화하면 해당 컴퓨터의 브라우저와 애플리케이션만 Clash를 사용하지만, LAN 접근을 허용하고 공유기 또는 다른 기기의 프록시 주소를 지정하면 노트북·스마트폰·태블릿·TV까지 같은 프록시 출구를 사용할 수 있습니다. 이때 단순히 포트를 열기만 하면 되는 것은 아닙니다. 수신 주소, 방화벽, 클라이언트별 프록시 방식, 국내 사이트의 직접 연결 규칙, DNS 처리, 공유기 네트워크 구조를 함께 확인해야 안정적으로 작동합니다.
이 글에서는 mihomo 코어를 사용하는 Clash Verge Rev, Clash for Android 및 유사한 클라이언트를 기준으로 멀티 디바이스 공유 구조를 설명합니다. 클라이언트마다 메뉴 이름은 Allow LAN, LAN 접근 허용, Mixed Port 또는 외부 연결 허용처럼 다르게 표시될 수 있습니다. 먼저 한 대의 호스트 기기에서 프록시가 정상적으로 동작하는지 확인한 뒤 LAN 공유를 활성화하세요. 기본 연결이 확인되지 않은 상태에서 여러 기기를 동시에 연결하면 어느 구간에서 문제가 생겼는지 구분하기 어렵습니다.
멀티 디바이스 공유의 기본 구조 이해하기
집 안의 다른 기기가 Clash를 사용하려면 트래픽이 다음 순서로 이동합니다. 클라이언트 기기가 호스트 기기의 사설 IP 주소와 프록시 포트로 연결하고, 호스트의 Clash 코어가 요청을 받은 뒤 규칙에 따라 DIRECT 또는 프록시 정책 그룹을 선택합니다. 프록시로 분류된 요청은 선택한 노드로 전달되고, 직접 연결로 분류된 요청은 호스트의 일반 인터넷 연결을 사용합니다. 따라서 다른 기기의 프록시 설정에는 노드 서버 주소가 아니라 Clash를 실행하는 호스트 기기의 LAN 주소를 입력해야 합니다.
예를 들어 호스트 컴퓨터의 주소가 192.168.1.20이고 mixed 포트가 7890이라면 스마트폰이나 보조 노트북에는 HTTP 프록시와 SOCKS 프록시 주소를 각각 192.168.1.20, 포트를 7890으로 지정할 수 있습니다. 다만 모든 클라이언트가 mixed 포트를 지원하는 것은 아니므로, HTTP 전용 포트와 SOCKS 전용 포트를 분리해 사용하는 편이 호환성 면에서 더 명확합니다.
호스트 기기
Clash와 프록시 코어가 실행되는 컴퓨터 또는 모바일 기기입니다. LAN에서 접근할 수 있는 사설 IP 주소를 유지해야 합니다.
클라이언트 기기
호스트의 프록시 포트를 사용하도록 설정하는 노트북, 스마트폰, 태블릿, TV 또는 기타 애플리케이션입니다.
수신 포트
HTTP, SOCKS 또는 mixed 요청을 받는 포트입니다. 포트가 열려 있어도 수신 주소가 로컬호스트로 제한되면 다른 기기는 접근할 수 없습니다.
LAN 접근 허용과 포트 지정하기
Clash의 LAN 공유는 일반적으로 두 가지 설정으로 구성됩니다. 첫째는 다른 네트워크 장치가 수신 포트에 접근하도록 허용하는 옵션이고, 둘째는 어떤 포트에서 HTTP·SOCKS·mixed 요청을 받을지 지정하는 옵션입니다. allow-lan: true는 LAN 접근을 허용하는 핵심 설정이며, bind-address가 별도로 지정되어 있다면 수신 인터페이스도 함께 확인해야 합니다. 127.0.0.1에만 바인딩된 포트는 호스트 내부에서만 사용할 수 있으므로 멀티 디바이스 공유에 적합하지 않습니다.
구성 파일에서 직접 관리하는 경우에는 아래처럼 포트와 LAN 접근 여부를 확인할 수 있습니다. 이미 사용하는 구독 설정에 포트가 포함되어 있다면 같은 필드를 중복해서 추가하지 말고, 클라이언트의 설정 오버라이드 기능이나 현재 설정의 해당 항목을 수정하세요.
mixed-port: 7890
allow-lan: true
bind-address: "*"
mode: rule
log-level: infomixed-port는 HTTP와 SOCKS5 요청을 하나의 포트에서 받을 수 있어 스마트폰이나 TV처럼 프록시 유형 선택이 제한적인 장치에 편리합니다. 반면 애플리케이션의 호환성을 명확히 관리하려면 port: 7890과 socks-port: 7891처럼 HTTP와 SOCKS 포트를 나누는 방법도 있습니다. 이미 다른 프로그램이 해당 포트를 사용하고 있으면 코어가 시작되지 않거나 로그에 포트 바인딩 실패가 기록됩니다. 변경 후에는 로그에서 실제로 어떤 포트가 열렸는지 확인하고, 화면에 입력한 값만 믿지 마세요.
| 항목 | 예시 | 사용 상황 | 주의할 점 |
|---|---|---|---|
| HTTP 포트 | 7890 |
운영체제와 브라우저의 HTTP 프록시 | HTTPS 요청도 CONNECT 방식으로 처리되는지 확인 |
| SOCKS 포트 | 7891 |
SOCKS5를 지원하는 앱과 개발 도구 | DNS 처리 방식이 앱마다 다를 수 있음 |
| Mixed 포트 | 7890 |
HTTP와 SOCKS를 하나의 포트로 공유 | 클라이언트가 mixed 연결을 지원하는지 확인 |
| 관리 API | 9090 |
상태 확인과 외부 관리 도구 | 일반 프록시 포트와 다르며 LAN에 공개하지 않는 편이 안전 |
실제로 다른 기기 연결하기
이제 호스트와 클라이언트 한 대만 사용해 단계적으로 테스트합니다. 처음부터 모든 기기를 연결하지 말고, 같은 Wi-Fi에 연결된 스마트폰이나 노트북 하나를 선택하세요. 테스트 중인 클라이언트 기기가 게스트 네트워크에 있으면 같은 공유기에 연결되어 있어도 호스트 기기와 통신할 수 없습니다.
- 호스트 기기에서 Clash를 실행하고 사용할 설정을 선택합니다. Rule 모드와 테스트를 통과한 정책 그룹을 지정한 뒤 호스트 자체의 웹 접속을 확인합니다.
- Clash 설정에서
Allow LAN또는 LAN 접근 허용을 켭니다. mixed 포트가 없다면 HTTP 포트와 SOCKS 포트 중 하나를 정하고 실제 코어에 적용합니다. - 호스트의 사설 IP 주소를 확인합니다. Windows에서는
ipconfig, macOS와 Linux에서는ifconfig또는ip addr명령으로 Wi-Fi 또는 유선 인터페이스의 IPv4 주소를 확인할 수 있습니다. - 클라이언트 기기의 Wi-Fi 상세 설정에서 수동 프록시를 선택하고 서버 또는 호스트 항목에 사설 IP 주소를 입력합니다. 포트에는 Clash의 HTTP 또는 mixed 포트를 입력합니다.
- 먼저 호스트와 같은 LAN에 있는 공유기 관리 주소 또는 내부 장치에 접근해 네트워크 연결 자체를 확인합니다. 그다음 국내 사이트와 외부 사이트를 각각 열어 규칙 결과를 비교합니다.
- Clash의 연결 로그에서 클라이언트 기기의 요청이 보이는지 확인합니다. 로그가 전혀 없다면 규칙 문제보다 IP 주소, 포트, 방화벽, Wi-Fi 격리를 먼저 점검해야 합니다.
- 테스트가 끝나면 클라이언트 기기의 수동 프록시를 유지할지 결정합니다. 호스트가 꺼져 있거나 다른 네트워크로 이동하면 해당 프록시를 사용하는 기기의 연결도 영향을 받습니다.
Android에서는 Wi-Fi 네트워크의 프록시 설정에 호스트 주소와 포트를 입력하는 방식이 간단하지만, 이 설정은 해당 Wi-Fi 네트워크에서만 적용됩니다. 모바일 데이터까지 처리하려면 Android용 Clash 클라이언트의 VPN 또는 TUN 기능을 별도로 사용해야 합니다. iOS와 일부 TV 운영체제도 HTTP 프록시 설정은 지원할 수 있지만 SOCKS나 UDP 전달은 제한적일 수 있습니다. 브라우저에서만 테스트하지 말고 실제로 사용할 앱의 연결 방식도 확인하세요.
방화벽과 Wi-Fi 격리 확인
호스트의 Clash 로그에 요청이 나타나지 않는다면 운영체제 방화벽이 수신 연결을 차단하고 있을 가능성이 큽니다. Windows 방화벽에서는 선택한 네트워크 프로필이 개인 네트워크인지 확인하고, Clash 실행 파일 또는 지정 포트의 인바운드 허용 규칙을 검토합니다. macOS에서는 방화벽과 네트워크 확장 권한을 확인하고, Linux에서는 ufw나 배포판의 방화벽 정책을 살펴봅니다. 허용 범위는 전체 인터넷이 아니라 홈 LAN의 사설 대역으로 제한하는 것이 좋습니다.
호스트와 클라이언트가 모두 같은 SSID를 사용해도 공유기의 AP isolation, Client isolation, 게스트 네트워크 기능이 켜져 있으면 서로의 사설 IP로 연결할 수 없습니다. 공유기 설정에서 무선 단말 간 통신 차단 옵션을 확인하고, 보안상 게스트 네트워크를 유지해야 한다면 별도의 유선 호스트나 허용된 VLAN 구성을 사용해야 합니다.
국내 사이트와 홈 네트워크를 직접 연결하기
멀티 디바이스 환경에서는 모든 트래픽을 프록시로 보내는 것보다 국내 사이트와 로컬 장치를 직접 연결하는 규칙을 두는 편이 일반적으로 효율적입니다. 국내 서비스는 DIRECT로 처리하면 불필요한 우회 지연을 줄일 수 있고, 공유기 관리 페이지·프린터·NAS·스마트 홈 장치도 로컬 경로를 유지할 수 있습니다. 단, “국내 사이트”와 “한국에서 운영되는 서비스”가 항상 같은 것은 아닙니다. 로그인, 결제, 스트리밍처럼 지역 정책이 중요한 서비스는 실제 연결 위치와 DNS 응답을 함께 고려해야 합니다.
규칙은 위에서 아래로 평가되므로 예외를 먼저 배치하고 넓은 지역 규칙과 MATCH를 뒤에 둡니다. 다음은 구조를 보여 주기 위한 예시입니다. 실제 도메인 목록은 사용하는 규칙 제공자와 서비스 요구 사항에 맞게 조정해야 합니다.
rules:
- DOMAIN-SUFFIX,router.local,DIRECT
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
- DOMAIN-SUFFIX,co.kr,DIRECT
- DOMAIN-SUFFIX,example-overseas.com,PROXY
- GEOIP,KR,DIRECT
- MATCH,PROXYno-resolve는 해당 IP-CIDR 규칙을 평가하기 위해 추가 DNS 확인을 하지 않도록 하는 옵션입니다. 로컬 사설 주소는 이미 목적지가 명확하므로 DNS 재확인을 줄이는 데 도움이 됩니다. 다만 도메인 기반 규칙과 실제 서비스의 CDN 도메인이 일치하지 않을 수 있으므로, 특정 서비스가 예상과 다른 정책으로 처리되면 연결 로그에서 매칭된 규칙과 최종策略을 확인해야 합니다.
| 대상 | 권장 기본 처리 | 확인할 이유 |
|---|---|---|
| 공유기·프린터·NAS | DIRECT |
사설 IP와 로컬 이름 확인이 프록시를 거치면 접근이 실패할 수 있음 |
| 국내 일반 웹서비스 | DIRECT |
불필요한 우회와 지연을 줄일 수 있음 |
| 해외 업무 서비스 | 프록시 정책 그룹 | 업무용 도메인이 국내 CDN을 사용하더라도 실제 요구 경로를 확인해야 함 |
| 분류되지 않은 연결 | MATCH로 결정 |
예상하지 못한 직접 연결을 줄이고 기본 정책을 명확히 함 |
공유기 구성과 호스트 안정성 높이기
호스트 기기의 사설 IP가 DHCP에 의해 자동으로 바뀌면 클라이언트에 저장한 프록시 주소가 어느 순간 작동하지 않을 수 있습니다. 공유기에서 호스트의 MAC 주소에 DHCP 예약을 설정하거나 호스트 운영체제에서 네트워크 구성을 고정해 주소를 안정적으로 유지하세요. 일반적인 홈 네트워크에서는 192.168.1.20처럼 관리하기 쉬운 주소를 예약하고, 공유기 DHCP 범위와 겹치지 않도록 설정하는 것이 좋습니다.
공유기와 호스트 사이에 메시 Wi-Fi, 이중 NAT, VLAN, 유선 스위치가 구성되어 있다면 기기 간 통신 경로가 단순하지 않을 수 있습니다. 같은 IP 대역처럼 보여도 무선 단말 격리나 방화벽 정책이 별도로 적용될 수 있습니다. 유선으로 연결된 호스트와 같은 SSID의 클라이언트부터 테스트하고, 이후 다른 액세스 포인트나 VLAN에 있는 기기를 추가하면 원인 범위를 좁히기 쉽습니다.
호스트가 항상 켜져 있어야 하는 구조라면 절전 모드와 네트워크 어댑터 전원 관리도 확인하세요. 컴퓨터가 절전 상태에 들어가면 Clash 포트도 응답하지 않으며, 공유기를 재시작한 뒤 호스트가 다른 IP를 받을 수도 있습니다. 여러 가족 기기가 사용하는 경우에는 호스트를 유선 LAN에 연결하고, 과도한 로그 기록과 불필요한 규칙 제공자 업데이트를 줄여 안정성을 높일 수 있습니다.
DNS와 TUN을 멀티 디바이스 환경에서 다루는 방법
다른 기기의 DNS 요청은 프록시 요청과 별도로 처리될 수 있습니다. 클라이언트가 호스트의 HTTP 프록시만 사용하면 도메인 확인은 클라이언트 운영체제나 애플리케이션이 직접 수행할 수 있습니다. 이 경우 DNS 결과와 실제 프록시 출구의 지역이 달라져 지역 규칙이 예상과 다르게 적용될 수 있습니다. 특히 fake-ip, redir-host, 암호화 DNS를 사용하는 설정에서는 호스트의 DNS 모듈과 클라이언트 기기의 DNS 동작을 함께 확인해야 합니다.
처음 공유를 구성할 때는 DNS와 TUN을 동시에 변경하지 않는 것이 좋습니다. 일반 HTTP 또는 mixed 프록시로 브라우저 연결을 확인한 후, 프록시를 읽지 않는 앱이나 전체 IP 트래픽 처리가 필요할 때 TUN을 검토하세요. TUN은 가상 인터페이스와 라우팅 테이블을 변경하므로 호스트에서만 활성화할지, 각 클라이언트 기기에서 별도로 활성화할지 결정해야 합니다. 호스트의 TUN이 켜져 있다고 해서 LAN 클라이언트의 모든 트래픽이 자동으로 TUN을 통해 처리되는 것은 아닙니다.
보안, 성능 및 유지 관리 기준
LAN 프록시는 같은 네트워크에 있는 기기가 호스트의 노드와 인터넷 연결을 함께 사용하도록 만드는 기능입니다. 그러므로 신뢰할 수 없는 기기가 연결된 네트워크에서는 LAN 접근을 계속 켜 두지 않는 것이 좋습니다. 공용 카페 Wi-Fi, 호텔 네트워크, 회사의 방문자 네트워크에서는 공유를 끄고, 필요하다면 호스트 방화벽에서 홈 LAN 대역만 허용하세요. 관리 API 포트는 프록시 포트와 분리하고 외부 인터페이스에 바인딩하지 않는 편이 안전합니다.
성능 측면에서는 모든 기기가 하나의 호스트와 하나의 노드를 동시에 사용하는 구조의 한계를 고려해야 합니다. 영상 스트리밍, 대용량 업데이트, 클라우드 동기화가 겹치면 호스트의 CPU·메모리·업로드 대역폭과 노드의 동시 연결 수가 병목이 될 수 있습니다. 연결 수가 급증할 때는 로그 수준을 info 또는 필요한 경우에만 debug로 조정하고, 실제 사용하지 않는 규칙 제공자와 프록시 제공자는 정리하세요.
문제가 발생했을 때는 다음 순서로 복구하면 됩니다. 먼저 클라이언트 기기의 수동 프록시를 끄고 직접 연결이 되는지 확인합니다. 다음으로 호스트의 Clash에서 LAN 접근, 사설 IP, 수신 포트, 방화벽 상태를 확인합니다. 그 후 호스트 자체에서 노드와 규칙이 정상인지 검증하고, 마지막으로 클라이언트 기기의 DNS·앱별 프록시·TUN 설정을 비교합니다. 포트 변경, 규칙 수정, 코어 업데이트를 한 번에 실행하지 말고 한 항목씩 적용한 뒤 로그와 실제 접속 결과를 기록하세요.