도메인 분류만으로 부족한 이유

많은 사용자가 브라우저·특정 사이트만 프록시로 보내고 나머지는 DIRECT로 두고 싶어 합니다. 이때 흔한 방법은 DOMAIN-SUFFIX·RULE-SET으로 호스트를 나누는 것인데, Clash 규칙 분기 베스트 프랙티스에서 설명하듯 규칙은 위에서 아래로만 읽힙니다. 그런데 같은 도메인을 쓰는 프로그램이 둘 이상이거나, 게임·런처·업데이트 모듈이 고정 도메인 없이 IP·다양한 CDN으로만 붙는 경우에는 도메인만으로 “이 프로그램만”을 가르기 어렵습니다.

이럴 때 후보가 되는 것이 프로세스 이름 기반 규칙입니다. Clash Meta(Mihomo) 계열에서는 PROCESS-NAME으로, “이 연결을 낸 실행 파일이 무엇인가”를 조건에 넣을 수 있습니다. 전역 프록시를 켜지 않고도 특정 .exe만 원하는 정책 그룹으로 보내는 그림이 됩니다. 다만 커널·모드·OS에 따라 동작 전제가 달라지므로 아래 전제를 먼저 맞추는 것이 좋습니다.

Windows에서 PROCESS-NAME이 의미 있으려면

프로세스 이름을 알아내려면 트래픽이 Clash 쪽에서 연결 단위로 관찰 가능해야 합니다. Windows에서는 보통 TUN 모드 또는 동등하게 시스템이 애플리케이션 트래픽을 코어로 보내는 구성이 함께 가정됩니다. TUN이 무엇을 바꾸는지는 TUN 모드 심화에서 다루는 것과 같은 맥락으로 이해하면 됩니다. 반대로 프록시만 수동으로 넣은 브라우저처럼 일부 앱만 시스템 프록시를 타는 경우, 그 앱의 연결이 항상 “프로세스 정보와 함께” 코어에 들어온다고 가정하면 안 됩니다.

GUI 클라이언트(예: Verge 계열)로 TUN을 켜는 절차는 Windows 11에서 Clash Verge·TUN 정리를 참고해, 먼저 “트래픽이 코어에 들어온다”를 확인한 뒤 프로세스 규칙을 얹는 편이 디버깅이 빠릅니다.

ℹ 용어: 글에서 “Clash Meta”와 “Mihomo”는 같은 계열 코어를 가리키는 표기로 씁니다. 실제 키 이름·기능은 빌드와 클라이언트에 따라 조금씩 다를 수 있으니, UI에 표시된 “규칙 미리보기·연결 로그”를 기준으로 검증하세요.

PROCESS-NAME 규칙 문법과 예시

규칙 한 줄의 일반적인 형태는 다른 규칙과 같습니다: 유형, 인자, 정책(또는 정책 그룹 이름). 프로세스 기준은 대략 다음과 같은 식으로 씁니다(코어/문서 버전에 따라 대소문자·별칭을 확인하세요).

Illustrative rules (YAML fragment) 
rules:
  - PROCESS-NAME,steam.exe,PROXY-GAMES
  - PROCESS-NAME,SomeOfficeApp.exe,DIRECT
  - DOMAIN-SUFFIX,example.com,PROXY-WORK
  - GEOIP,CN,DIRECT
  - MATCH,FINAL

여기서 steam.exe처럼 적을 때는 Windows 작업 관리자에 보이는 실행 파일 이름에 가깝게 맞추는 것이 일반적입니다. 경로(C:\...)가 아니라 파일명 위주인 경우가 많습니다. 정확한 토큰은 사용 중인 코어 문서의 “Process” 관련 절을 한 번 확인하는 것이 안전합니다.

규칙 매칭 순서: 위에서 아래, 한 줄이라도 먼저면 종료

PROCESS-NAME도 다른 규칙과 똑같이 목록 상단이 우선입니다. 예를 들어 위 예시에서 steam.exe가 먼저 매칭되면, 아래에 DOMAIN-SUFFIX로 같은 연결을 바꾸려 해도 이미 끝난 뒤입니다. 그래서 “특정 exe만 예외”를 주고 싶다면, 그 예외를 넓은 DOMAIN 규칙보다 위에 두는 패턴이 흔합니다. 규칙 전체의 설계 감각은 규칙 분기 베스트 프랙티스와 같은 원리입니다.

정책 그룹 이름(PROXY-GAMES 등)은 구독·노드·자동 전환을 묶어 둔 정책 그룹·지연 측정 글에서 정리한 것과 연결됩니다. 게임용으로 지연을 재는 URL, 스트리밍용으로 고정 노드 같은 식으로 나눠 두면 프로세스 규칙은 “어느 묶음으로 보낼지”만 짧게 적을 수 있습니다.

실측: 작업 관리자로 exe 이름 맞추기

규칙에 넣을 문자열은 실제로 연결을 만든 프로세스와 같아야 합니다. Windows에서는 작업 관리자의 “세부 정보”에서 이름을 확인하거나, 클라이언트의 연결 목록에 표시되는 Process/프로세스 열을 참고합니다. 런처(launcher.exe)와 본체(game.exe)가 다르면, 프록시를 태우고 싶은 쪽 이름을 규칙에 넣어야 합니다. UWP·스토어 앱은 표시 이름과 실행 이미지가 헷갈리기 쉬우니, 연결 로그와 함께 맞추는 것이 좋습니다.

⚠ 주의: 안티치트·커널 드라이버가 있는 타이틀은 네트워크 경로가 일반적인 사용자 모드 exe와 다르게 보이거나, 정책 위반으로 간주될 수 있습니다. 게임 이용약관·지역 규정을 반드시 확인하세요.

연결 로그로 규칙 적용 확인하기

규칙을 추가한 뒤에는 “맞는 줄에 걸렸는지”를 추측하지 말고, 연결(Connections) 화면에서 해당 트래픽이 어떤 규칙 이름으로 분류됐는지 확인하는 것이 가장 빠릅니다. TLS·타임아웃 이슈와 로그를 같이 읽는 방법은 연결 로그·timeout·TLS 가이드를 참고하면 단계가 정리됩니다.

DNS가 개입하는 증상(해석은 됐는데 출구만 이상하다 등)이면 Clash Meta DNS(nameserver·fallback·fake-ip-filter) 설정과의 정합도 함께 봐야 합니다. 프로세스 규칙은 “어느 정책으로 보낼지”를 정하지만, 이름 해석이 먼저 흔들리면 도메인 기반 규칙과 상호작용이 꼬일 수 있습니다.

도메인 규칙·정책 그룹·게임(UDP)과 병행

실무에서는 PROCESS-NAME으로 “이 게임 실행 파일만 게임용 그룹”을 주고, 나머지 트래픽은 DOMAIN·GEOIP로 사이트별 분류하는 식으로 섞는 경우가 많습니다. 스팀·멀티플레이처럼 UDP·TUN 이슈가 함께 나오는 경우는 Steam·게임·UDP·TUN 분류 글의 순서와 겹쳐 점검하게 됩니다. Android에서는 같은 “앱 단위”를 패키지 이름으로 다루는데, 개념 비교는 Clash Meta Android 앱별 프록시를 참고하면 이해가 빨라집니다.

WSL·터미널·호스트 간 프록시만 따로 쓰는 경우에는 프로세스 규칙과 별개로, WSL2와 Windows 호스트 Clash처럼 “트래픽이 어디로 들어오나”를 먼저 맞추는 편이 안전합니다.

안 잡힐 때 체크리스트

  1. TUN/리다이렉트가 꺼짐 — 연결 자체가 코어 규칙 엔진에 안 들어오면 프로세스 이름도 비어 있거나 의미가 없습니다.
  2. 이름 불일치 — 대소문자·런처 vs 본체·32/64비트 다른 실행 파일을 혼동했는지 확인합니다.
  3. 더 위쪽 규칙에 선매칭 — 넓은 MATCH나 DOMAIN이 먼저 걸리면 아래 PROCESS-NAME은 실행되지 않습니다. 순서를 바꿉니다.
  4. 서비스·시스템 프로세스 — 사용자 exe가 아닌 다른 프로세스 이름으로 나가는 경우가 있습니다. 로그의 실제 이름을 기준으로 규칙을 수정합니다.

어떤 Clash 포크를 쓸지 고르는 일반 기준은 클라이언트 선택 가이드에 정리된 것처럼 업데이트·UI·로그를 함께 보는 것입니다. Meta 계열 기능을 쓸 계획이라면 코어와 GUI의 조합을 처음부터 맞춰 두면 재작성을 줄일 수 있습니다.

맺음말

Windows에서 전역 프록시 없이 특정 프로그램만 다른 노드로 보내고 싶다면, PROCESS-NAME은 도메인 분류와 상호 보완이 됩니다. 핵심은 세 가지입니다. 첫째, 트래픽이 규칙 엔진에 들어오도록 TUN 등 모드를 맞출 것. 둘째, 규칙 목록에서 위에서 아래 순서를 이해하고 좁은 예외를 위에 둘 것. 셋째, 추측 대신 연결 로그로 프로세스 문자열을 확인할 것입니다.

→ Clash를 무료로 다운로드하고, Windows용 클라이언트에서 Meta 계열 코어와 로그를 기준으로 프로세스 규칙을 검증해 보세요.