1 어떤 사용자에게 맞는지
이미 Clash Verge Rev 등으로 구독을 넣고 시스템 프록시 또는 TUN을 쓸 줄 아는 분을 대상으로 합니다. 목표는 단순히 «프록시를 켠다»가 아니라, 한 PC 안에서 동시에 게임 클라이언트는 게임용 노드, 웹 브라우저와 문서·메신저는 다른 노드(또는 직접 연결)로 보내 지연·안정성·정책을 나누는 것입니다. 이때 도메인 기반 규칙만으로는 같은 브라우저가 여러 용도로 쓰이거나, 게임이 잡히지 않는 전용 포트·IP를 쓰는 경우 한계가 드러날 수 있어, 실행 파일 단위인 PROCESS-NAME이 검색·실무에서 자주 쓰입니다. 클라이언트 설치가 필요하면 Windows 설치 가이드를 먼저 맞춘 뒤 이 글을 적용하는 편이 좋습니다.
2 도메인·IP 규칙만으로는 왜 부족한가
DOMAIN·DOMAIN-SUFFIX·GEOIP 등은 목적지가 무엇인지에 따라 분기합니다. 반면 «이 연결이 어느 프로그램에서 나왔는가」는 별개의 축입니다. 예를 들어 브라우저로 회사 웹앱과 개인 영상을 동시에 쓰면, 둘 다 비슷한 HTTPS 트래픽이라 도메인만으로는 업무용·개인용 노드를 깔끔히 나누기 어렵습니다. 게임은 특정 IP 대역으로만 붙거나, 런처와 실제 게임이 서로 다른 실행 파일로 나뉘어 한 가지 도메인 규칙에 묶이지 않는 경우도 있습니다. 그래서 «앱별로 출구를 다르게»가 요구될 때 프로세스명 기반 규칙이 도메인 규칙과 보완 관계로 쓰입니다. 이는 자동 선택 프록시 그룹을 써서 노드 품질을 관리하는 것과도 잘 맞습니다. 전역 MATCH만 바꿔 대응하는 것보다 규칙 설계가 길어지지만, 한번 맞춰 두면 매일 노드를 옮겨 다닐 필요가 줄어듭니다.
3 TUN(또는 동등한 트래픽 가로채기)이 전제인 이유
PROCESS-NAME이 동작하려면 코어가 해당 연결의 프로세스 정보를 알아야 합니다. 시스템 프록시만 켠 상태에서 일부 앱이 프록시를 우회하거나, 프록시 체인 상에서 프로세스 정보가 소실되면 규칙이 기대대로 매칭되지 않을 수 있습니다. Mihomo 환경에서는 보통 TUN 모드로 로컬 트래픽을 코어 쪽으로 끌어와 프로세스 단위 매칭을 안정적으로 쓰는 사례가 많습니다. TUN을 켤 때는 관리자 권한·가상 어댑터 충돌·스플릿 터널 등 환경 요소가 따르므로, TUN 모드 가이드의 기본 점검을 먼저 통과하는 것이 좋습니다. «프로세스 규칙을 넣었는데 전혀 안 먹는다»면, 우선 TUN이 실제로 해당 앱의 트래픽을 코어에 넘기고 있는지 로그로 확인하는 순서가 빠릅니다.
4 프록시 그룹을 먼저 나누기
PROCESS-NAME의 마지막 인자는 정책 이름으로, 보통 proxy-groups에 정의한 그룹을 가리킵니다. 예를 들어 GAME은 게임 전용 url-test나 낮은 지연 노드 풀, OFFICE는 업무용 안정 노드, PROXY는 일반 웹용 등으로 나눕니다. 그룹 안에 어떤 서버를 넣을지는 구독·노드 품질에 따라 다르고, 자동 선택·백업 그룹을 쓰는 방법은 url-test·Fallback 설명을 참고하면 됩니다. 중요한 점은 규칙에서 이름을 부를 그룹이 YAML에 실제로 존재해야 하며, 오타가 나면 매칭 시점에 의도와 다른 동작이 납니다.
5 Windows에서 프로세스 이름 확인하기
PROCESS-NAME에 넣는 값은 보통 실행 파일 이름입니다. 예: 크롬은 chrome.exe, 엣지는 msedge.exe, 일부 게임은 GameClient.exe처럼 표시됩니다. 작업 관리자에서 해당 앱을 선택한 뒤 세부 정보로 전환하면 이름을 볼 수 있고, PowerShell에서는 예를 들어 다음과 같이 확인할 수 있습니다.
# List process names containing "chrome"
Get-Process | Where-Object { $_.Name -like "*chrome*" } | Select-Object Name, Id
이름은 대소문자를 구분하는 환경이 있으므로, 작업 관리자에 보이는 표기와 동일하게 맞추는 것이 안전합니다. 런처와 실제 게임이 다른 EXE인 경우, 둘 다 규칙에 넣거나 우선순위를 정해야 합니다. 경로까지 구분해야 하면 코어가 지원하는 PROCESS-PATH 계열 규칙을 검토할 수 있습니다(클라이언트·코어 버전에 따라 문법이 다를 수 있어 공식 문서와 로그를 함께 확인하세요).
6 rules 예시: 게임·브라우저·나머지
아래는 이해를 돕기 위한 개념적 스니펫입니다. 실제 그룹 이름·노드 구성은 자신의 프로필에 맞게 바꿔야 합니다.
rules:
# Game client -> dedicated group (low latency pool)
- PROCESS-NAME,SomeGame.exe,GAME
- PROCESS-NAME,GameLauncher.exe,GAME
# Browsers -> general or split group
- PROCESS-NAME,chrome.exe,PROXY
- PROCESS-NAME,msedge.exe,PROXY
# Office (example)
- PROCESS-NAME,WINWORD.exe,OFFICE
- PROCESS-NAME,EXCEL.exe,OFFICE
# Then your usual DOMAIN / GEOIP / MATCH
- GEOIP,KR,DIRECT
- MATCH,PROXY
위에서 GAME·PROXY·OFFICE는 각각 proxy-groups에 정의된 이름이어야 합니다. 한국 IP 직접 연결 같은 GEOIP 규칙과 병행할 때는, 프로세스 규칙을 앞에 두어 «먼저 앱별로 보내고, 나머지는 지역·도메인 규칙으로 처리»하는 식으로 배치하는 경우가 많습니다. 정확한 순서는 정책 우선순위에 따라 달라지므로, 변경 후에는 반드시 연결 로그로 의도한 그룹이 선택되는지 확인하세요.
7 규칙 순서와 흔한 함정
Clash 계열 규칙은 위에서 아래로 첫 매칭이 적용되는 경우가 일반적입니다. 그래서 PROCESS-NAME을 GEOIP나 넓은 DOMAIN 규칙보다 앞에 둘지 뒤에 둘지에 따라 결과가 달라집니다. 예를 들어 특정 국가 IP를 전부 직접 연결로 보내는 규칙이 먼저 걸리면, 같은 IP로 붙는 게임 트래픽도 그쪽으로 가 버릴 수 있습니다. 반대로 프로세스 규칙이 너무 뒤에 있으면 이미 다른 규칙에 걸려 버립니다. 또한 UWP·스토어 앱은 실행 파일 표기가 기대와 다르거나, 백그라운드 서비스가 별도 프로세스인 경우가 있어 UWP·시스템 프록시 이슈와 겹칠 수 있습니다. 증상이 «프로세스 규칙만 안 먹는다»일 때는 프로세스명 오타·TUN 미적용·다른 규칙 선점을 순서대로 의심하면 됩니다.
8 Sniffer와의 역할 분담
HTTPS 등에서는 목적지가 TLS로 가려져 도메인을 알기 어려울 수 있어, Sniffer가 도메인 복원에 도움을 줍니다. 이는 도메인 기반 라우팅을 정확히 하기 위한 장치에 가깝고, PROCESS-NAME이 담당하는 앱 단위 분기와는 목적이 다릅니다. 둘 다 켜 두는 구성이 흔하며, 도메인이 필요한 규칙과 프로세스 규칙을 함께 쓸 때 전체 정책이 안정적으로 맞물립니다. Sniffer 설정의 개요는 Sniffer·HTTPS 라우팅 글을 참고하세요.
9 점검 체크리스트
proxy-groups에GAME등 규칙에서 쓰는 이름이 존재하는가- TUN(또는 환경에 맞는 가로채기)이 켜져 있고 해당 앱 트래픽이 코어에 보이는가
- 작업 관리자·PowerShell로 확인한 실행 파일명과 YAML이 일치하는가
PROCESS-NAME과GEOIP·DOMAIN의 순서가 의도와 맞는가- 변경 후 로그에서 선택된 정책·그룹이 기대와 같은가
10 정리
Windows에서 Mihomo를 쓸 때 PROCESS-NAME은 «같은 PC에서 게임은 게임 노드, 브라우저·오피스는 다른 노드»처럼 앱별 프록시를 구현하는 직관적인 수단입니다. 전제로는 보통 TUN과 잘 정의된 프록시 그룹, 그리고 규칙 순서에 대한 이해가 필요합니다. 도메인·IP 규칙과 병행하면 검색 의도에 맞는 프로세스 분류를 실사용 수준으로 끌어올릴 수 있습니다. 설치 패키지는 출처가 분명한 공식 다운로드 페이지를 우선하는 것이 안전합니다. 오픈 소스·업데이트 정보는 별도로 GitHub를 참고하되, 일상적인 클라이언트 설치는 사이트의 안내 경로를 따르는 편이 좋습니다.
규칙을 세밀하게 나눌수록 초기 설정 시간은 들지만, 이후에는 매번 글로벌 노드를 바꾸지 않아도 되어 게임과 업무를 동시에 쓰는 환경에서 체감이 큽니다. 다른 도구에 비해 Clash 계열은 로그와 YAML 가독성에서 여전히 강점이 있습니다.
