먼저 구분하기: 클라이언트 화면과 프록시 코어
Clash 클라이언트는 일반적으로 그래픽 인터페이스와 프록시 코어로 구성됩니다. 인터페이스에서는 구독을 가져오고, 프록시 그룹을 확인하며, 설정을 바꿉니다. 코어는 로컬 포트를 열고 규칙에 따라 트래픽을 처리해 연결을 설정합니다. 창이 정상적으로 열려도 코어가 실행 중이라고 단정할 수 없으며, 노드 목록이 보여도 앱 트래픽이 코어를 통과한다는 뜻은 아닙니다.
Clash Meta(현 mihomo)를 사용하는 클라이언트는 TUN, 프로세스별 규칙, 여러 DNS 강화 모드 등을 제공할 수 있습니다. 지원 기능은 코어와 클라이언트 구현에 따라 달라집니다. 이 글은 기능별로 설명하며 특정 클라이언트의 화면 구성을 모든 버전의 공통 인터페이스로 간주하지 않습니다. 데스크톱에서는 사이드바가 흔하고, 모바일에서는 하단 탭이나 드로어 메뉴를 사용할 수 있습니다. 같은 이름의 버튼이 없다면 아래 표에서 해당 기능을 찾아보세요.
| 메뉴 | 주요 내용 | 확인할 수 있는 질문 |
|---|---|---|
| 대시보드 / 홈 | 코어 상태, 트래픽, 트래픽 우회 설정 | 프록시 서비스가 실행 중인가요? |
| 프록시 / Proxies | 프록시 그룹, 노드, 지연 시간 테스트 | 이번 연결은 어느 출구를 이용하나요? |
| 프로필 / Profiles | 구독, 로컬 파일, 업데이트 상태 | 현재 어떤 프로필을 사용 중인가요? |
| 규칙 / Rules | 적용 중인 규칙, 규칙 세트, 매칭 순서 | 대상 트래픽은 어떤 정책으로 보내야 하나요? |
| 연결 / Connections | 대상 주소, 규칙, 정책 경로, 트래픽 | 실제 연결은 어떤 경로를 거쳤나요? |
| 로그 / Logs | 시작 정보, 파싱 실패, 연결 오류 | 어느 단계에서 실패했나요? |
대시보드: 실행 상태를 확인한 뒤 트래픽 우회 여부 점검
코어 실행과 시스템 프록시 활성화는 별개
대시보드에는 보통 실시간 업로드·다운로드 속도, 누적 트래픽, 실행 상태가 표시됩니다. 실시간 속도가 0이라면 현재 집계 범위에서 전송 중인 데이터가 없다는 뜻일 뿐, 노드가 작동하지 않는다고 단정할 수는 없습니다. 처음 사용할 때는 코어가 실행 중인지 확인한 다음, 앱의 트래픽을 어떤 방식으로 클라이언트에 전달할지 점검하세요.
- 시스템 프록시: 운영체제에 로컬 프록시 주소를 등록합니다. 시스템 프록시 설정을 따르는 앱만 이를 사용하며, 일부 게임이나 명령줄 프로그램, 자체 프록시 설정이 있는 소프트웨어는 따르지 않을 수 있습니다.
- TUN 모드: 가상 네트워크 인터페이스를 통해 라우팅 조건에 맞는 트래픽을 전달합니다. 관리자 권한이나 관련 서비스가 필요한 경우가 많으며, 라우팅 제외 설정, DNS, 클라이언트 구성의 영향을 받습니다.
- LAN 허용: 다른 기기가 이 기기의 프록시 수신 포트에 접속할 수 있도록 하는 기능입니다. 이 기기의 브라우저가 인터넷에 연결되는 데 필요한 설정은 아닙니다. 켜기 전에 수신 주소, 방화벽, 접근 인증을 확인하세요.
인터페이스에서 「대시보드」→「시스템 프록시」로 이동해 시스템 프록시 설정을 찾을 수 있습니다. 일부 클라이언트에서는 트레이 아이콘을 마우스 오른쪽 버튼으로 클릭해야 합니다. TUN 설정은 보통 「설정」→「TUN 모드」에 있습니다. 이는 기능을 찾기 위한 경로이며, 실제 메뉴는 클라이언트에 따라 다릅니다. 이름이 비슷한 ‘시스템 프록시’와 ‘TUN’을 같은 설정으로 혼동하지 마세요.
포트와 프록시 모드의 역할
로컬 포트는 앱이 연결할 주소를 지정합니다. 설정 화면에 혼합 포트가 7890으로 표시된다고 가정하면, HTTP 프록시를 지원하는 앱을 수동으로 설정할 때 주소는 127.0.0.1, 포트는 7890으로 입력할 수 있습니다. 이는 예시이며 모든 클라이언트의 기본값은 아닙니다. 화면에 다른 포트가 표시되면 실제 값을 사용하세요. 혼합 포트는 보통 HTTP와 SOCKS를 모두 지원합니다. 별도의 HTTP 및 SOCKS 포트는 앱에서 선택한 프록시 유형에 맞춰야 합니다.
규칙, 전역, 직접 연결은 서로 다른 개념입니다. 규칙 모드는 규칙에 따라 트래픽을 분배합니다. 전역 모드는 보통 전역 정책에서 출구를 선택하지만, 모든 앱의 트래픽이 자동으로 클라이언트에 전달되는 것은 아닙니다. 직접 연결 모드는 코어에 들어온 연결을 바로 외부로 내보냅니다. 평소에는 규칙 모드를 사용하고, 규칙 영향을 분리해 확인할 때만 잠시 전역 모드로 바꾸는 편이 좋습니다.
프로필: 구독을 업데이트하고 활성화했는지 확인
프로필 메뉴에서는 개별 노드가 아니라 전체 설정의 출처를 관리합니다. 프로필은 구독 URL이나 로컬 YAML 파일에서 가져올 수 있으며, 노드 외에도 프록시 그룹, 규칙, DNS, 규칙 세트 참조가 포함될 수 있습니다. 가져오기에 성공했다고 해서 설정이 정상적으로 적용된 것은 아닙니다. 파싱에 성공했는지, 해당 프로필이 선택되어 활성화되었는지, 업데이트가 완료되었는지 확인하세요.
- 「프로필」 또는 「Profiles」로 이동한 뒤 가져오기 메뉴에서 구독이나 로컬 파일을 추가합니다.
- 항목의 업데이트 시각, 상태 메시지, 오류 정보를 확인합니다. 구독 업데이트 시간 초과와 YAML 파싱 실패는 서로 다른 문제입니다.
- 프로필 항목을 클릭하거나 ‘활성화’를 선택하고, 현재 사용 중 표시가 해당 항목으로 옮겨졌는지 확인합니다.
- 프록시 메뉴에서 프록시 그룹과 노드가 표시되는지 확인한 다음, 규칙 메뉴에서 규칙 내용이 예상한 대로인지 점검합니다.
일부 클라이언트는 구독 업데이트가 성공하면 자동으로 적용하지만, 다른 클라이언트는 수동으로 다시 불러와야 합니다. 업데이트 후 노드 목록이 바뀌지 않았다면 먼저 현재 활성화된 프로필을 확인하세요. 곧바로 같은 구독을 여러 번 가져오지는 마세요. 이름이 비슷한 프로필이 많으면 잘못 선택하기 쉽고, ‘파일을 수정했는데 적용되지 않는다’고 착각할 수도 있습니다.
구독 원본, 오버라이드, 실제 적용 설정은 서로 다를 수 있습니다
그래픽 클라이언트는 인터페이스 설정으로 구독에 포함된 포트, DNS, TUN 항목을 덮어쓰거나 설정 병합 및 스크립트 처리를 지원할 수 있습니다. 따라서 구독 원본이 코어에 전달되는 최종 설정과 항상 같지는 않습니다. 문제를 점검할 때는 ‘실행 설정’, ‘적용된 설정 보기’와 같은 메뉴를 찾아 최종 값을 확인하세요. 해당 메뉴의 제공 여부는 클라이언트에 따라 다릅니다.
임시로 생성된 실행 파일을 직접 수정해 장기 설정을 저장하지 마세요. 다시 불러올 때 파일이 재생성될 수 있습니다. 구독 파일도 업데이트 과정에서 덮어써질 수 있습니다. 변경 사항을 유지하려면 클라이언트에서 지원하는 오버라이드 기능을 사용하거나, 백업 후 별도의 로컬 설정 파일을 관리하세요.
프록시: 선택하는 대상은 개별 노드가 아니라 프록시 그룹일 수 있습니다
프록시 메뉴에는 보통 프록시 그룹이 먼저 표시되고, 각 그룹 안에 선택 가능한 항목이 나옵니다. 그룹에는 노드, 다른 프록시 그룹, DIRECT 같은 내장 정책이 들어갈 수 있습니다. 노드를 선택해도 대상 사이트에 영향을 주는지는 매칭된 규칙이 해당 그룹을 가리키는지에 달려 있습니다. 현재 연결에서 사용하지 않는 그룹을 바꿔도 그 연결의 출구는 바뀌지 않습니다.
| 그룹 유형 | 기본 동작 | 화면에서 확인할 점 |
|---|---|---|
select | 후보 항목을 직접 선택 | 선택한 뒤 표시가 바뀌었는지 확인 |
url-test | 탐지 결과에 따라 자동 선택하며, 허용 오차 등 설정의 영향을 받음 | 테스트 주소, 주기, 현재 선택 항목 확인 |
fallback | 일반적으로 목록 순서에 따라 사용 가능한 항목을 선택 | 첫 번째 항목이 사용 가능하면 지연 시간이 가장 낮은 항목이 선택되지 않을 수 있음 |
load-balance | 설정된 정책에 따라 연결마다 다른 항목을 할당 | 연결마다 서로 다른 출구를 사용할 수 있음 |
지연 시간은 다운로드 속도 순위가 아닙니다
같은 테스트에서 노드 A가 65 ms, 노드 B가 120 ms로 표시되었다고 가정해 보겠습니다. 이는 해당 테스트에 걸린 시간이 서로 다르다는 뜻일 뿐입니다. 설명을 위한 예시이며 이 사이트에서 측정한 결과가 아닙니다. 테스트 URL, DNS, 핸드셰이크 과정, 당시 네트워크 상태가 결과에 영향을 주므로 이 수치만으로 동영상 전송 속도나 게임의 UDP 성능을 판단할 수 없습니다.
시간 초과로 표시되어도 노드를 전혀 사용할 수 없다는 뜻은 아닙니다. 테스트 대상에 연결할 수 없는 경우일 수도 있습니다. 먼저 설정에서 테스트 주소를 확인한 다음 실제 서비스로 연결을 시험해 보세요. 노드를 수동으로 바꾼 뒤에는 새 연결을 시도해야 합니다. 이미 설정된 장시간 연결은 선택 항목을 바꿔도 자동으로 다른 경로로 이동하지 않는 경우가 많습니다.
규칙: 개수보다 매칭 순서 확인
규칙 메뉴에는 현재 불러온 트래픽 분기 규칙이 표시됩니다. 일반적으로 위에서부터 순서대로 확인하며, 먼저 일치하는 규칙의 정책을 적용합니다. 도메인 접미사 규칙, IP 대역 규칙, 최종 대체 규칙은 각각 용도가 다릅니다. 규칙이 많다고 해서 원하는 대로 트래픽이 분배되는 것은 아닙니다. 아래는 규칙 작동 방식을 보여 주는 예시이며, 기존 구독을 대체할 수 있는 완성된 설정이 아닙니다.
rules:
- DOMAIN-SUFFIX,example.com,DIRECT
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- MATCH,PROXY첫 번째 규칙은 일치하는 도메인을 직접 연결로 보냅니다. 두 번째 규칙은 해당 사설 IPv4 대역과 일치시키며, 이 규칙만을 위해 도메인 조회를 강제로 시작하지 않도록 no-resolve를 사용합니다. 마지막 규칙은 앞서 일치하지 않은 트래픽을 PROXY라는 프록시 정책으로 보냅니다. 실제 설정에 해당 정책 이름이 없다면 이 예시를 그대로 사용할 수 없습니다.
여기서 example.com은 문서용 예시 도메인입니다. 실제 문제를 점검할 때는 연결 메뉴에 기록된 대상 도메인을 사용하세요. 웹페이지 하나도 로그인, 이미지, API 등 여러 도메인에 요청할 수 있습니다. 브라우저 주소창에 표시된 기본 도메인만 확인하면 실제 실패한 요청을 놓치기 쉽습니다.
RULE-SET을 사용하는 설정이라면 참조된 규칙 세트가 정상적으로 로드되었는지도 확인해야 합니다. 규칙 메뉴에 참조 항목이 보인다고 원격 규칙 세트까지 다운로드되었다는 뜻은 아닙니다. 규칙 정의가 올바른지, 연결에서 실제로 어떤 규칙이 적용되었는지는 연결 메뉴와 로그 메뉴를 함께 확인하세요. 설정 구조에 관한 자세한 내용은 사용 설명서의 프록시 그룹 안내를 참고하세요.
연결: 실제 접속 경로 확인
연결 메뉴는 트래픽 분배 결과를 확인하기 가장 좋은 곳입니다. 일반적으로 대상 호스트와 포트, 출발지 주소, 네트워크 유형, 매칭된 규칙, 정책 경로, 업로드·다운로드량이 표시됩니다. 일부 클라이언트는 프로세스 이름도 보여 주지만, 운영체제 권한과 코어 기능에 따라 표시 여부가 달라집니다. 프로세스 열이 비어 있어도 연결에 문제가 있다고 단정할 수 없습니다.
- 목록에 불필요한 항목이 섞이지 않도록 관련 없는 다운로드를 잠시 멈추세요. 표시 기록은 지워도 되지만, ‘기록 지우기’와 ‘연결 종료’는 서로 다른 작업입니다.
- 확인할 웹사이트를 연 뒤 도메인이나 프로세스 이름으로 즉시 필터링합니다.
- HTTPS에서 흔히 사용하는
443등 대상 포트를 확인한 뒤 매칭된 규칙과 정책 경로를 살펴봅니다. - 노드나 규칙을 변경했다면 해당 기존 연결을 종료한 다음 페이지를 새로고침해 연결을 다시 만듭니다.
목록에 대상 요청이 전혀 없다면 먼저 트래픽 전달 경로를 확인하세요. 앱이 시스템 프록시를 따르는지, 자체 프록시가 설정되어 있는지, TUN 라우팅 범위에 포함되는지 점검합니다. 요청은 표시되지만 정책 경로가 DIRECT로 끝난다면 노드 속도를 반복 측정하지 말고 매칭된 규칙을 확인하세요.
브라우저 접속에서는 TCP와 UDP 트래픽이 함께 발생할 수 있으며, HTTP/3 요청은 UDP 연결로 표시될 수 있습니다. 연결에 데이터가 전송 중이라고 표시되는데 페이지 이미지가 보이지 않는다면 실패한 리소스를 각각 확인하세요. 기본 페이지 연결이 성공했다고 모든 리소스가 정상이라는 뜻은 아닙니다.
로그: 오류는 시각을 기준으로 추적하고 빨간 항목만 보지 마세요
로그 메뉴에는 이벤트가 기록되며 전체 브라우징 기록이 저장되는 것은 아닙니다. 자주 쓰이는 로그 수준은 error, warning, info, debug입니다. 실제 선택 항목은 클라이언트와 코어에 따라 다릅니다. 평소에는 정보 수준을 사용하고, 세부 원인을 찾아야 할 때만 잠시 디버그를 켜세요. 문제를 재현한 뒤에는 로그가 너무 많아져 중요한 기록을 놓치지 않도록 원래 수준으로 되돌립니다.
| 로그 단서 | 관련 가능성이 있는 단계 | 다음 점검 항목 |
|---|---|---|
address already in use | 로컬 수신 포트 충돌 | 중복 실행 중인 코어 프로세스와 포트 설정 확인 |
timeout | 상위 서버 연결, 테스트 또는 요청 대기 시간 초과 | 대상 주소와 앞뒤 로그를 함께 확인 |
connection refused | 대상 포트에서 연결 거부 | 노드 주소와 포트, 서비스 상태 확인 |
| DNS 조회 오류 | 리졸버에 연결할 수 없거나 DNS 조회 경로에 이상이 있음 | DNS 상위 서버와 접속 경로 확인 |
| 설정 파싱 오류 | YAML 형식 오류 또는 지원되지 않는 필드 | 줄 번호를 기준으로 들여쓰기와 코어 지원 여부 확인 |
timeout은 구독 다운로드, 노드 연결, DNS 조회 중 어느 단계에서도 발생할 수 있습니다. 로그를 읽을 때는 시각, 구성 요소, 대상 주소를 함께 확인하세요. 새로고침이나 노드 전환을 누른 시각을 기록하고 문제를 한 번만 재현한 뒤, 전후 약 10초간의 로그를 살펴보는 것이 좋습니다. 여러 설정을 동시에 바꾸면 원인과 결과의 관계를 파악하기 어려워집니다.
가져오기부터 규칙 적용 확인까지 한 번에 점검하기
처음 설정할 때는 아래 순서대로 확인하면 됩니다. 각 단계에서는 한 가지 사실만 확인하고, 문제가 생기면 해당 메뉴에서 먼저 해결하세요. DNS, TUN, 규칙, 노드를 한꺼번에 바꿀 필요는 없습니다.
- 프로필: 구독을 정상적으로 가져왔고 현재 프로필이 활성화되어 있으며 업데이트 오류가 없는지 확인합니다.
- 대시보드: 코어가 정상 실행 중인지, 로컬 포트가 앱 설정과 일치하는지 확인합니다. 테스트를 시작할 때는 트래픽 전달 방식을 하나 선택하세요.
- 프록시: 대상 프록시 그룹을 확인하고 최종적으로 사용 가능한 노드나 원하는 정책을 가리키는지 확인합니다.
- 규칙: 관련 규칙이 있고 순서가 적절한지, 규칙 세트가 로드되었는지 확인합니다.
- 연결: 새로 접속한 뒤 대상, 매칭된 규칙, 최종 출구를 확인합니다.
- 로그: 접속에 실패했다면 같은 시간대의 로그를 살펴보고 DNS 조회, 연결 시도, 설정 오류를 확인합니다.
각 메뉴에서 확인할 수 있는 내용을 기억하세요. 프로필은 ‘무엇을 불러왔는지’, 프록시는 ‘무엇을 선택할지’, 규칙은 ‘어떻게 분배할지’, 연결은 ‘실제로 무슨 일이 있었는지’, 로그는 ‘어디서 오류가 났는지’를 보여 줍니다. 대시보드에서는 실행 상태와 트래픽 전달 설정을 확인할 수 있습니다. 브라우저와 시스템 네트워크 설정을 추가로 점검하려면 연결 확인 단계를 따라 진행하세요.