왜 BT·PT는 Clash 밖으로 빼는 사용자가 많을까요?
브라우저·메신저·개발 도구는 저지연·안정적인 출구 한 곳을 노드로 고르는 이점이 큽니다. 반면 토렌트 스웜은 동시에 수많은 피스·릴레이와 맞닿고, 업·다운 모두 대역을 크게 씁니다. 전역 프록시로 그대로 두면 상용 노드 대역을 빠르게 소모하거나, 노드 운영 정책상 비HTTP 트래픽·P2P이 제한되는 경우가 있습니다. 지연 측면에서도, 굳이 해외 회선을 한 번 더 거칠 필요가 없는 피스가 많으면 불필요한 RTT만 늘 수 있습니다.
PT(프라이빗 트래커) 환경에서는 트래커·시딩 규칙·포트 가시성까지 맞춰야 해서, «브라우저만 프록시·클라이언트는 직행»처럼 앱 단위로 경로를 나누는 요구가 흔합니다. 도메인 기반 규칙만으로는 같은 실행 파일에서 나가는 트래커 HTTPS와 피스 TCP/UDP를 일관되게 나누기 어렵고, RULE-SET 업데이트마다 순서가 밀리면 예외가 묻히기도 합니다. 그래서 Windows에서는 프로세스 이름 한 줄로 클라이언트 전체를 직행에 붙이는 방식이 가장 단순하고 재현성이 좋습니다.
전제: 코어·모드·Windows 스택
PROCESS-NAME은 Clash Premium·Meta(mihomo) 계열에서 쓰이는 규칙 유형입니다. 구독만 넣은 구형 클라이언트라면 메뉴에 규칙 편집이 없을 수 있으니, 프로필을 직접 편집할 수 있는지부터 확인하세요. 모드는 보통 규칙(Rule)에서 프로세스 규칙이 의미 있습니다. 글로벌에서 «모든 것을 한 노드»로내면, 예외 줄을 아무리 넣어도 UI 상으로는 헷갈릴 수 있으니 규칙 모드에서 매칭 로그를 볼 것을 권장합니다.
Windows에서는 시스템 프록시만 켠 상태와 TUN(가상 어댑터)을 켠 상태가 다릅니다. 일부 앱은 자체적으로 프록시를 따로 지정하고, 또 어떤 앱은 TUN 경로로만 잡힙니다. 증상이 «규칙을 넣었는데도 안 먹는다»면 TUN·시스템 프록시 점검에서 스택을 먼저 맞추고 나서 프로세스 규칙을 검증하는 순서가 덜 헛돕니다. WSL2·Docker Desktop처럼 별 네임스페이스가 있는 경우, 호스트의 qBittorrent와는 다른 프로세스 트리가 되므로 이 글의 Windows 규칙과는 별 문제입니다.
PROCESS-NAME 규칙 문법과 qBittorrent 기본 이름
가장 흔한 설치형 qBittorrent의 실행 파일 이름은 qbittorrent.exe입니다. 규칙 한 줄은 다음 형태로 씁니다.
rules: # Windows: send qBittorrent process traffic to DIRECT - PROCESS-NAME,qbittorrent.exe,DIRECT
세 번째 인자는 DIRECT 대신 정책 그룹 이름도 가능합니다. 예를 들어 «한국 전용 저지연 그룹»만 타게 하고 싶다면 해당 그룹명을 넣으면 됩니다. 다만 BT·PT를 완전 직행하려는 목적이라면 DIRECT가 가장 명확합니다. 프록시 그룹 안에 DIRECT를 포함한 select를 두고 그 그룹 이름을 쓰는 패턴도 있지만, 오타 시 기동 오류가 나기 쉬우니 초보 단계에서는 DIRECT 고정을 추천합니다.
일부 문서나 예제에서는 대문자 PROCESS-NAME을 쓰고, 프로세스 부분은 소문자 qbittorrent.exe를 씁니다. Windows에서 실행 파일 이름은 통상 대소문자를 구분하지 않는 비교가 되지만, 코어 버전·빌드에 따라 엄격히 구분되는 사례를 듣기도 하니 작업 관리자에 표시되는 이름과 동일하게 맞추는 습관이 안전합니다. 경로에 공백이 있는 설치 위치(예: C:\Program Files\...)는 흔하지만, PROCESS-NAME은 경로 전체가 아니라 실행 파일명 위주로 매칭하므로 «폴더 이름에 공백이 있어서 규칙에 공백을 넣어야 하나?»라는 오해에서 오는 설정 실수는 줄어듭니다. 반대로, 이름이 다른 포크 실행 파일(예: 테스트 빌드가 다른 exe 이름을 쓰는 경우)이라면 그 이름으로 줄을 하나 더 추가해야 합니다.
규칙 순서: 위에서 첫 매칭만 적용됩니다
Clash의 rules는 위에서 아래로 읽히며, 처음 걸린 한 줄만 적용됩니다. 그래서 구독에서 가져온 RULE-SET이나 GEOIP,CN,DIRECT 같은 넓은 줄이 앞에 있고, 그 안에 이미 «모든 TCP를 어떤 그룹으로»에 가까운 매칭이 들어 있으면 아래에 쓴 PROCESS-NAME은 영원히 도달하지 못합니다. 해결책은 두 가지 중 하나입니다. (1) PROCESS-NAME 줄을 그 RULE-SET보다 위로 올린다. (2) RULE-SET을 rule-providers로 쪼개고, no-resolve나 세분화된 순서를 재구성한다. 현실적으로는 (1)이 가장 빠릅니다.
맨 아래의 MATCH,PROXY-GROUP 같은 줄은 «나머지 전부»를 한 번에 흡수합니다. 따라서 PROCESS-NAME은 반드시 MATCH보다 위에 있어야 합니다. «브라우저만 프록시·나머지 직행»을 MATCH로 직행에 두었다면, qBittorrent는 이미 직행이므로 PROCESS-NAME은 중복이지만 명시적으로 안전장치가 됩니다. 반대로 MATCH가 프록시로 가게 되어 있으면, PROCESS-NAME을 그 위에 두지 않는 한 BT는 계속 노드를 탑니다.
같은 원리로 DOMAIN-SUFFIX로 특정 트래커만 프록시 같은 줄을 쓰는 경우, PROCESS-NAME(앱 전체 직행)과의 우선순위 충돌을 잘 봐야 합니다. «앱은 직행인데 트래커 HTTPS만 프록시»를 만들려면, 일반적으로는 트래커 도메인 규칙을 PROCESS-NAME보다 위에 두어 트래커 연결만 먼저 잡히게 설계합니다. 이때도 구독 세트가 트래커 호스트를 먼저 가로채는지 로그로 확인하세요.
TUN·시스템 프록시와의 조합
시스템 프록시만 사용하는 구성에서는, 프록시를 «알고 있는」앱만 Clash를 탑니다. qBittorrent는 기본적으로 시스템 프록시를 따르지 않는 경우가 많아, 오히려 «전역인데도 BT만 직행처럼 보인다»는 착시가 생기기도 합니다. TUN을 켜면 OS 레벨에서 트래픽이 가상 인터페이스로 들어가므로, Clash가 연결을 중간에서 보더라도 프로세스 정보를 규칙에 쓸 수 있는지는 사용 중인 코어·클라이언트 조합에 달려 있습니다. 증상이 맞지 않을 때는 연결 로그에 프로세스 이름이 찍히는지를 먼저 확인하는 것이 좋습니다.
한 PC에서 브라우저만 프록시를 원하면, 브라우저 확장·PAC·프로필별 프록시 등 앱 레벨 방법과 Clash 규칙을 역할 분담하는 경우가 많습니다. qBittorrent는 SOCKS5/HTTP 프록시 필드를 비워 두고 PROCESS-NAME으로 DIRECT를 보장하는 편이, «실수로 클라이언트 안에 프록시 주소를 넣어 이중으로 탐»하는 사고를 줄입니다. 이미 프록시를 넣어 둔 설정이 있다면 한 번 비우고 다시 측정해 보세요.
PT·트래커·포트: 직행만으로 끝나지 않는 경우
PROCESS-NAME으로 DIRECT를 주면 그 프로세스가 여는 대부분의 소켓에 같은 정책이 적용됩니다. 그러나 NAT·포트포워딩·방화벽은 별개입니다. 공유기 뒤에서 시딩하려면 UPnP나 수동 포트포워딩이 필요하고, Windows Defender 방화벽에서 qbittorrent.exe의 인바운드를 허용해야 할 수 있습니다. Windows Clash LAN 공유·방화벽 글에서 다룬 것처럼, «프록시만 맞추면 끝»이 아니라 OS·공유기 스택 전체를 봐야 하는 이유입니다.
일부 PT는 트래커 접속 IP나 클라이언트 보고 값을 엄격히 봅니다. 모든 아웃바운드를 해외 노드로내던 환경에서 갑자기 DIRECT로 바꾸면, 트래커가 보는 공인 IP가 달라져 세션·비율 통계에 영향이 갈 수 있습니다. 규칙을 바꾼 뒤에는 트래커 상태 아이콘과 사이트 규칙을 다시 확인하는 것이 좋습니다. 바인드 인터페이스 옵션을 쓰는 고급 사용자는, Clash TUN과 물리 NIC 중 무엇에 묶일지까지 함께 점검해야 합니다.
복붙용 최소 스니펫과 확장 패턴
아래는 개념 확인용 최소 예시입니다. 실제 프로필에는 LAN·DNS·GEOIP·구독 RULE-SET과 합쳐야 하며, 순서는 반드시 본인 환경에 맞게 조정하세요.
rules: # Put BEFORE broad RULE-SET / GEOIP / MATCH - PROCESS-NAME,qbittorrent.exe,DIRECT # Optional: other BT clients on Windows - PROCESS-NAME,Transmission-qt.exe,DIRECT # ... your subscription rulesets, then MATCH
여러 BT 클라이언트를 같이 쓴다면 실행 파일마다 한 줄씩 추가합니다. WebUI를 별도 프로세스로 띄우지 않는 한 대부분은 동일 qbittorrent.exe 안에서 처리됩니다. CLI 헬퍼가 별도 exe라면 그 이름도 추가해야 합니다.
Steam·Epic CDN 분기 글과 무엇이 다른가요?
Steam·Epic 스토어·CDN 분기는 호스트 이름(DOMAIN-SUFFIX)으로 «어디로 가는지»를 나누는 축이 분명합니다. 반면 BT 클라이언트는 피스 IP가 전 세계에 흩어지고, 같은 프로세스 안에서 트래커·메타데이터·피스 전송이 섞입니다. 그래서 «도메인 몇 줄»보다 프로세스 한 줄로 앱 전체를 직행하는 패턴이 더 잘 맞는 경우가 많습니다. 두 방식 모두 규칙 순서와 로그 대조라는 Clash의 공통 원리는 같습니다.
자주 묻는 질문
Windows에서 qBittorrent가 여전히 프록시 노드를 탈 때 무엇부터 보나요?
규칙 모드인지, PROCESS-NAME 줄이 GEOIP·DOMAIN-SUFFIX·MATCH보다 위에 있는지 확인하세요. TUN을 쓰는 경우 앱이 가상 스택을 타는지와 코어 로그에서 매칭된 규칙 이름을 대조하면 원인이 빨리 좁혀집니다.
설치 경로에 공백이 있어도 PROCESS-NAME은 어떻게 쓰나요?
PROCESS-NAME은 일반적으로 실행 파일 이름(예: qbittorrent.exe)만 비교합니다. 폴더 경로의 공백은 규칙 문자열에 넣지 않으며, 포터블이든 스토어형이든 프로세스 표시 이름이 같으면 동일 규칙으로 잡힙니다.
PT 트래커만 프록시를 타게 할 수 있나요?
트래커 도메인은 DOMAIN-SUFFIX 등으로 묶을 수 있지만, 피스·DHT·로컬 랜은 별 연결입니다. 대용량 스웜은 PROCESS-NAME으로 클라이언트 전체를 DIRECT로 두고, 트래커만 별도 규칙으로 프록시 그룹에 보내는 식으로 순서를 설계하는 경우가 많습니다.
PROCESS-NAME과 IP·ASN 규칙 중 무엇을 먼저 두어야 하나요?
Clash는 위에서 아래로 첫 매칭만 적용합니다. 특정 앱을 확실히 빼내려면 PROCESS-NAME을 넓은 GEOIP나 MATCH보다 위에 두는 것이 안전합니다. 구독 RULE-SET이 앞에서 흡수하면 아래 줄은 실행되지 않습니다.
마무리
2026년에도 Windows에서 Clash를 켠 채 BT·PT를 쓰는 분들은 대역·지연·약관·트래커 정책을 한꺼번에 맞춰야 합니다. PROCESS-NAME,qbittorrent.exe,DIRECT 한 줄은 단순해 보이지만, 규칙 순서와 TUN·시스템 프록시 스택, 클라이언트 내부 프록시 설정이 어긋나면 «안 먹는다»로 보입니다. 구독 RULE-SET을 정리하고 나서도 이상하면 코어 로그의 매칭 결과를 기준으로 다시 배치하세요. 코어와 UI 차이는 미호모 코어 업그레이드 가이드와 발행 노트를 함께 보는 편이 좋습니다.
장기적으로는 «한 줄 예외»를 메모해 두고, 구독이 바뀔 때마다 맨 위 사용자 규칙 블록만 재검증하는 루틴을 들이면 재발이 줄어듭니다.