사용자 정의 규칙 튜토리얼: 지정한 앱을 원하는 노드로 보내기

먼저 알아둘 개념: Clash는 「앱 이름」만으로는 잘 안 나눈다

사용자 입장에서는 「크롬만 프록시, 은행 앱은 직접」이 자연스럽지만, 코어가 보는 것은 연결의 메타데이터입니다. 구버전 Clash는 주로 도메인·IP·지역으로 규칙을 맞추고, 실행 파일 이름으로 분기하는 것은 Clash Meta(Mihomo) 등 확장 빌드에서 지원 범위가 넓습니다. 그래서 「앱별 분류」를 말할 때는 (1) 프로세스 규칙이 되는 환경인지, (2) 아니면 그 앱이 붙는 도메인을 규칙으로 덮는지를 먼저 가릅니다.

TUN 모드를 켜면 시스템이 가상 NIC 쪽으로 더 많은 트래픽을 넘기므로, 프로세스 매칭과 함께 쓸 때 기대에 가깝게 동작하는 경우가 많습니다. 반대로 브라우저만 시스템 프록시를 탄다면, 규칙은 그 브라우저가 여는 호스트명 기준으로만 작동합니다. 전체 흐름은 Clash 기본 튜토리얼에서 잡고, 그룹 이름 설계는 프록시 그룹(proxy-groups) 가이드와 같이 읽으면 설정이 끊기지 않습니다.

① Windows: PROCESS-NAME·PROCESS-PATH (Mihomo 계열)

Clash Meta를 쓰는 Windows 클라이언트(예: Clash Verge Rev)에서는 실행 파일 이름이나 경로로 규칙을 걸 수 있습니다. PROCESS-NAME은 프로세스 이름(예: chrome.exe), PROCESS-PATH는 전체 경로에 매칭합니다. 이름이 겹치는 프로그램이 있으면 경로 쪽이 더 안전합니다.

규칙은 위에서 아래로 첫 매칭이 이깁니다. 앱 전용 그룹을 위에 두고, 나머지는 일반 MATCH로 넘기는 식으로 쌓습니다. 아래는 개념 예시이며, 실제 proxy-groups에 선언한 이름과 반드시 같아야 합니다.

rules:
  - PROCESS-NAME,steam.exe,GameJP
  - PROCESS-NAME,Telegram.exe,Proxy
  - MATCH,CatchAll

② macOS: 번들·프로세스 규칙과 한계

macOS는 앱이 .app 번들로 배포되고, 내부적으로는 여러 보조 프로세스가 뜰 수 있습니다. Meta 계열에서 제공하는 프로세스·경로류 규칙을 쓸 때는 실제로 패킷을 내는 바이너리가 무엇인지 확인해야 합니다. 단일 「앱 이름」만으로 모든 트래픽이 한 규칙에 걸린다고 가정하면 어긋날 수 있습니다.

불확실하면 도메인 규칙으로 서비스 단위를 나누는 편이 디버깅이 쉽습니다. 예를 들어 특정 개발 도구가 접속하는 CDN·API 호스트만 DOMAIN-SUFFIX로 묶어 별도 그룹으로 보내는 방식입니다.

③ Android: 패키지 이름과 클라이언트 기능

Android에서는 앱이 패키지 이름(예: com.discord)으로 식별됩니다. Clash for Android 계열에서 앱별 프록시·분할 터널을 지원하면, UI에서 앱을 지정하고 그에 대응하는 정책을 쓰기도 합니다. 코어 YAML만으로 통일하고 싶다면, 빌드가 PACKAGE-NAME류 규칙을 지원하는지 문서를 확인합니다.

게임·동영상 앱은 백그라운드에서 추가 도메인을 열기도 하므로, 「앱만 골랐는데 일부 요청이 직접 나간다」는 현상이 나오면 해당 서비스의 도메인 규칙을 보강하는 것이 일반적인 다음 단계입니다.

④ 도메인·IP로 「서비스 단위」 분류하기

앱 식별이 어렵거나 규칙이 불안정할 때는 목적지로 나눕니다. DOMAIN, DOMAIN-SUFFIX, DOMAIN-KEYWORD는 가장 많이 쓰이고, 지역 잠금이 있는 스트리밍은 공개 RULE-SET이나 자체 목록을 rule-providers로 불러옵니다. GEOIP는 국가 단위로 국내 트래픽을 DIRECT로 보낼 때 편합니다.

한 줄의 규칙은 하나의 대상 그룹 이름만 가리킵니다. 그 이름은 proxy-groups에 존재해야 하며, 그 안에 미국 전용 노드만 넣어 두면 「그 도메인은 미국 출구」가 됩니다. Netflix만 미국, 나머지는 일반 프록시 같은 패턴이 여기에 해당합니다.

rules:
  - DOMAIN-SUFFIX,netflix.com,StreamingUS
  - DOMAIN-SUFFIX,nflxvideo.net,StreamingUS
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

⑤ proxy-groups에 「용도별 진입점」을 만들기

규칙에서 StreamingUS, GameJP, Proxy처럼 부르는 이름은 모두 proxy-groups에 정의된 그룹이어야 합니다. 용도별로 select 그룹을 여러 개 두면, UI에서 「스트리밍만 미국 노드 고정」「게임만 도쿄 풀」처럼 서로 다른 출구를 동시에 유지하기 쉽습니다.

이름을 바꿀 때는 rules 전체에서 같은 문자열을 함께 고쳐야 합니다. 한 글자라도 다르면 조용히 기본 MATCH나 엉뚱한 그룹으로 빠집니다. 중첩 그룹(한 그룹의 멤버가 다른 그룹)을 쓰면 표면 규칙은 짧게 유지할 수 있다는 점은 프록시 그룹 가이드에 자세히 나와 있습니다.

⑥ RULE-SET과 rule-providers로 규칙을 모듈화

수백 줄의 DOMAIN 규칙을 본문에 직접 쓰기보다, 원격 규칙 세트를 불러오는 방식이 유지 보수에 유리합니다. Mihomo·Clash Meta에서는 rule-providers로 URL·경로를 지정하고, rules에서는 RULE-SET 한 줄로 연결합니다. 공개 목록은 서비스 도메인 변경에 따라 업데이트되므로, provider의 interval을 적절히 두고 가끔 로그를 확인합니다.

정책 충돌이 나면 규칙 순서가 원인인 경우가 많습니다. 더 구체적인 규칙을 위에, 넓은 MATCH는 맨 아래에 두는 패턴을 지키세요.

⑦ TUN·시스템 프록시와의 관계

프로세스 기반 규칙은 코어가 해당 연결의 프로세스 정보를 볼 수 있을 때 의미가 있습니다. TUN 모드에서는 전체 트래픽이 더 일관되게 코어를 지나가는 경우가 많아, 「앱별」 기대에 가깝게 맞출 여지가 생깁니다. 반면 일부 앱은 프록시를 우회하거나 자체 인증서·핀닝을 써서 예외가 생기기도 합니다.

DNS가 클라이언트 밖에서 먼저 풀리면 규칙 매칭 전에 이미 다른 경로로 나갈 수 있으므로, 이상이 있으면 DNS 설정과 fake-ip·redir-host 같은 옵션을 TUN 모드 심화 글과 함께 점검하는 것이 좋습니다.

자주 하는 실수

• 그룹 이름 불일치: 규칙에는 US인데 proxy-groups에는 USA만 있으면 매칭 실패나 예기치 않은 폴백이 납니다.
• 지원하지 않는 규칙 타입: Premium 전용·Meta 전용 문법이 섞이면 파서 오류가 나거나 줄이 무시됩니다. 쓰는 코어 문서를 기준으로 맞춥니다.
• 순서 착각: 위에서 아래로 첫 매칭이므로, 넓은 DOMAIN-KEYWORD가 먼저 나오면 뒤의 세부 규칙이 영원히 안 걸립니다.
• 구독 덮어쓰기: 원격 프로필을 가져올 때마다 수동으로 넣은 rules가 사라지면, 클라이언트의 머지·패치 기능으로 고정 구간을 보호합니다.

검증 절차

설정을 바꾼 뒤에는 대표 앱을 실행하고, 로그나 연결 패널에서 어느 규칙 줄·어느 그룹으로 나갔는지 확인합니다. IP 확인 사이트는 브라우저 탭 단위로 출구가 갈리므로, 문제가 되는 앱에서 직접 테스트하는 것이 좋습니다.

백업된 YAML을 Git 등에 두면, 구독 갱신 후 diff로 「내가 넣은 사용자 정의 구간」만 재적용하기도 쉽습니다.

자주 묻는 질문

일회성 VPN과 달리 Clash 계열은 규칙을 코드처럼 쌓아 두고 매일 같은 정책을 재사용할 수 있다는 점이 큽니다. 클라이언트를 최신으로 유지하고 프로필을 안전하게 합치려면 Clash 다운로드 페이지에서 배포 경로를 통일해 두는 것도 실수를 줄이는 방법입니다. → Clash를 무료로 받아 직접 분류 규칙을 적용해 보세요.