Clash Meta PROCESS-NAME 프로세스 분류 (2026)

왜 프로세스 기준 분류가 필요한가

대부분의 사용자는 DOMAIN·GEOSITE·RULE-SET으로 “사이트 단위” 분류에 익숙합니다. 그러나 실제 운영에서는 다음과 같은 요구가 자주 겹칩니다. 첫째, 브라우저만 프록시하고 IDE·메신저·백업 클라이언트는 직접 연결하고 싶다. 둘째, 동일한 호스트를 쓰는 앱이 여럿인데 그중 일부만 우회하고 싶다. 셋째, 앱이 WinINet이나 macOS의 시스템 프록시 설정을 따르지 않아 시스템 프록시 모드만으로는 도저히 잡히지 않는다. 이때 PROCESS-NAME은 “누가 보냈는가”라는 한 단계 위의 단서를 규칙 엔진에 넘겨 줍니다. 즉 목적지가 아니라 발신 주체를 기준으로 정책 그룹을 고르는 방식입니다.

다만 이 방식은 만능이 아닙니다. 샌드박스된 앱·컨테이너 내부·일부 보안 소프트웨어가 프로세스 식별을 가리면 기대와 다르게 동작할 수 있습니다. 그래도 데스크톱 게임·브라우저·전용 다운로더처럼 실행 파일이 명확한 프로그램에는 여전히 가장 빠른 해결책 중 하나입니다.

1전제: Meta 코어와 TUN(또는 동등한 데이터 플레인)

PROCESS-NAME이 의미 있으려면, 커널이나 드라이버·네트워크 확장 쪽에서 연결에 프로세스 메타데이터를 붙여 줄 수 있어야 합니다. 실무에서는 TUN 모드나 클라이언트가 제공하는 “전역 캡처” 경로를 켠 상태에서 쓰는 경우가 대부분입니다. 시스템 프록시만 켠 채로 일부 앱이 직접 나가면, 코어 입장에서는 “어느 프로세스인지”를 알기 어렵고 규칙도 빗나갑니다. 따라서 이 글의 예시를 따라 하기 전에 TUN 튜토리얼에서 OS별 활성화·권한·헬퍼 설치까지 마쳤는지 먼저 확인하세요.

DNS 쪽이 어긋나면 규칙이 맞아도 체감만 이상해질 수 있습니다. FakeIP·스니퍼·업스트림 리졸버를 바꾸는 중이라면 Meta 코어 DNS 유출 방지 가이드의 점검 순서를 함께 적용하는 것이 안전합니다. 프로세스 규칙은 “어느 노드로 보낼지”를 정할 뿐, 이름 해석이 엇나가면 여전히 연결이 실패합니다.

주의: PROCESS-NAME만 추가하고 TUN을 끈 채로 “왜 안 맞지?”라고 하면 원인은 규칙이 아니라 데이터 경로인 경우가 많습니다. 먼저 트래픽이 코어를 실제로 통과하는지부터 확인하세요.

2규칙 문법: PROCESS-NAME 한 줄의 구조

일반적인 형태는 다음과 같습니다. 타입 이름은 대문자와 하이픈을 그대로 쓰는 것이 안전합니다.

# Pattern: PROCESS-NAME,<process identifier>,<policy or proxy group>
- PROCESS-NAME,chrome.exe,PROXY
- PROCESS-NAME,Google Chrome,GLOBAL

세 번째 필드에는 DIRECT, REJECT, 사용자 정의 프록시 그룹 이름(예: PROXY, Auto) 등 프로필에 이미 정의된 출구를 적습니다. 존재하지 않는 그룹 이름을 쓰면 로드 시 오류가 나거나 해당 줄이 무시될 수 있으니, proxy-groups의 표기와 완전히 동일한지 대조하세요.

Clash Meta·Mihomo는 상위 호환을 유지하는 편이지만, 빌드·GUI 버전에 따라 일부 확장 규칙(예: 경로 기반 매칭) 지원 여부가 다를 수 있습니다. 이 글에서는 가장 이식성이 높은 PROCESS-NAME 중심으로 설명합니다. 경로까지 필요하면 사용 중인 코어 버전의 공식 문서에서 지원 키워드를 확인하세요.

3Windows에서 프로세스 이름 확인하기

Windows에서는 대개 실행 파일 이름이 식별자로 쓰입니다. 예를 들어 Google Chrome은 보통 chrome.exe, Microsoft Edge는 msedge.exe, Visual Studio Code는 Code.exe처럼 보입니다. 작업 관리자의 “세부 정보” 탭에서 이름 열을 확인하거나, PowerShell에서 해당 앱을 실행한 뒤 프로세스 목록을 조회해 실제 문자열을 복사하는 방식이 오타를 줄입니다.

대소문자는 환경에 따라 관대하게 보일 때도 있지만, 규칙 파일에는 작업 관리자에 보이는 표기와 동일하게 맞추는 것을 권장합니다. Chrome.exe와 chrome.exe를 혼동하면 디버깅이 길어집니다. 또한 일부 런처는 실제 네트워크를 쓰는 자식 프로세스가 따로 있으므로, 연결 로그에 찍힌 이름을 기준으로 규칙을 추가하는 편이 정확합니다.

Microsoft Store(UWP) 계열은 Loopback·패키지 격리 이슈와 겹치는 경우가 많습니다. 순수하게 프로세스 이름만으로 해결되지 않으면 UWP Loopback·시스템 프록시 점검 글과 병행하세요. Windows 설치·서비스 모드 가이드에서 클라이언트 권한을 정리한 뒤 적용하는 것도 좋습니다.

4macOS에서 프로세스 이름 확인하기

macOS에서는 메뉴 막대의 활성 상태 표시기나 활성 상태 표시기(구 Activity Monitor)에서 프로세스 이름을 확인합니다. Safari는 Safari, Chrome은 Google Chrome처럼 공백이 포함된 이름이 나오는 경우가 많습니다. YAML에 적을 때도 그대로 적어야 하며, 따옴표로 감싼 규칙 줄이 필요하지는 않습니다. 쉼표가 이름에 들어가는 특수한 경우가 아니라면 일반적인 한 줄 형식으로 충분합니다.

권한 측면에서는 네트워크 확장·시스템 확장이 허용되어 있어야 TUN 경로에서 프로세스 정보가 안정적으로 붙습니다. 시스템 프록시만으로는 동일한 증상이 반복될 수 있으니, macOS 시스템 프록시·키체인·Helper 글과 함께 “트래픽이 실제로 코어로 들어오는지”를 먼저 가르는 것이 좋습니다.

5규칙 순서: PROCESS-NAME을 어디에 둘까

Clash 계열은 rules 배열을 위에서 아래로 평가하고, 처음 맞는 한 줄에서 결정합니다. 따라서 PROCESS-NAME을 너무 아래에 두면, 이미 DOMAIN-SUFFIX 같은 일반 규칙에 걸려 버려 의도대로 동작하지 않습니다. 반대로 너무 위에만 두면, 디버깅용으로 넣은 좁은 예외가 전역을 덮어쓸 위험도 있습니다.

실무에서는 (1) 확실히 특정 앱만 다르게 보내고 싶은 소수의 PROCESS-NAME을 (2) 광범위한 지역·카테고리 RULE-SET보다 위쪽에 두되, (3) MATCH 직전에는 도메인 기반의 마지막 안전망을 두는 식으로 배치하는 경우가 많습니다. 팀 단위로 프로필을 공유한다면, 주석으로 블록을 나누어 “앱 예외” 구역을 고정해 두면 이후 유지보수가 쉬워집니다.

6복사해 쓸 수 있는 YAML 스케치

아래는 개념을 잡기 위한 최소 스케치입니다. 실제 프로필에는 이미 존재하는 proxies·proxy-groups·rules 앞부분과 합쳐 넣으세요. tun 블록과 OS별 스택 옵션은 사용 중인 클라이언트 문서를 따릅니다.

# Sketch only — merge into your real profile
mode: rule

tun:
  enable: true
  # stack: system/gvisor/mixed — follow your client docs

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - NODE-A
      - AUTO
  - name: AUTO
    type: url-test
    proxies: [NODE-A, NODE-B]
    url: "https://www.gstatic.com/generate_204"
    interval: 300

rules:
  # Browsers and a game client go through PROXY
  - PROCESS-NAME,chrome.exe,PROXY
  - PROCESS-NAME,msedge.exe,PROXY
  - PROCESS-NAME,Google Chrome,PROXY
  - PROCESS-NAME,SomeGame.exe,PROXY
  # Your normal DOMAIN / GEOIP / RULE-SET blocks follow...
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

화이트리스트 vs 블랙리스트: “이 앱들만 프록시”처럼 소수를 지정하고 나머지는 DIRECT에 가깝게 두는 편이, 실수로 전체 트래픽을 해외로 보내는 위험을 줄입니다. 반대로 “특정 업데이트 도구만 직결”처럼 예외만 DIRECT로 빼는 패턴도 흔합니다. 운영 정책에 맞게 한 가지 스타일로 통일하세요.

7검증: 연결 로그에서 프로세스 열 보기

설정을 저장한 뒤에는 추측하지 말고 연결 로그로 확인합니다. 대부분의 GUI는 실시간 연결 창에 규칙 이름·정책 그룹·체인을 보여 줍니다. 문제의 앱에서 실제로 트래픽을 발생시킨 다음, 해당 행에 기대한 PROCESS-NAME 줄이 적용됐는지, 아니면 여전히 DOMAIN 규칙에 먼저 걸렸는지를 봅니다. 한 번에 변수를 여러 개 바꾸지 말고, 규칙 한 블록·DNS 한 옵션씩 바꾸며 재현해 보세요.

터미널 도구를 쓰는 사용자는 external-controller API로 연결 목록을 조회하는 방법도 있습니다. 대시보드 연결은 Mihomo·Yacd 패널 가이드를 참고하면 브라우저에서 같은 정보를 빠르게 훑을 수 있습니다.

자주 있는 실수와 대응

프로세스와 실제 통신 주체 불일치: 런처는 launcher.exe인데 게임 본체는 game.exe만 네트워크를 쓰는 식이면, 규칙을 자식 쪽에 맞춰야 합니다.
경로를 이름에 섞고 싶은 욕구: 표준 PROCESS-NAME은 이름 중심입니다. 경로 단위가 꼭 필요하면 코어 버전별 확장 문법을 확인하세요.
VPN·가상화와의 중복: 다른 가상 어댑터가 먼저 잡아가면 TUN 체인이 꼬일 수 있습니다. 어댑터 우선순위·분할 터널링 설정을 함께 봅니다.
규칙만 늘리고 노드 품질은 그대로: 출구 RTT가 나쁘면 프로세스를 아무리 잘 나눠도 체감은 좋아지지 않습니다. url-test·수동 전환으로 품질을 병행하세요.

정리

Clash Meta·Mihomo에서 PROCESS-NAME은 “이 앱만 이렇게 보낸다”는 요구를 YAML 한 줄로 표현할 수 있는 강력한 도구입니다. 전제는 분명합니다. 트래픽이 코어의 TUN·동등 경로로 들어오고, Windows·macOS에서 실제 프로세스 표기를 정확히 알며, rules 배열에서 순서를 의도에 맞게 배치하는 것. 이 세 가지가 맞으면 브라우저만 우회·게임만 직결 같은 일상 시나리오가 훨씬 단순해집니다. 도메인 기반 글로벌 규칙과 프로세스 예외를 함께 쓰면, 시스템 프록시를 무시하는 앱도 비교적 예측 가능하게 다룰 수 있습니다.

다른 플랫폼과의 역할 분담으로, 서버나 컨테이너만 다루는 경우에는 Docker 배포 글·Linux TUN·systemd 글이 더 적합합니다. 이 글은 데스크톱 앱 단위 분류에 초점을 맞췄습니다.

설치 패키지는 릴리스 직링크보다 사이트의 다운로드 허브를 기준으로 고르는 편이 플랫폼·빌드 혼선이 적습니다. 오픈소스 본문·이슈 트래커는 신뢰 확인용으로 두고, 아래 링크에서 클라이언트를 받아 프로세스 규칙을 바로 시험해 보세요.

→ Clash 클라이언트를 무료로 내려받아, Meta 코어와 PROCESS-NAME 규칙으로 앱별 출구를 정리해 보세요

Clash Meta(Mihomo)에서 앱별로 나누기: PROCESS-NAME 규칙 단계별 가이드 (2026)