Clash PROCESS-NAME 규칙 Windows 무반응? 권한·경로·Mihomo

1. 왜 «맞게 썼는데» 로그에 안 잡힐까

Clash·Mihomo 계열에서 PROCESS-NAME(또는 문서에 따라 PROCESS-NAME, 접두가 붙는 규칙 행)은 «이 연결이 어느 실행 파일에서 왔는가»를 엔진이 알 수 있을 때 의미가 있습니다. 브라우저·일부 데스크톱 앱은 도메인 규칙만으로도 정리되지만, 동일 .exe 이름이 여러 경로에 존재하거나, 실제 연결이 자식 프로세스·업데이터·백그라운드 모듈에서 나가는 경우 사용자가 규칙에 적은 이름과 코어가 관측한 이름이 어긋날 수 있습니다. Windows는 경로의 대소문자를 파일 시스템마다 다르게 보이게 할 수 있어, «트레이 아이콘으로 켠 프로그램이 항상 같은 경로의 같은 바이너리»라고 가정하면 오판이 납니다.

또 하나의 큰 그림은 프로세스 규칙만으로는 «앱 전체 트래픽»이 한 번에 귀속되지 않을 수 있다는 점입니다. 시스템 구성 요소·드라이버· 다른 VPN·가상 스위치와의 상호작용에 따라 연결이 코어에 도달하기 전에 이미 다른 테이블로 빠질 수 있습니다. 그럴 때는 TUN·라우팅·방화벽 점검 글과 증상을 나누어 보는 것이 좋습니다. 아래부터는 PROCESS-NAME이 아예 작동하지 않는 것처럼 보일 때의 현실적인 검사 순서입니다.

팁: GUI의 «규칙 미리보기»만 믿기보다 Mihomo 로그에서 해당 연결이 어떤 규칙에 걸렸는지·프로세스 필드에 무엇이 찍히는지를 먼저 확인하면, 경로 문제인지 순서 문제인지 빨리 갈립니다.

2. PROCESS-NAME이 성립하려면

문법을 맞춘 PROCESS-NAME,app.exe,GROUP 한 줄이 있다고 해서 항상 매칭되는 것은 아닙니다. Mihomo(구 Clash Meta) 계열 코어와 규칙 모드(RULE)를 쓰고 있어야 하며, 엔진이 해당 OS에서 프로세스 정보를 붙일 수 있는 경로(예: 윈도 자체의 연결 정보 조회)가 열려 있어야 합니다. 구버전 클라이언트·순정 Clash Premium과 Meta 계열의 기능 차이를 가정한 인터넷 글을 그대로 따라가면 «문법은 맞는데 코어가 그 규칙 타입을 처리하지 않는» 상황이 납니다.

또한 시스템 프록시만 켠 상태에서 일부 앱이 프록시 없이 직접 나가면, 코어 입장에서는 «프로세스 연결»을 붙이기 전에 이미 앱이 종단에 붙어 있어 분류가 의미 없어질 수 있습니다. 이때는 TUN이나 클라이언트가 제공하는 터널/리다이렉트를 켜 트래픽이 반드시 코어를 지나가게 한 뒤 PROCESS-NAME을 검증하는 편이 재현성이 높습니다. 입문 튜토리얼에서 프로필 적용·모드 전환 순서를 익혀 두면 실험 속도가 빨라집니다.

3. 실행 경로와 파일명: 무엇을 써야 할까

Windows에서 흔한 실수는 «작업 관리자에 보이는 이름»과 «규칙에 써야 할 문자열»을 동일하게 본다는 점입니다. 문서에 따라 app.exe만 허용하는 경우도 있고, C:\Program Files\Vendor\app.exe처럼 전체 경로를 요구하거나 와일드카드를 허용하는 변형도 있습니다. 버전을 올린 뒤 설치 경로가 Program Files와 AppData\Local로 갈라진 앱은 이름은 같아도 실제로 트래픽을 내는 경로가 사용자가 예상한 것과 다를 수 있습니다.

백슬래시·공백·권한 폴더

YAML 안에서 백슬래시를 이스케이프해야 하는지, 따옴표로 감싸야 하는지는 편집기·클라이언트의 «구독 병합 파서»에 따라 달라질 수 있습니다. 복사해 온 경로 끝의 공백·전각 기호·보이지 않는 문자도 규칙 불일치를 만듭니다. 관리자 권한이 필요한 디렉터리에 설치된 앱은 일반 사용자 세션에서 뜬 Clash 프로세스 관점에서 접근 경로 정보가 제한될 수 있다는 점도 간과하기 쉽습니다.

# Illustrative rules — keys may differ by Mihomo / client version
rules:
  - PROCESS-NAME,chrome.exe,PROXY-BROWSER
  - PROCESS-NAME,C:\Path\app.exe,PROXY-APP
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,PROXY-DEFAULT

위는 이해를 위한 스켈레톤입니다. 실제 프로젝트에서는 사용 중인 코어 문서의 규칙 키 이름·쉼표 규칙을 따르고, 한 행이 다른 상위 규칙에 의해 먹히지 않는지(다음 절) 함께 봐야 합니다.

4. 진짜로 트래픽을 내는 프로세스는 누구인가

Electron·브라우저 계열은 메인 창의 .exe가 아니라 헬퍼·GPU·렌더 프로세스에서 연결이 많이 나갑니다. 메신저·런처(Discord 등)도 음성·업데이트·보안 모듈별로 이름이 갈라질 수 있어, 사용자가 «앱 이름 하나」만 규칙에 넣으면 나머지 연결은 다른 프로세스 규칙이나 MATCH로 흘러갑니다. Steam의 경우 게임 실행 파일 단위로 나가는 트래픽이 steam.exe와 다를 수 있다는 점이 문서화되어 있습니다.

해결 전략은 (1) 문제가 되는 동작을 재현한 채 로그에서 실제로 찍힌 프로세스명·경로를 그대로 규칙에 옮기고, (2) 여전히 비면 그 연검이 UDP·TLS 핑거프린팅 단계 전에 다른 레이어에서 처리되는지 확인하는 순서입니다. «이론상 맞는 app.exe»보다 로그 한 줄이 신뢰도가 높습니다.

5. 권한(UAC)·서비스·다른 사용자 세션

관리자 권한으로만 설치된 애플리케이션이 높은 무결성으로 실행되면, 일반 권한으로 돌아가는 프록시 코어가 프로세스 메타데이터를 일관되게 읽지 못하는 환경이 보고되어 왔습니다. 반대로 Clash GUI만 «관리자로 실행»에 두고 테스트하는 방식도 다른 앱과의 조합에 따라 결과가 달라집니다. 한 PC에서 무엇을 관리자로 띄울지 통일하지 않으면 같은 YAML도 재현이 어렵습니다.

Windows 서비스로 등록된 업데이트·백그라운드 작업은 사용자가 클릭한 창의 .exe와 무관하게 나가는 경우가 있어 PROCESS-NAME만으로 «앱 전체를 한 그룹에» 묶기 어렵습니다. 이때는 도메인·IP 측 규칙과 병용하는 편이 현실적입니다. 회사 PC의 WDAC·보안 소프트웨어가 트래픽을 가로채면 진단 자체가 달라지므로, 개인 기기에서의 자가 점검을 전제로 서술했습니다.

주의: 직장·학교 등 정책상 프록시 사용이 금지된 네트워크에서는 기술적 가능 여부와 무관하게 준수해야 합니다.

6. 규칙 순서: DOMAIN·GEOIP가 먼저면 PROCESS는 영원히 안 보인다

RULE 모드에서는 위에서 아래로 첫 매칭이 승리합니다. 상단에 광범한 DOMAIN-KEYWORD·GEOIP·거대 구독 세트의 MATCH에 가까운 행이 있으면, 아래에 둔 PROCESS-NAME 줄은 «도달하지도 못한» 셈이 됩니다. 사용자는 «PROCESS를 넣었는데 왜 안 되지?»라고 느끼지만, 실제로는 도메인 규칙이 먼저 승리한 것입니다.

디버깅 시에는 (1) 문제 앱의 연결 대상 도메인이 무엇인지 로그로 확인하고, (2) 그 도메인을 잡아 가는 규칙이 어느 줄인지 찾아, (3) 프로세스 전용 줄을 그보다 위로 옮길지, 아니면 도메인 쪽을 더 쪼갤지 결정해야 합니다. 앱별로 출구를 완전히 갈라야 한다면 프로세스 조건이 우선해야 하는 트래픽이 무엇인지부터 정해야 합니다.

7. TUN·포워딩 없이 프로세스 정보만 기대할 때 생기는 일

일부 환경에서는 TUN 미사용·로컬 리다이렉트만으로도 충분하지만, 타깃 앱이 WFP·자체 스택으로 직접 나가면 코어에 연결 메타가 전달되지 않아 PROCESS-NAME이 비어 있거나 unknown에 가깝게 보일 수 있습니다. 이때는 TUN을 켠 뒤 같은 앱을 다시 시험해 «프로세스 필드가 채워지는지»를 비교하는 것이 빠른 A/B 테스트입니다. TUN을 켠 뒤 전체 단절이 나면 같은 글의 라우팅·DNS 절차로 되돌아가야 합니다.

UDP·QUIC 다량 사용 앱은 TCP만 잡히는 로그를 보고 잘못 판단하기 쉽습니다. 공식 문서·FAQ에서 코어 버전별 UDP 지원·스니퍼·로그 레벨을 확인한 뒤, 동일 시나리오를 반복 측정하는 편이 안전합니다.

8. GUI·포크마다 보이는 이름·적용 경로가 다르다

Clash Verge·Clash for Windows 등은 같은 Mihomo 코어를 쓰더라도 설정 파일 합성 방식·규칙 편집기·로그 뷰가 다릅니다. 한쪽에서 «저장»한 규칙이 실제 런타임 config.yaml의 몇 번째 줄에 들어갔는지 확인하지 않으면 순서 버그를 놓칩니다. 클라이언트 비교 글에서 프로필 경로·백업 습관을 정리해 두면 재발을 줄일 수 있습니다.

자동 구독이 주기적으로 덮어쓰는 rules 블록에 수동으로 끼워 넣은 PROCESS-NAME 줄이 갱신마다 사라지는 경우도 흔합니다. «어제 됐는데 오늘 안 된다»면 병합 결과가 바뀌었는지부터 의심하세요.

9. 증상별로 어디를 볼까

아래는 Windows·Clash·PROCESS-NAME을 함께 쓸 때 자주 나오는 패턴과 점검 초점을 압축한 표입니다.

증상	먼저 의심할 것	조치 방향
로그에 프로세스가 비어 있거나 unknown	TUN 미적용·앱이 코어를 우회	TUN/리다이렉트 켜고 재측정, 라우팅 글 점검
도메인 규칙엔 걸리는데 PROCESS는 무시되는 느낌	RULE 순서상 DOMAIN이 상단	PROCESS 줄을 상향·도메인 세트 재구성
같은 app.exe인데 출구만 다름	실제 경로가 여러 개·자식 프로세스	로그의 전체 경로·자식 이름을 규칙에 반영
관리자 앱만 이상하게 매칭	UAC·무결성·권한 불일치	실행 높이 맞추기·경로별 규칙 분리 검토
구독 갱신 후만 규칙이 풀림	머지 시 수동 줄 유실	정적 rule 파일 분리·병합 순서 고정

비슷한 맥락의 앱별 실전은 Steam·Discord 문서와 겹치지 않도록, 본 글에서는 PROCESS-NAME 자체의 불능 요인에 초점을 맞겼습니다. 여전히 막히면 로그 원문 한 블록(민감 정보 가림)만으로도 규칙 엔진이 무엇을 보고 있는지 추적하기 쉬워집니다.

10. 맺음말

PROCESS-NAME은 «앱 한 줄이면 끝»이라기보다, Windows에서의 실행 경로·권한·규칙 순서·코어가 트래픽을 받는 경로(TUN 여부)까지 맞았을 때 비로소 안정적으로 쓰이는 레이어입니다. 튜토리얼의 예제 .exe를 그대로 복사했을 때 안 되면, 문자 하나가 아니라 위 조합을 의심하는 편이 빠르게 원인을 좁힙니다. 다른 종류 도구보다 규칙 엔진·노드를 한눈에 비교하기 쉬운 클라이언트를 고르면 재현과 공유 모두 편합니다.

설치 프로그램은 GitHub 릴리스 페이지가 아니라 우선 이 사이트의 안내를 따르는 것이 혼선이 적습니다. 오픈 소스 저장소는 빌드·이슈·기여 확인용으로 두고, 패키지는 다운로드 페이지에서 받는 흐름을 권장합니다.

→ Clash를 무료로 내려받아 PROCESS-NAME·규칙 순서·TUN을 본인 환경에 맞게 다시 맞춰 보세요