1 왜 «TUN인데도» PROCESS-NAME이 엇나갈까
사용자 입장에서는 TUN만 켜면 모든 로컬 트래픽이 곧바로 Clash Meta 규칙 엔진에 들어온다고 느끼기 쉽습니다. 실제로는 커널에서 가상 인터페이스로 들어온 뒤에도, PROCESS-NAME,chrome.exe,PROXY 같은 규칙을 평가하려면 «이 세션을 연 실행 파일이 무엇인가»가 코어에 전달되어야 합니다. OS별로 프로세스 조회 API, 보안 정책, 스택(gVisor·system·mixed)에 따라 그 정보가 비어 있거나 지연되면, 표면적으로는 같은 YAML인데도 이전과 다른 정책이 선택되는 경험이 납니다. 그래서 «누가 프록시를 타는지»를 보려는 질문과 «왜 이 규칙이 안 먹지»라는 질문은 TUN 설정과 find-process-mode를 같이 봐야 풀리는 경우가 많습니다. 기초 분기만 다룬 Windows PROCESS-NAME 가이드와 달리, 여기서는 커널·코어 사이의 탐색 모드에 초점을 둡니다.
find-process-mode와 권한이 첫 번째 의심 대상입니다.
2 find-process-mode는 무엇을 바꾸나
Mihomo 프로필 최상위(또는 클라이언트가 주입하는 동일 위치)에 있는 find-process-mode는, 코어가 연결마다 프로세스 메타데이터를 얼마나 적극적으로 찾을지를 조절하는 설정입니다. 값에 따라 CPU 부하와 매칭 정확도의 트레이드오프가 달라지고, 특히 TUN 아래에서 동시에 많은 연결이 생길 때 체감이 커질 수 있습니다. 중요한 점은 이 옵션이 DOMAIN-SUFFIX만으로 설계된 정책에는 거의 영향을 주지 않지만, PROCESS-NAME·PROCESS-PATH·UID 기반 규칙처럼 로컬 프로세스 식별에 의존하는 규칙에는 직접적인 레버라는 것입니다. 즉 «프로세스 규칙 문법은 맞는데 결과가 이상하다»는 증상을 볼 때 YAML의 다른 부분보다 먼저 이 한 줄을 의심하는 것이 합리적입니다.
3 strict·always·off를 언제 고르나
문서화된 관행에 따르면 find-process-mode는 보통 세 가지 값으로 이해합니다. strict는 기본에 가깝게 쓰이며, 코어가 안전하다고 판단할 때만 프로세스 조회를 깊게 하려는 성향입니다.always는 가능한 한 프로세스 정보를 찾아 규칙 매칭에 반영하려는 쪽이라, 특정 게임 클라이언트·브라우저만 계속 빗나갈 때 비교 실험용으로 켜 보는 경우가 있습니다. 반면 off는 프로세스 탐색을 사실상 끄에 가깝게 두어, NAS·공유기처럼 프로세스 개념이 모호한 환경이나 프로세스 규칙을 아예 쓰지 않는 프로필에서 선택합니다. 실서비스 PC에서는 먼저 strict로 두고 재현한 뒤, 필요한 최소 기간만 always로 바꿔 차이를 로그에 남기는 방식이 디버깅에 유리합니다. off인 채로 PROCESS-NAME만 추가해 두면 «규칙이 있음에도 항상 다른 줄로 떨어진다»는 상태가 나올 수 있어, 모드를 바꿨다면 반드시 코어를 재시작하고 캐시된 연결을 한번 끊어 보세요.
4 TUN 스택·라우팅과의 연결 고리
TUN 블록의 stack 값은 패킷이 사용자 공간으로 올라오는 방식을 바꿉니다. system 스택은 플랫폼 네이티브 경로에 더 가깝고, gVisor 계열은 샌드박스된 네트워크 스택을 쓰는 대신 호환성 이슈가 trade-off가 됩니다. 어떤 조합이든 «코어가 연결을 받았다»는 사실과 «프로세스 FD가 무엇인가»는 별 문제라서, tun.auto-route·auto-detect-interface·strict-route 같은 옵션을 바꾼 직후에만 프로세스 매칭이 흔들리는지도 함께 보아야 합니다. 예를 들어 Windows에서 strict-route를 과하게 걸면 예상과 다른 인터페이스로 나가며 관찰되는 앱이 달라 보일 수 있어, TUN 기본 가이드에서 권장하는 순서로 먼저 네트워크 안정성을 확보한 뒤 프로세스 규칙을 얹는 편이 낫습니다. 리눅스 데스크톱에서는 systemd-resolved·스텁 DNS와 겹치는지도 라우팅 이슈와 동시에 생각해야 하며, DNS만 따로 다룬 stub DNS 글과 교차해서 읽으면 «TUN 켰더니 이상해졌다」 증상을 구분하기 쉽습니다.
5 Linux·Windows에서의 권한과 «볼 수 있는 프로세스」
리눅스에서 Mihomo를 일반 사용자로 실행하면, 보안상 다른 사용자 UID가 만든 소켓의 프로세스 정보를 전부 볼 수 없을 수 있습니다. capabilities로 CAP_NET_ADMIN 등 필요한 권한을 주거나(배포판·설치 방식마다 문구가 다릅니다), 테스트 단계에서만 루트로 올려 차이를 확인하는 방법이 있습니다. 컨테이너 안에서 돌릴 때는 호스트 PID 네임스페이스와의 관계 때문에 프로세스 이름이 항상 clash 등으로만 보일 수도 있어, 그 환경에서는 애초에 프로세스 규칙 대신 mark·cgroup·포트 기반 정책을 쓰는 편이 현실적입니다. Windows에서는 흔히 관리자 권한으로 클라이언트를 띄워 TUN 어댑터를 올리는데, 이때도 백신·WFP 필터가 프로세스 경로를 숨기거나 지연시키는 사례가 있으니 예외 정책을 점검해야 합니다. 즉 find-process-mode를 always로 바꿔도 권한이 막혀 있으면 소용이 없을 수 있습니다.
6 YAML에서 한 줄과 tun 블록을 같이 두기
아래는 개념 예시입니다. 실제 키 이름은 사용 중인 Clash Meta 버전과 GUI가 생성하는 템플릿을 우선하세요.
# profile root
mode: rule
find-process-mode: strict # try always when debugging PROCESS-NAME
tun:
enable: true
stack: mixed
auto-route: true
strict-route: false # set true only when you understand the side effects
dns:
enable: true
# ... align with your TUN DNS policy
rules:
- PROCESS-NAME,chrome.exe,BROWSER
- PROCESS-NAME,SomeGame.exe,GAME
- GEOIP,KR,DIRECT
- MATCH,PROXY
proxy-groups에 BROWSER·GAME이 실제로 정의돼 있어야 하며, 앞선 규칙이 먼저 소비되면 아래 줄은 실행되지 않습니다. 구독 URL만 주기적으로 갱신하는 방법은 interval·lazy 글과는 주제가 다르지만, 같은 프로필 안에서 규칙과 네트워크 블록이 서로 다른 파일에 쪼개져 있다면 최종 병합 결과에 이 줄이 들어왔는지도 확인하세요.
7 규칙 순서 때문에 생기는 가짜 «모드 오류」
사용자는 find-process-mode를 바꾼 뒤에도 증상이 같다고 느끼지만, 실제로는 앞선 GEOIP나 넓은 DOMAIN-KEYWORD가 이미 매칭을 끝낸 경우가 많습니다. 특히 «한국 IP는 DIRECT» 같은 규칙을 프로세스 규칙보다 위에 두면, 게임이 국내 서버에 붙을 때는 항상 DIRECT로 보이고 프로세스 줄은 실행되지 않습니다. 반대로 프로세스 규칙을 과도하게 앞에 세워 두면 시스템 업데이트·백그라운드 서비스까지 원치 않는 노드로 나가기도 합니다. UWP·Microsoft Store 앱은 실행 파일 표기가 직관과 다를 수 있어, UWP 루프백 글과 함께 실제 EXE를 잡아본 뒤 규칙을 써야 합니다. Sniffer가 필요한 경우 HTTPS 스니핑 설정과 혼동하지 말고, 도메인 축과 프로세스 축을 나누어 생각하면 디버깅이 빨라집니다.
8 로그·연결 UI로 «탐지 성공 여부」 확인하기
Mihomo 계열은 외부 컨트롤러와 연결 패널에서 선택된 정책과 체인을 보여 줍니다. 문제가 되는 앱만 켜 두고, 동시에 터미널에서 해당 실행 파일 이름을 다시 확인한 뒤 YAML의 대소문자와 비교하세요. 그다음 find-process-mode를 always로 올려 동일 시나리오를 재현해 보고, 로그에 프로세스 필드가 채워지는지를 비교하면 원인이 모드인지 규칙 선점인지 분리됩니다. 클라이언트별로 대시보드 연결은 Yacd·외부 컨트롤러 글의 패턴을 참고하면 됩니다. 기록이 남지 않는 환경이라면 임시로 로그 레벨을 올리되, 공유할 때 개인 정보가 섞이지 않도록 주의하세요.
9 짧게 다시 읽는 Q&A
Q. TUN만 켜면 자동으로 프로세스까지 보이나요?
A. TUN은 트래픽을 가져오는 역할이고, 프로세스 이름은 별도 조회 결과입니다. 모드와 권한이 맞지 않으면 빈 값이거나 엉뚱한 이름이 들어올 수 있습니다.
Q. 라우터에도 같은 YAML을 넣어도 되나요?
A. 프로세스 규칙 의미가 달라지므로 보통 find-process-mode: off 쪽과 DOMAIN 규칙 중심 설계가 맞습니다.
Q. Sniffer를 켜면 PROCESS-NAME이 고쳐지나요?
A. Sniffer는 주로 도메인 가시성을 복구합니다. 실행 파일 축 문제는 그대로입니다.
10 정리
Mihomo에서 TUN을 켠 뒤 PROCESS-NAME 기대가 어긋날 때는, 문법보다 먼저 find-process-mode와 OS 권한, 그리고 앞선 규칙 선점 여부를 확인하는 세 박자가 중요합니다. strict를 기본으로 두고 재현이 될 때만 always로 비교하면 위험을 줄이는데, 그래도 안 되면 실행 파일 이름 자체·UWP·컨테이너 환경을 의심하세요. YAML 한 줄이 규칙 전체의 체감을 바꿀 수 있다는 점에서, 이 설정은 구독 URL만큼 자주 바꿀 필요는 없지만 바꿀 때 영향 범위는 큽니다.
일부 상용 VPN이나 원클릭형 클라이언트는 GUI에서 세부 옵션을 숨기고, 프로세스 단위 분기는 아예 지원하지 않는 경우가 많습니다. 반면 Clash Verge Rev 같은 Mihomo 기반 클라이언트는 TUN과 규칙 파일을 그대로 드러내 주어 find-process-mode를 바꾸고 로그로 검증하기 수월합니다. 한 번 설정해 두면 «어떤 앱이 실제로 어떤 노드를 타는지」를 스스로 설명할 수 있어, 게임 지연과 업무 트래픽을 나누는 프로세스 매칭 구성에 특히 유리합니다. 출처가 분명한 패키지는 다운로드 허브에서 받고, 본문에서 다룬 옵션은 사용 중인 코어 버전 문서와 함께 대조하는 습관을 권합니다.
