Windows에서 Clash Meta(Mihomo) PROCESS-NAME으로 프로세스별 분류: YAML 규칙과 클라이언트 설정 (2026)

① 왜 도메인 규칙만으로는 「exe만 따로」가 어렵나

대부분의 구독 프로필은 DOMAIN·GEOIP·RULE-SET으로 트래픽을 나눕니다. 같은 웹사이트를 크롬과 특정 게임 내장 브라우저가 동시에 열어도, 코어가 보는 건 결국 목적지 호스트와 IP입니다. 그래서 「이 프로그램에서 나가는 연결만」을 한 줄에 묶으려면 연결을 만든 프로세스를 규칙에 올려야 합니다. Mihomo(Clash Meta)는 Windows에서 이 메타데이터를 활용할 수 있도록 PROCESS-NAME 계열 규칙을 제공합니다.

다만 모든 연결에 프로세스 이름이 붙는 것은 아닙니다. 커널이 연결을 가로채는 방식(TUN 모드, 또는 이에 준하는 경로)과 클라이언트 설정에 따라 로그에 프로세스 필드가 비어 있는 경우가 있습니다. 그래서 규칙을 넣기 전에 Clash Verge Rev 첫 설정에서 시스템 프록시만 켠 상태와 TUN을 켠 상태의 차이를 먼저 짚는 편이 디버깅이 빠릅니다.

② PROCESS-NAME과 PROCESS-PATH 문법

rules 배열 한 줄은 보통 유형,패턴,대상프록시그룹 형태입니다. 프로세스 규칙에서 자주 쓰는 유형은 다음과 같습니다.

• PROCESS-NAME — 실행 파일 이름만 비교합니다. 예: chrome.exe, steam.exe. 같은 이름의 다른 경로 프로그램과 충돌할 수 있습니다.
• PROCESS-PATH — 전체 경로에 매칭합니다. C:\Program Files\...처럼 공백·한글 경로가 있으면 클라이언트·코어 버전에 따라 이스케이프 규칙을 확인하세요.

세 번째 필드는 반드시 proxy-groups에 실제로 선언된 이름과 같아야 합니다. 오타가 나면 코어가 설정을 거부하거나, 해당 줄이 무시되어 아래쪽 MATCH로만 떨어집니다.

# Conceptual example — replace group names with yours
proxy-groups:
  - name: GameJP
    type: select
    proxies:
      - DIRECT
      - your-japan-node

rules:
  - PROCESS-NAME,SomeGame.exe,GameJP
  - PROCESS-NAME,Telegram.exe,Proxy
  - MATCH,DIRECT

③ 규칙 순서: 위에서 첫 매칭이 이긴다

Clash 규칙 엔진은 리스트를 위에서 아래로 훑고, 처음 맞는 한 줄만 적용합니다. 그래서 PROCESS-NAME으로 특정 게임만 분리하려면 해당 줄을 GEOIP나 넓은 RULE-SET보다 위에 두는 경우가 많습니다. 반대로 맨 위에 MATCH,Proxy만 두면 그 아래 프로세스 규칙은 실행되지 않습니다.

구독 제공자의 규칙 묶음을 그대로 쓰면서 맨 아래에만 사용자 규칙을 덧붙이는 방식은, 프로세스 규칙이 이미 위쪽 일반 규칙에 걸려 버려 먹히지 않는다는 신고가 잦습니다. 사용자 정의 규칙에서 말한 것처럼, 클라이언트가 제공하는「규칙 prepend / 사용자 규칙 우선」옵션을 켜거나, 프로필 편집기에서 rules 배열 순서를 직접 확인하세요.

④ 게임·런처: 어떤 exe에 규칙을 걸지

Steam처럼 런처와 본페 스토어 트래픽이 다른 프로세스로 나뉘는 경우가 많습니다. 업데이트·친구 목록·실제 게임 실행 파일이 각각 다른 .exe일 수 있으므로, 「연결이 안 된다」면 작업 관리자에서 해당 순간에 튀는 프로세스 이름을 확인합니다. 플랫폼별 도메인 위주로 묶는 접근은 Steam·Epic 분류 글과 함께 보면, 프로세스 규칙과 DOMAIN 규칙을 역할 분담하기 좋습니다.

프로세스 규칙은 「그 프로그램이 여는 모든 호스트」를 따라가므로, 게임 안티치트·클라우드 저장 서버까지 같은 노드로 묶일 수 있습니다. 출구를 바꿨더니 로그인만 실패한다면, 해당 호스트만 DIRECT로 빼는 식의 도메인 예외가 추가로 필요할 수 있습니다.

⑤ 시스템 프록시만으로는 부족할 때와 TUN

시스템 프록시를 켠 상태에서는 브라우저처럼 프록시 설정을 따르는 앱 위주로 트래픽이 코어에 들어옵니다. 반면 일부 게임·데스크톱 프로그램은 시스템 프록시를 무시하고 직접 나갑니다. 이때 네트워크 스택 더 아래에서 가로채는 TUN 모드를 쓰면 프로세스 정보가 규칙 엔진까지 더 잘 전달되는 경우가 많습니다. 다만 TUN은 다른 VPN·가상화 소프트와 충돌할 수 있으니 TUN 모드 심화의 주의점도 함께 읽는 것이 안전합니다.

⑥ Microsoft Store·UWP와의 구분

UWP·스토어 앱은 로컬 프록시(127.0.0.1) 접근이나 샌드박스 정책 때문에 「프록시가 안 먹는다」로 보일 수 있습니다. 이건 PROCESS-NAME 문제라기보다 Loopback 격리나 패키지 정책 문제에 가깝습니다. 해당 증상은 Windows 11 UWP·Loopback 글의 순서를 먼저 밟고, 연결이 코어에 들어온 뒤에야 프로세스·도메인 규칙을 조정하는 편이 좋습니다.

⑦ 클라이언트(Clash Verge Rev)에서의 실무 흐름

대표적인 흐름은 (1) 프로필 YAML을 연다 → (2) rules에 PROCESS-NAME 줄을 추가한다 → (3) 세 번째 필드의 그룹 이름이 proxy-groups와 일치하는지 확인한다 → (4) 저장 후 코어를 재시작하거나 프로필을 다시 적용한다 → (5) 연결 로그에서 해당 연결에 어떤 규칙이 적중했는지 본다 — 입니다. 편집기에서 문법 오류가 있으면 적용 단계에서 거부되므로, 변경 후에는 반드시 로그 한 줄이라도 확인하세요.

스니핑(sniffing) 옵션이 켜져 있으면 일부 사이트에서 이상 동작하는 사례가 있어, 예외 규칙이 필요할 때는 sniffing 예외 글과 연결해 생각하면 원인 분리가 쉽습니다.

⑧ 정리

Windows에서 exe 단위로 프록시를 나누려면, Clash Meta·Mihomo의 PROCESS-NAME·PROCESS-PATH와 규칙 순서, 그리고 TUN·시스템 프록시 선택을 한 세트로 다뤄야 합니다. 도메인만으로 덮기 어려운 게임·메신저·개발 도구에 특히 유용하고, 반대로 웹사이트 단위 분류는 여전히 DOMAIN 쪽이 안정적인 경우가 많습니다.

설치 패키지는 릴리스 페이지만 보다가 버전이 엇갈리기 쉽습니다. 먼저 입문 튜토리얼로 흐름을 잡고, 클라이언트는 공식 다운로드 페이지에서 현재 OS에 맞는 빌드를 받는 편이 안전합니다. 규칙형 프록시와 일괄 터널형 VPN의 차이는 Clash와 VPN 비교에서도 짚었습니다. 준비가 되었다면 → Clash를 무료로 내려받고, PROCESS-NAME으로 원하는 exe만 골라 분류해 보세요.