Clash란 무엇일까? 앱·구독·노드 관계를 처음부터 이해하기

Clash를 이해하는 첫 단계: 앱·코어·설정 구분하기

Clash를 처음 접하면 앱 이름, 구독 서비스, 노드 이름이 모두 하나의 제품처럼 보일 수 있습니다. 그러나 실제로는 역할이 서로 다른 여러 요소가 함께 작동합니다. 클라이언트 앱은 설정을 관리하고 화면을 제공하며, 코어는 실제 프록시 연결과 규칙 처리를 담당합니다. 구독은 노드와 정책 설정을 내려받는 주소이고, 노드는 인터넷 트래픽을 대신 전달하는 개별 프록시 서버입니다.

FlClash, Clash Verge Rev, ClashX, Clash for Android 같은 프로그램은 일반적으로 클라이언트에 해당합니다. 사용자는 이 앱에서 구독 링크를 추가하고, 설정을 선택하며, 시스템 프록시 또는 TUN 모드를 켭니다. 하지만 버튼을 눌러 보이는 화면과 실제 네트워크 처리는 같은 계층이 아닙니다. 앱이 실행 중이어도 코어가 중지되어 있거나 로컬 포트가 다른 프로그램과 충돌하면 인터넷 연결은 정상적으로 프록시되지 않을 수 있습니다.

요소	주요 역할	예시	문제가 생겼을 때
클라이언트	화면, 설정 관리, 권한 요청, 시스템 프록시 전환	FlClash, Clash Verge Rev	앱이 열리지 않거나 설정을 불러오지 못함
코어	포트 수신, DNS, 규칙 매칭, 프록시 연결	mihomo, 클래식 Clash	포트 오류, 지원하지 않는 필드, 연결 실패
구독	노드와 정책 설정을 원격으로 제공	HTTPS 구독 URL	401, 403, 만료, 형식 오류
노드	실제 외부 서버로 트래픽 전달	Shadowsocks, Trojan, VLESS	연결 시간 초과, 인증 실패, 속도 저하

클라이언트와 코어는 어떻게 함께 작동할까

클라이언트에서 “시작”을 누르면 내부적으로 코어 실행 파일이 설정 파일을 읽고 로컬 포트를 엽니다. 일반적인 설정에서는 mixed-port: 7890이 HTTP와 SOCKS 연결을 함께 받을 수 있는 포트로 사용됩니다. 운영체제의 시스템 프록시가 127.0.0.1:7890을 가리키면 브라우저와 시스템 프록시를 따르는 앱의 요청이 코어로 전달됩니다.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090

여기서 mixed-port와 external-controller는 서로 다른 용도입니다. 전자는 애플리케이션의 프록시 요청을 받는 포트이고, 후자는 클라이언트가 코어의 상태를 조회하거나 정책 그룹을 전환하는 관리용 인터페이스입니다. 관리 포트인 9090을 브라우저나 다른 앱의 프록시 주소로 입력하면 원하는 결과가 나오지 않습니다.

클래식 Clash와 mihomo는 설정 구조가 상당 부분 비슷하지만 기능 범위가 동일하지는 않습니다. 기본적인 proxies, proxy-groups, rules 구조는 서로 이해할 수 있는 경우가 많습니다. 그러나 구독에 Hysteria2, TUIC, VLESS Reality, WireGuard, 복잡한 DNS 정책 또는 TUN 전용 필드가 포함되어 있다면 사용하는 코어가 해당 기능을 지원해야 합니다. 앱 이름만 보고 호환성을 판단하지 말고 코어 정보와 시작 로그를 확인해야 합니다.

시스템 프록시와 TUN 모드의 차이

시스템 프록시 모드는 운영체제의 HTTP·HTTPS·SOCKS 프록시 설정을 로컬 포트로 바꾸는 방식입니다. 구조가 단순하고 권한 요구가 적어 처음 시작할 때 적합합니다. 반면 TUN 모드는 가상 네트워크 인터페이스와 라우팅을 사용해 시스템 프록시를 읽지 않는 프로그램의 트래픽까지 코어로 전달할 수 있습니다. 대신 Windows, macOS, Android에서 VPN 또는 네트워크 권한을 요구할 수 있으며 DNS 하이재킹과 라우팅 설정이 추가됩니다.

웹 브라우저와 일반 업무 앱만 사용한다면 먼저 시스템 프록시를 선택합니다.
명령줄 도구, 게임, 일부 업데이트 프로그램이 프록시를 무시한다면 TUN을 검토합니다.
TUN을 켜기 전에는 기존 VPN, 다른 프록시 앱, 보안 프로그램의 가상 어댑터를 확인합니다.
연결 문제가 발생하면 TUN을 끄고 시스템 프록시만으로 재현해 원인을 좁힙니다.

구독 링크는 노드를 어떻게 설정으로 바꿀까

구독 링크는 보통 긴 인증 토큰이 포함된 HTTPS 주소입니다. 클라이언트가 이 주소에 요청을 보내면 구독 서버는 사용자가 선택한 형식에 따라 Clash 또는 mihomo 설정을 반환합니다. 반환된 설정에는 여러 노드, 정책 그룹, 규칙, DNS 항목과 업데이트용 외부 리소스가 들어갈 수 있습니다. 따라서 구독은 단순히 서버 주소 하나를 내려받는 기능이 아니라 코어가 읽을 수 있는 설정 묶음을 전달하는 과정입니다.

일반적인 처리 순서는 다음과 같습니다. 먼저 클라이언트가 구독 URL에 요청을 보내고, DNS가 구독 도메인의 주소를 찾습니다. 그다음 서버와 HTTPS 연결을 맺어 응답을 받고, 클라이언트가 응답을 YAML 또는 지원되는 설정 형식으로 파싱합니다. 마지막으로 코어가 proxies에 정의된 노드를 읽고 proxy-groups와 rules에 따라 실제 연결 대상을 결정합니다.

구독 URL을 클라이언트의 Profiles 또는 설정 페이지에 추가합니다.
서비스가 제공하는 형식에서 Clash 또는 mihomo를 선택합니다.
업데이트가 끝나면 설정 파일의 노드와 정책 그룹을 확인합니다.
코어를 시작하고 정책 그룹에서 사용할 노드를 선택합니다.
브라우저에서 IP 확인 또는 테스트 페이지를 열어 연결 결과를 확인합니다.

구독 서버가 반환하는 내용은 서비스마다 다릅니다. 어떤 서비스는 모든 노드를 직접 proxies에 넣고, 어떤 서비스는 proxy-providers를 통해 별도의 원격 파일을 참조합니다. 또한 rule-providers가 포함되어 있으면 기본 설정을 받은 뒤에도 규칙 세트를 추가로 다운로드해야 할 수 있습니다. 기본 구독 업데이트가 성공했다는 사실만으로 모든 외부 리소스가 정상이라고 단정할 수 없습니다.

직접 가져오기: 처음 설정하는 실제 순서

이제 새 설정을 추가하는 과정을 기준으로 확인해 보겠습니다. 메뉴 이름은 클라이언트와 플랫폼에 따라 조금씩 다르지만, “프로필”, “Profiles”, “설정” 또는 “구독 관리”와 같은 항목에서 비슷한 기능을 찾을 수 있습니다. 처음에는 여러 구독을 동시에 추가하지 말고 하나만 등록하는 편이 오류를 추적하기 쉽습니다.

1단계: 구독을 등록하고 형식을 확인하기

FlClash 또는 사용하는 Clash 클라이언트를 열고 설정 목록으로 이동합니다.
URL에서 가져오기 또는 구독 추가 메뉴를 선택합니다.
서비스에서 발급한 전체 HTTPS 주소를 붙여넣습니다.
이름은 “일상용”, “업무용”처럼 알아보기 쉽게 지정합니다.
서비스에 형식 선택 항목이 있다면 Clash 또는 mihomo를 선택합니다.
가져오기를 완료한 뒤 노드 수와 정책 그룹이 표시되는지 확인합니다.

노드가 하나도 표시되지 않는다면 먼저 링크 자체가 만료되지 않았는지 확인합니다. 브라우저에서 링크를 열었을 때 로그인 페이지나 HTML 안내문이 나타난다면 Clash 설정을 받은 것이 아닙니다. 401 Unauthorized는 인증 정보 문제, 403 Forbidden은 접근 정책이나 요청 차단, 404 Not Found는 주소 변경 가능성을 의미합니다. 응답을 받았지만 yaml: unmarshal errors가 표시되면 코어가 이해하지 못하는 필드나 잘못된 YAML 구조가 포함되었을 수 있습니다.

2단계: 노드가 아니라 정책 그룹을 선택하기

구독을 추가한 뒤 보이는 “노드 선택”, “Proxy”, “Global”, “Streaming” 같은 항목은 대개 정책 그룹입니다. 정책 그룹은 여러 노드를 하나로 묶어 규칙에서 사용할 수 있도록 만든 선택 계층입니다. 사용자는 정책 그룹 안에서 특정 노드를 직접 고르거나, url-test와 같은 자동 선택 그룹을 사용할 수 있습니다. 그룹을 바꾸지 않고 노드 목록만 확인하면 실제 트래픽에는 이전 선택이 계속 적용될 수 있습니다.

정책 유형	동작	처음 사용할 때의 기준
select	사용자가 노드를 직접 선택	문제 원인을 추적하기 쉽고 결과가 예측 가능함
url-test	지정한 URL의 지연 시간을 비교	자동 선택이 필요하지만 측정값이 항상 실제 속도를 뜻하지는 않음
fallback	앞의 노드가 실패하면 다음 노드 사용	연결 유지가 중요한 환경에 적합
load-balance	여러 노드에 요청을 분산	서비스 특성에 따라 세션 유지나 인증 문제가 생길 수 있음

3단계: 연결과 규칙을 따로 검증하기

노드 지연 시간 테스트가 성공해도 원하는 웹사이트가 열리지 않을 수 있습니다. 지연 시간 테스트는 특정 주소에 대한 연결만 확인하고, 최종 접속 도메인이 어떤 규칙으로 분류되는지까지 보장하지 않기 때문입니다. 먼저 정책 그룹에서 한 노드를 직접 선택한 뒤 브라우저를 열고, 그다음 규칙 모드에서 국내 사이트와 해외 사이트의 처리 결과를 각각 확인하세요.

설정의 mode: rule은 rules를 위에서부터 순서대로 적용합니다. 특정 도메인 규칙이 너무 넓은 위치에 있으면 예상과 다른 정책 그룹으로 전달될 수 있습니다. 반대로 모든 트래픽을 하나의 프록시로 보내는 전역 모드는 규칙 문제를 잠시 피할 수 있지만, 국내 서비스까지 우회하거나 속도와 지연 시간이 불필요하게 증가할 수 있습니다.

mode: rule
rules:
  - DOMAIN-SUFFIX,example.com,Proxy
  - GEOIP,KR,DIRECT
  - MATCH,Proxy

테스트할 때는 한 번에 여러 설정을 바꾸지 않는 것이 중요합니다. 먼저 코어 실행 여부와 로컬 포트를 확인하고, 다음으로 선택한 노드의 연결 상태를 확인합니다. 그 후 시스템 프록시 또는 TUN을 켜고, 마지막으로 DNS와 규칙을 점검합니다. 이 순서를 지키면 “노드가 죽은 것인지”, “프록시가 앱에 적용되지 않은 것인지”, “규칙이 다른 그룹을 선택한 것인지”를 구분하기 쉽습니다.

처음 시작할 때 기억할 판단 기준

좋은 설정은 노드가 많은 설정이 아니라 현재 사용하는 코어와 네트워크 환경에 맞는 설정입니다. 구독에 수백 개의 노드가 있어도 실제로 안정적으로 사용할 수 있는 노드는 일부일 수 있습니다. 가까운 지역의 서버가 항상 빠른 것도 아니며, 한 번 측정한 지연 시간이 장시간 다운로드 성능을 보장하지도 않습니다. TCP 기반 노드와 UDP·QUIC 기반 노드는 통신사와 공유기 환경에 따라 결과가 달라질 수 있습니다.

클라이언트 확인: 앱의 이름보다 현재 실행 중인 코어와 코어 버전을 확인합니다.
구독 형식 확인: 클래식 Clash, Meta, mihomo 중 설정이 요구하는 형식을 선택합니다.
노드 확인: 프로토콜, 인증 정보, TLS 설정과 서버 상태가 서로 맞는지 봅니다.
정책 확인: 실제 트래픽이 어떤 정책 그룹을 사용하는지 확인합니다.
모드 확인: 시스템 프록시로 충분한지 TUN이 필요한지 먼저 판단합니다.
보안 확인: 외부 제어 인터페이스를 LAN이나 인터넷에 불필요하게 공개하지 않습니다.

특히 allow-lan: true를 켜면 같은 네트워크의 다른 기기가 로컬 프록시 포트에 접근할 가능성이 생깁니다. 다른 기기에서 사용할 목적이 없다면 false를 유지하고, 외부 제어 인터페이스에도 강력한 secret을 설정하는 편이 안전합니다. 공용 Wi-Fi에서는 TUN과 LAN 공유를 동시에 켜기보다 필요한 기능만 활성화하는 것이 좋습니다.