Windows Clash Meta PROCESS-NAME 앱별 프록시

왜 PROCESS-NAME인가: 앱 단위(per-app)에 가깝게 나누기

Windows에서 Clash·Clash Meta(mihomo 코어)를 쓰다 보면, 「해외 게임 서버만 프록시」「특정 P2P·다운로드 클라이언트만 출국선」「나머지 업무·메신저는 직접 연결」처럼 프로그램 단위로 출구를 갈라 두고 싶은 경우가 많습니다. 도메인 규칙만으로는 같은 브라우저 안에서 탭마다 다르게 보낼 수 없고, 반대로 게임은 IP·UDP·런처 구조 때문에 DOMAIN-SUFFIX만으로는 번거롭기도 합니다. 이때 실행 파일 이름을 기준으로 매칭하는 PROCESS-NAME이 “앱별 프록시”에 가장 직관적으로 다가오는 도구가 됩니다. 전 트래픽을 한 번에 가져가는 TUN 모드 가이드나, Windows 전체 설치·시스템 프록시 튜토리얼이 다루는 기본 축과 겹치지만, 이 글은 rules 안에서 PROCESS-NAME을 어떻게 쓰는지에만 초점을 둡니다.

다만 PROCESS-NAME은 “마법”이 아닙니다. 코어가 해당 연결을 어떤 프로세스에서 왔는지 식별할 수 있어야 규칙이 먹고, Windows에선 보통 TUN(또는 클라이언트가 프로세스 메타데이터를 넘겨 주는 스택)과 함께 쓸 때 기대한 대로 동작하는 경우가 많습니다. 반대로 일부 앱은 자체 스택·서비스 프로세스로 나가 이름이 런처와 다르게 잡히기도 하니, 아래에서 이름 확인과 규칙 순서를 같이 다룹니다.

전제: Meta 코어·프로필 편집·전략 그룹 이름

이 글은 이미 구독을 불러와 proxy-groups(예: PROXY, 게임, SELECT)가 동작하는 프로필이 있다는 가정에서 출발합니다. 용어·문법 개요는 문서 개요와 규칙 분류 심화를 함께 보면 rules: 블록의 위치와 들여쓰기 실수를 줄이기 쉽습니다. PROCESS-NAME 줄의 마지막 필드는 반드시 존재하는 전략 그룹 이름과 같아야 하며, 오타 한 글자면 해당 줄이 무시되거나 시작 단계에서 오류가 납니다.

1단계: 작업 관리자로 정확한 exe 이름 확인

PROCESS-NAME에 넣는 값은 보통 파일 이름만입니다. 예: chrome.exe, steam.exe, SomeGame.exe. 전체 경로가 아니라 이름.exe 형태인 경우가 일반적입니다(구성·코어 버전에 따라 PROCESS-PATH류의 다른 키를 쓰는 템플릿도 있으나, 이 글에서는 가장 흔한 PROCESS-NAME만 다룹니다).

확인 절차는 단순합니다. 작업 관리자를 연 뒤 세부 정보 탭에서 이름 열을 보거나, 해당 프로그램 실행 중 PID를 찍고 속성에서 실행 파일명을 확인합니다. 스토어·런처형 게임은 실제 네트워크를 치는 프로세스가 게임.exe가 아니라 런처.exe·서비스 호스트 쪽일 수 있으니, 문제 재현 중에 이름을 다시 확인하는 습관이 필요합니다. 한 번 맞췄다고 끝이 아니라, 패치 후 바이너리 이름이 바뀌는 경우도 있습니다.

2단계: rules에 PROCESS-NAME 줄 쓰기

rules: 목록 안에 아래와 같이 한 줄을 추가합니다. 대소문자는 Windows 관행상 보통 신경 쓰지 않아도 되는 경우가 많지만, 클라이언트·코어 버전에 따라 다를 수 있으니 작업 관리자에 보이는 문자열을 그대로 맞추는 편이 안전합니다.

rules:
  - PROCESS-NAME,steam.exe,게임
  - PROCESS-NAME,SomeDownloader.exe,PROXY
  - MATCH,DIRECT

위 예에서 게임·PROXY는 사용자 프로필의 proxy-groups에 실제로 있는 이름이어야 합니다. 여러 exe를 같은 그룹으로 묶고 싶다면 줄을 여러 개 두면 됩니다. 게임 UDP·보이스 채팅까지 묶어 보려면 게임·UDP·TUN 분류 글과 전제가 겹치므로 같이 읽는 것이 좋습니다.

3단계: 규칙 순서—넓은 GEOIP·MATCH보다 위에 둘 것

Clash 규칙은 위에서 아래로 첫 매칭에서 멈추는 모델입니다. GEOIP,CN이나 넓은 DOMAIN-KEYWORD, 최종 MATCH가 PROCESS-NAME보다 위에 있으면, 의도한 exe도 먼저 그 줄에 걸려 버립니다. 따라서 앱 전용으로 쓰려면 PROCESS-NAME 블록을 충분히 앞쪽—보통은 자주 쓰는 지역·광고 차단 등 명시적 예외 바로 아래, 넓은 지리·최종 매치 직전—에 두는 패턴이 안전합니다. 세부 패턴은 규칙 심화의 순서 설명과 동일한 논리입니다.

4단계: TUN·스택과의 관계(왜 “켰는데 안 잡힌다”가 나오나)

PROCESS-NAME 매칭이 동작하려면 코어가 연결에 프로세스 정보를 붙일 수 있어야 합니다. Windows에서 시스템 프록시만 켜고 일부 앱이 자체 경로로 나가면, 기대한 exe와 로그에 찍히는 이름이 어긋날 수 있습니다. 그래서 실무에서는 TUN을 켜 전체 스택을 코어 쪽으로 모은 뒤, 그 위에 PROCESS-NAME으로 “이 앱만 이 그룹”을 얹는 식으로 맞추는 경우가 많습니다. TUN과 다른 VPN·보안 소프트의 가상 어댑터가 동시에 붙어 있으면 경로가 꼬이기도 하니, TUN 가이드의 전제(한 레이어씩)를 기억하는 것이 좋습니다.

HTTP/3·QUIC처럼 SNI 의존이 커지는 경로는 Sniffer·QUIC 글에서 다루는 설정과 맞물립니다. 프로세스는 맞는데 도메인 규칙이 빗나가는 느낌이면, 스니퍼·DNS·fake-ip 축을 같이 점검해야 합니다.

흔한 실수 체크리스트

런처 vs 본 클라이언트: 업데이트·안티치트·별도 *.exe가 실제 접속을 담당하는데, 규칙만 본 게임 파일에 걸어 둔 경우.
전략 그룹 오타: YAML은 살아 있는데 해당 줄만 무력화되는 패턴.
순서 역전: MATCH,PROXY가 위에 있어 PROCESS-NAME이 영원히 도달하지 못하는 경우.
대소문자·확장자: .EXE와 .exe 혼동, 또는 64비트·32비트 별 다른 바이너리.
브라우저만 분리가 목적이면 Chrome·Edge만 프록시 글처럼 애플리케이션 쪽 훅이 더 단순한 경우도 있습니다. PROCESS-NAME은 “어떤 Win32 프로세스의 소켓이든” 같은 그림에 잘 맞습니다.

5단계: 로그로 검증하는 습관

설정을 바꾼 뒤에는 클라이언트의 로그에서 해당 트래픽이 어떤 규칙에 걸렸는지, CHAIN이 기대한 전략 그룹인지 확인하는 것이 가장 빠릅니다. “규칙은 넣었는데 전부 DIRECT”라면 순서·프로세스 이름·TUN 전제 중 하나를 의심하면 됩니다. 원격 저장소·이슈 트래커는 오픈 소스 정보로 참고할 수 있지만, 설치 패키지는 공식 다운로드 페이지를 우선하는 편이 일관됩니다.

맺음: 요구가 명확할 때의 또 하나의 레버

Clash Meta의 PROCESS-NAME은 “이 프로그램만 이 출구”라는 사용자 언어에 가깝게 규칙을 쓰게 해 줍니다. Windows에서 게임·다운로더·특정 툴만 프록시에 태우고 나머지는 직접 연결로 남기려면, 이름 확인 → rules 배치 → TUN·순서·로그 검증의 네 박자를 한 세트로 기억해 두면 재시도 비용이 줄어듭니다. 같은 코어를 쓰더라도 GUI마다 메뉴 이름이 달라도, 결국은 YAML의 rules:에 같은 줄이 들어갑니다. 여러 시나리오를 오가는 사용자에게 Clash 계열은 규칙과 로그를 한 화면에서 다루기 쉬운 편이라, per-app에 가까운 요구가 생겼을 때 실험하기 좋은 선택지입니다.

→ Clash 공식 클라이언트 무료 다운로드 — 최신 mihomo 기반 클라이언트에서 프로필을 연 뒤, 위 순서대로 PROCESS-NAME 한 줄을 넣고 로그로 확인해 보시면, “전부 프록시” 없이도 원하는 exe만 골라 보내는 감각이 잡히기 쉽습니다.