Clash 규칙 모드·전역 모드·직접 연결 모드 차이: 초보자 가이드

먼저 업무 앱의 연결 경로를 구분하세요

재택근무에서 Zoom 회의가 끊기거나 Slack 메시지 전송이 늦을 때는 노드를 바꾸기 전에 해당 앱의 트래픽이 Clash를 거치는지부터 확인해야 합니다. 시스템 프록시는 운영체제의 프록시 설정을 따르는 앱에 적용됩니다. 모든 프로그램이 이 설정을 따르는 것은 아니며, 특히 UDP 기반 미디어 연결이나 앱 내부에서 별도로 만든 연결은 시스템 프록시만으로 처리되지 않을 수 있습니다.

TUN은 가상 네트워크 인터페이스를 통해 더 많은 IP 트래픽을 Clash 코어에 전달할 수 있지만, 앱과 운영체제에 따라 동작이 다릅니다. TUN을 켰다고 모든 연결이 프록시 노드를 이용하는 것도 아닙니다. Rule 모드에서는 코어에 도달한 연결이 규칙과 정책 그룹에 따라 프록시, 직접 연결 또는 차단으로 처리됩니다. 따라서 앱의 트래픽 전달 여부, 일치한 규칙, 그룹에서 선택한 노드를 차례로 살펴보세요.

업무 프록시와 직접 연결 규칙을 안전하게 나누기

일반적으로 외부 업무 서비스는 사용할 수 있는 프록시 정책 그룹으로 보내고, 사내 시스템은 조직의 네트워크 정책에 맞춰 처리합니다. 직접 연결이 필요한 내부 도메인이나 사설 IP 대역이 분명하다면 해당 항목만 별도 규칙으로 지정하세요. 업무 서비스가 직접 연결되어야 하는지 프록시를 거쳐야 하는지는 계정 정책, 회사 보안 설정, 현재 네트워크에 따라 달라집니다. 편의만으로 일괄 결정하지 마세요.

다음은 이미 업무라는 정책 그룹이 구성되어 있다는 가정의 규칙 예시입니다. 실제 구독 설정에 그룹이 없다면 먼저 기존 그룹 이름을 확인하고, 아래 이름을 그 그룹에 맞게 바꿔야 합니다. 이 조각을 전체 설정 파일로 사용하거나 기존 rules 목록을 통째로 대체하지 마세요.

rules:
  - DOMAIN-SUFFIX,zoom.us,업무
  - DOMAIN-SUFFIX,zoom.com,업무
  - DOMAIN-SUFFIX,slack.com,업무
  - DOMAIN-SUFFIX,meet.google.com,업무
  - DOMAIN-SUFFIX,회사내부도메인.example,DIRECT
  - MATCH,기본정책

• DOMAIN-SUFFIX는 지정한 도메인과 그 하위 도메인에 적용됩니다. 예시의 zoom.us 규칙은 그 하위 도메인을 포함하지만, 모든 Zoom 연결이 이 도메인으로만 이루어진다는 뜻은 아닙니다.
• 회사 내부 도메인 예시는 설명용입니다. 실제 도메인으로 바꾸고, 직접 연결이 허용되는지 회사 담당자에게 확인하세요. 내부 서비스가 사설 IP로 연결된다면 현재 설정의 사설망 규칙과 충돌하지 않는지도 살펴봐야 합니다.
• 규칙은 위에서부터 확인되므로 구체적인 업무 도메인 규칙을 넓은 기본 규칙보다 앞에 두세요. MATCH는 나머지 연결을 처리하는 기본 규칙이므로 일반적으로 목록 끝에 둡니다.
• 정책 그룹 이름과 규칙의 대상은 실제 설정에 존재해야 합니다. 구독 업데이트가 규칙을 다시 생성할 수 있으므로 직접 편집을 유지하는 방법은 클라이언트의 Mixin 또는 설정 오버라이드 지원 여부를 확인하세요.

Clash for Windows는 더 이상 유지 관리되지 않습니다. 같은 화면을 사용하더라도 클라이언트와 내장 코어의 종류에 따라 지원 설정이 다를 수 있습니다. mihomo 전용 필드를 구형 코어에 그대로 추가하지 말고, 현재 실행 중인 코어와 로그에서 설정 파싱 결과를 확인하세요.

설정을 적용하고 Zoom·Slack 연결을 단계별로 확인하기

1. 현재 설정을 보존합니다. Profiles 화면에서 사용 중인 프로필을 확인하고, 가능하면 복사본을 저장합니다. 구독 원본을 직접 수정하는 방식은 업데이트 때 변경 사항이 사라질 수 있습니다.
2. 연결 방식과 모드를 확인합니다. 먼저 Rule 모드인지 확인하고, 시스템 프록시 또는 TUN 중 현재 어떤 방식으로 트래픽을 전달하는지 기록합니다. 업무용 VPN이나 다른 로컬 프록시 앱이 함께 실행 중이면 테스트할 때 하나씩 중지해 경로 충돌을 분리하세요.
3. 업무 그룹을 선택합니다. Proxies 화면에서 예시 규칙에 연결한 그룹을 열고, 사용 가능한 노드 하나를 선택합니다. 자동 선택 그룹을 쓴다면 그룹 안의 현재 노드와 지연 검사 결과도 살펴보세요. 지연 시간이 낮아도 Zoom 미디어 품질이나 회사 서비스 접속이 보장되지는 않습니다.
4. 규칙을 추가하고 다시 불러옵니다. 클라이언트가 지원하는 Mixin 또는 오버라이드 방식으로 도메인 규칙을 넣은 다음 설정을 적용합니다. 시작 오류가 나오면 새 필드나 잘못된 그룹 이름을 확인하고, 정상 작동했던 복사본으로 돌아갑니다.
5. 한 앱씩 시험합니다. 먼저 Slack 로그인과 메시지 전송을 확인하고, 다음으로 파일 업로드를 시험합니다. Zoom은 짧은 회의에 참여해 음성, 영상, 화면 공유를 각각 확인하세요. Meet도 회의 입장 화면뿐 아니라 실제 통화 품질을 살펴봅니다.
6. 로그에서 결과를 대조합니다. 테스트 시각에 발생한 연결을 찾아 도메인, 일치 규칙, 선택된 정책을 확인합니다. 해당 도메인이 로그에 없으면 연결이 다른 경로를 사용했거나 로그 수준·필터가 맞지 않을 수 있습니다. 로그에 규칙이 표시되어도 선택된 그룹에서 직접 연결을 골랐다면 최종 경로는 프록시가 아닐 수 있습니다.

시험 중에는 노드, 모드, 규칙을 한꺼번에 바꾸지 마세요. 변경을 하나씩 적용하면 문제가 규칙 매칭인지, 노드 품질인지, 트래픽 전달 방식인지 구별하기 쉽습니다. 회의가 시작된 뒤 노드를 바꾸면 기존 연결이 끊기거나 다시 연결될 수 있으므로, 중요한 통화 전에 짧게 검증하는 편이 안전합니다.

연결 문제가 남을 때 경로별로 원인 좁히기

Slack 웹 화면은 열리지만 메시지가 갱신되지 않는다면 웹 페이지 하나의 접속 성공만으로 정상이라고 판단할 수 없습니다. 앱을 완전히 종료한 뒤 다시 열고, 로그에서 새 연결이 생성되는지 확인하세요. 파일 업로드만 실패하면 메시지 연결과 별도로 파일 전송 요청이 어떤 도메인 및 규칙을 사용하는지 살펴봅니다. 확인되지 않은 서비스 도메인을 추측해 광범위한 규칙으로 추가하기보다, 로그에 나타난 연결과 공식 업무 네트워크 안내를 기준으로 좁혀 가세요.

Zoom에서 회의 입장은 되지만 음성이나 영상이 불안정하다면 시스템 프록시만 활성화된 상태에서 미디어 트래픽이 Clash에 전달되지 않는 경우, UDP 처리 차이, Wi-Fi 품질 또는 노드 경로를 각각 점검합니다. TUN을 시험한다면 클라이언트가 해당 기능을 지원하는지, 권한이 허용되었는지, 코어 로그에 오류가 없는지 확인하세요. TUN을 켠 뒤에도 모든 연결이 프록시를 거친다고 단정하지 말고, 규칙과 정책 그룹 선택을 함께 확인해야 합니다.

• 업무 서비스만 실패: 도메인 규칙의 순서, 그룹 이름, 그룹에서 선택한 정책을 확인합니다.
• 회의 음성·영상만 불안정: UDP 연결 처리, TUN 지원 여부, Wi-Fi와 노드 경로를 따로 비교합니다.
• 사내 시스템만 실패: 회사의 VPN·DNS·직접 연결 정책을 확인하고, 임의로 사설망 전체를 프록시로 보내지 않습니다.
• 설정 적용 후 여러 앱이 실패: 마지막으로 추가한 규칙을 제거해 복구하고, 코어 시작 로그에서 YAML 오류나 참조되지 않는 그룹을 확인합니다.

규칙이 필요 이상으로 복잡해지면 한 번에 한 조건만 남기고 재시험하세요. 업무 시간 중에는 정상 작동한 설정 복사본을 보관해 빠르게 되돌릴 수 있도록 하는 것이 좋습니다. 회사가 관리하는 기기나 업무 프로필에서는 조직의 보안 정책이 우선이며, Clash 규칙으로 관리 정책을 우회하려고 해서는 안 됩니다.