Clash 생태계 · 클라이언트와 설정
운영체제에 맞는 클라이언트를 선택하고 구독 가져오기, 규칙 분기, DNS 설정을 확인하세요.
CONFIGURATION / 설정 가이드
구독, 프록시 그룹, 규칙의 역할을 구분한 뒤 앱 트래픽이 코어로 전달되는 방식을 정하세요.
클라이언트는 그래픽 인터페이스와 구독 저장, 시스템 연동을 담당하고, 코어는 설정을 해석해 연결을 만들고 트래픽을 분기합니다. 아래 예시는 각 설정 항목을 설명하며, 단독 실행 가능한 완성 설정 파일은 아닙니다. 사용하기 전에 유효한 프록시 정의를 합치고, 프록시 그룹 이름과 규칙에서 참조하는 이름이 일치하는지 확인하세요.
구독 주소는 원격 설정을 가져오는 데 사용하며, 클라이언트 설치 파일이나 네트워크 연결을 의미하지 않습니다. 클라이언트의 구독 화면에 링크를 붙여 넣고 다운로드가 완료되면 해당 설정을 선택한 뒤 프록시 목록이 표시되는지 확인하세요. 전체 설정 구독과 프록시 목록 구독은 별도로 다뤄야 합니다. 후자는 proxy-providers로 불러온 다음 프록시 그룹에서 참조해야 합니다. 원격 업데이트 과정에서 기존 파일이 덮어써질 수 있으므로 계속 사용할 규칙은 클라이언트의 오버라이드나 병합 설정에 작성하세요. 그래야 업데이트할 때마다 다시 수정하지 않아도 됩니다. 구독 주소에는 접근 정보가 포함될 수 있으니 화면을 캡처하거나 로그를 공유하기 전에 주소를 가리세요.
Clash Vergeproxy-providers:
remote:
type: http
url: "https://example.com/sub?token=xxxx"
path: ./providers/remote.yaml
interval: 3600프록시 그룹은 여러 출구를 규칙에서 참조할 대상으로 묶습니다. select는 직접 경로를 고정할 때, url-test는 지정한 테스트 주소의 결과로 후보를 선택할 때, fallback은 목록의 우선순위에 따라 사용 가능한 출구를 찾을 때 적합합니다. 테스트 시간은 특정 주소와 해당 시점의 네트워크 상태만 반영하므로 다운로드 속도로 환산할 수 없습니다. 먼저 수동 그룹으로 각 경로가 작동하는지 확인한 다음 자동 그룹을 추가하면, 문제 발생 시 경로 오류와 전환 로직을 쉽게 구분할 수 있습니다. 아래 use는 구독 설정의 remote 목록을 참조하므로 설정을 병합할 때 이름을 일치시켜 빈 그룹이 생기지 않도록 하세요.
proxy-groups:
- name: 자동 선택
type: url-test
use:
- remote
url: https://www.gstatic.com/generate_204
interval: 300
tolerance: 50규칙 모드는 위에서 아래로 연결을 확인하고, 일치하는 규칙을 찾으면 지정된 프록시 그룹으로 전달합니다. 이후 규칙은 더 이상 검사하지 않습니다. 따라서 정확한 도메인, 로컬 네트워크 대역, 특정 앱 규칙은 일반 규칙보다 앞에 두고, 마지막에 MATCH로 나머지 트래픽을 처리하는 것이 좋습니다. DOMAIN-SUFFIX는 도메인과 하위 도메인을, IP-CIDR은 IP 주소 대역을 매칭하므로 각각 사용하는 정보가 다릅니다. 설정이 맞아 보이는데 결과가 다르면 현재 선택한 노드 이름만 보지 말고 연결 화면에서 실제로 일치한 규칙과 대상 프록시 그룹을 확인하세요. 설정을 바꾼 뒤 새 연결을 만들어야 하며, 이미 연결된 장시간 연결은 바로 경로가 바뀌지 않을 수 있습니다.
rules:
- DOMAIN-SUFFIX,example.com,자동 선택
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
- MATCH,자동 선택Fake-IP는 도메인에 예약 주소를 반환하고, 코어가 이후 연결에서 도메인을 복원해 규칙을 적용하도록 합니다. 도메인 기반 분기 정보를 유지하는 데 도움이 됩니다. 하지만 Fake-IP만으로 DNS 유출을 막을 수 있는 것은 아닙니다. 앱이 코어의 DNS를 사용하는지, 시스템 라우팅이 어떻게 처리되는지, 상위 DNS 요청이 어느 출구를 이용하는지 함께 확인해야 합니다. 실제 DNS 응답에 의존하는 일부 로컬 네트워크 서비스는 예외 처리가 필요할 수 있으며, 예외 범위는 가능한 한 좁게 설정하세요. 활성화한 뒤 새 연결로 테스트하고 DNS 요청과 실제 트래픽의 경로를 각각 확인하세요. 예약 주소가 보인다는 사실만으로 모든 트래픽이 프록시를 통과한다고 단정할 수 없습니다.
dns:
enable: true
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
fake-ip-filter:
- "*.lan"
- "localhost"
nameserver:
- https://dns.alidns.com/dns-queryTUN은 가상 네트워크 인터페이스로 트래픽을 받아 시스템 프록시 설정을 따르지 않는 앱까지 처리할 수 있습니다. 다만 클라이언트 권한, 드라이버 또는 시스템 네트워크 확장이 필요합니다. 활성화하기 전에 시스템 프록시로 설정을 검증하고 연결이 정상인지 확인한 다음 라우팅을 처리하세요. 다른 VPN, 가상 머신 또는 회사 네트워크와 함께 사용할 때는 라우팅 충돌과 제외할 네트워크 대역을 확인하고, 여러 트래픽 처리 도구를 반복해서 전환하지 않는 것이 좋습니다. 예시의 DNS 하이재킹은 TUN으로 들어오는 일반 DNS 요청에 적용됩니다. 앱 자체의 암호화 DNS는 별도로 확인해야 합니다. 플랫폼별 네트워크 스택 지원과 권한 설정 방법은 해당 클라이언트 안내를 따르세요.
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53시스템 프록시는 앱의 프록시 요청을 로컬 수신 포트로 전달합니다. 해당 설정을 따르는 프로그램만 프록시를 사용합니다. mixed-port는 HTTP와 SOCKS 요청을 모두 받으며, 값을 바꾼 뒤에는 클라이언트에 표시된 시스템 프록시 주소도 확인해야 합니다. 시작 시 자동 실행은 그래픽 클라이언트 기능이지 아래 코어 설정 항목이 아닙니다. 클라이언트 실행, 코어 실행, 프록시 자동 활성화도 서로 별개의 옵션일 수 있습니다. 처음 설정한 뒤 한 번 재부팅하고 시스템 트레이, 코어 상태, 시스템 프록시 설정이 일치하는지 확인하세요. 클라이언트를 종료하기 전에 시스템 프록시를 꺼야 로컬 수신 포트가 중단된 뒤에도 시스템이 해당 포트를 계속 가리키는 일을 막을 수 있습니다.
mixed-port: 7890
allow-lan: false
bind-address: "127.0.0.1"
mode: rule
log-level: infoPACKAGES / 플랫폼별 선택
운영체제와 프로세서 아키텍처를 먼저 확인한 뒤 그래픽 클라이언트를 선택하세요.
Clash는 여러 프로젝트가 공유하는 생태계 이름이며, 모든 플랫폼에서 같은 설치 프로그램을 사용하는 것은 아닙니다. 클라이언트마다 인터페이스, 코어 업데이트 주기, 시스템 연동 방식이 다르므로 설정 항목은 실제 코어의 지원 여부를 기준으로 확인해야 합니다. 다운로드 페이지에서 플랫폼별 설치 파일, 유지 관리 상태, 설치 안내를 확인할 수 있습니다. 클라이언트별 차이는 클라이언트 비교에서 살펴보세요.
우선 추천 클라이언트는 Clash Plus이며, Clash Verge Rev, FlClash, Clash Nyanpasu도 선택할 수 있습니다. 설치 전에 시스템 아키텍처와 실행 구성 요소 요구 사항을 확인하세요. TUN 서비스 권한과 일반 실행 권한은 별도로 설정해야 합니다.
기존 클라이언트에서 옮길 때는 먼저 구독과 사용자 규칙을 내보내고, 혼합 포트와 시작 설정을 확인하세요. 두 클라이언트가 동시에 시스템 프록시를 설정하지 않도록 주의하세요.
다운로드 페이지로 이동Apple Silicon 또는 Intel 프로세서에 맞춰 Clash Plus, Clash Verge Rev, FlClash를 선택하세요. 설치 후 시스템 안내에 따라 필요한 권한을 허용하고 메뉴 막대 상태와 프록시 포트를 확인하세요.
시스템 프록시와 네트워크 확장은 허용 범위가 다릅니다. 네트워크 문제가 발생하면 먼저 다른 VPN이나 이전 클라이언트가 실행 중인지 확인한 다음 DNS 또는 TUN 설정을 조정하세요.
다운로드 페이지로 이동우선 추천 클라이언트는 Clash Plus이며, Clash Meta for Android, FlClash, Surfboard도 사용할 수 있습니다. 기기의 ABI에 맞는 설치 파일을 선택하고 처음 연결할 때 시스템 VPN 권한을 허용하세요.
백그라운드 연결이 끊기면 배터리 최적화, 백그라운드 실행, 제조사별 절전 제한을 확인하세요. Surfboard는 Clash YAML과 설정 형식이 다르므로 가져오기 전에 구독 형식을 확인해야 합니다.
다운로드 페이지로 이동Clash Plus를 선택하고 다운로드 페이지에서 App Store로 이동하세요. 제품 정보는 공식 사이트 clashplus.io에서 확인할 수 있습니다. 연결하기 전에 시스템 안내에 따라 VPN 구성을 추가하세요.
구독을 가져온 뒤 설정과 프록시 그룹을 선택하고 연결을 시작하세요. 데스크톱 클라이언트의 서비스 모드나 시작 시 자동 실행 설정을 모바일 운영체제에 그대로 적용할 수는 없습니다.
다운로드 페이지로 이동그래픽 데스크톱 환경에서는 Clash Verge Rev 또는 FlClash를 선택하고 배포판에 맞는 패키지 형식을 사용하세요. 서버와 라우터용 mihomo는 다운로드 페이지의 코어 섹션에서 찾을 수 있습니다.
데스크톱 세션의 시스템 프록시 설정이 모든 터미널 프로세스에 자동으로 적용되지는 않습니다. 명령줄 앱은 환경 변수를 확인해야 하며, 서비스 배포 시에는 실행 사용자, 설정 디렉터리, 로그 위치도 지정해야 합니다.
다운로드 페이지로 이동SOURCE / 코어와 클라이언트
원래 Clash는 규칙 기반 프록시와 YAML 설정의 기반을 마련했으며, 이후 등장한 클라이언트와 코어 포크에서도 비슷한 인터페이스 명칭이 널리 사용됩니다. mihomo는 한때 Clash.Meta라는 이름으로 불렸으며, 기존 설정 체계를 바탕으로 프로토콜, 규칙 세트, 네트워크 처리 기능을 확장했습니다. 이름이 비슷한 설치 파일을 발견하면 아이콘이나 파일명만으로 호환성을 판단하지 말고 유지 관리 프로젝트와 포함된 코어를 확인하세요. 이 사이트는 다운로드와 한국어 자료를 제공하는 안내 페이지이며 각 클라이언트 개발팀을 대표하지 않습니다.
mihomo는 수신 포트를 열고 DNS를 처리하며 규칙을 해석해 프록시 연결을 만듭니다. Clash Verge Rev, FlClash 같은 그래픽 클라이언트는 구독 관리, 트레이 메뉴, 시스템 프록시 연동 기능을 제공합니다. 두 요소는 따로 업데이트될 수 있으므로 클라이언트를 바꾸면 구독 주소가 같더라도 일부 설정의 위치나 적용 방식이 달라질 수 있습니다. 문제를 확인할 때는 먼저 클라이언트 이름과 사용 중인 코어를 기록한 뒤 최종 생성된 실행 설정을 살펴보세요. 인터페이스의 스위치를 표준 YAML 설정 항목으로 오해하지 않도록 주의해야 합니다.
mihomo 소스 코드는 공개 저장소에서 관리되며 GPL-3.0 라이선스를 따릅니다. 코드, 커밋 기록, 이슈 논의는 구현과 변경 배경을 파악하는 데 도움이 되지만, 소스가 공개되어 있다고 해서 모든 설정이 예상대로 작동하는 것은 아닙니다. 그래픽 클라이언트마다 라이선스, 의존성, 배포 안내가 다르므로 코어 라이선스가 설치 패키지 전체의 조건을 뜻하지는 않습니다. 빌드하거나 재배포하려면 해당 프로젝트의 라이선스 파일을 확인하고 필요한 고지 사항을 유지하며 의존 구성 요소의 이용 조건도 살펴보세요.
업데이트 전에 구독 주소, 오버라이드 파일, 사용자 규칙을 저장하고 현재 수신 포트와 트래픽 처리 방식을 기록하세요. 업데이트 후 설정을 불러온 다음 시작 로그, 프록시 그룹, 새로 만든 연결을 확인하고 마지막으로 TUN과 시작 시 자동 실행을 다시 설정하세요. 구독 업데이트는 설정을 다시 가져오는 작업이고, 클라이언트 업데이트는 인터페이스와 패키지에 포함된 코어를 바꾸는 작업이므로 구분해야 합니다. 유지 관리가 중단된 클라이언트는 이전 설정을 참고하는 용도로만 활용하고, 새 운영체제나 프로토콜에 계속 대응할 것이라고 기대하지 않는 편이 좋습니다. 이전 방법은 Clash for Windows 지원 종료 후 대체 클라이언트로 이전하기에서 확인하세요.
NOTES / 사용 팁
설정이 적용되려면 클라이언트 지원 여부, 유효한 코어 설정 항목, 올바른 네트워크 경로가 모두 맞아야 합니다. 아래 문서는 구체적인 증상과 이전 상황을 다루므로 첫 연결을 마친 뒤 참고하기 좋습니다. 문제를 확인할 때는 한 번에 하나씩만 바꾸고 복원할 수 있는 설정 사본을 보관해야 어떤 변경이 결과에 영향을 줬는지 파악할 수 있습니다.
지원이 종료된 클라이언트의 대체 제품을 정리하고 플랫폼 지원 범위와 코어 차이를 비교합니다. 구독, 규칙, 사용자 설정을 백업한 뒤 이전하고 포트, 시스템 프록시, 시작 설정을 다시 확인해 기존 설정이 새 클라이언트에 영향을 주지 않도록 하세요.
운영체제별로 설정 문법, 포트 사용 여부, 코어 파일 권한, WebView 구성 요소를 확인하세요. 먼저 로그를 저장하고 최근 변경 사항을 되돌린 다음 데이터 디렉터리 초기화를 고려하세요. 원인을 찾기 전에 구독과 오버라이드 파일을 잃지 않도록 주의해야 합니다.
앱의 DNS 조회, 코어의 상위 DNS, 실제 트래픽이 나가는 출구를 각각 확인하고 Fake-IP, nameserver-policy, respect-rules, TUN을 이용해 요청 경로를 분석하세요. 테스트 결과는 네트워크 환경을 고려해 해석해야 하며, 한 번 표시된 결과만으로 결론을 내려서는 안 됩니다.