Clash 클라이언트 화면 가이드: 프록시·프로필·로그 페이지 사용법

프로필, 아웃바운드, 트래픽 유입 경로 구분하기

Clash 클라이언트 사이드바에는 보통 프록시, 프로필, 연결, 로그, 설정 메뉴가 있습니다. 각 메뉴는 같은 기능으로 들어가는 서로 다른 경로가 아닙니다. 프로필 페이지에서는 불러올 노드와 프록시 그룹, 규칙을 정하고, 프록시 페이지에서는 각 그룹이 사용할 아웃바운드를 선택합니다. 연결 페이지에는 처리 중인 요청이 표시되고, 로그 페이지에는 코어 실행 이벤트가 기록됩니다. 시스템 프록시와 TUN 모드는 트래픽을 코어로 전달하는 역할을 합니다.

클라이언트마다 Proxies를 ‘프록시’ 또는 ‘프록시 그룹’, Profiles를 ‘프로필’ 또는 ‘구독’으로 번역할 수 있습니다. 아래에서는 ‘프록시 → 프록시 그룹 선택’처럼 조작 경로를 설명하며, 메뉴 이름이 모든 클라이언트에서 같다는 뜻은 아닙니다. 먼저 영문 이름과 기능으로 페이지를 확인한 뒤 실제 버튼과 비교해 조작하세요.

프로필 페이지: 구독 가져오기 및 프로필 활성화

가져오기에 성공해도 적용된 것은 아닐 수 있습니다

구독 주소는 보통 원격 프로필을 가져오는 데 사용되며, 노드 목록만 제공하는 경우도 있습니다. 클라이언트에서 바로 가져올 수 있는지는 응답 형식과 클라이언트의 가져오기 기능에 따라 달라집니다. 웹페이지 주소, 구독 주소, 노드 공유 링크는 서로 다른 형식입니다. 서비스 제공업체의 로그인 페이지 주소를 구독 입력란에 붙여 넣으면 코어가 필요한 YAML 대신 HTML을 받을 수 있습니다.

1. ‘프로필 / Profiles’ → ‘가져오기’ 또는 구독 주소 입력란으로 이동한 뒤, 서비스 제공업체에서 안내한 호환 구독 주소를 붙여 넣습니다.
2. 다운로드와 파싱이 끝날 때까지 기다린 다음 프로필 카드가 표시되는지, 구문 오류가 보고되는지 확인합니다.
3. 해당 프로필을 선택하고 선택 표시가 나타나거나 현재 프로필 이름이 바뀌었는지 확인합니다.
4. 프록시 페이지로 이동해 예상한 프록시 그룹과 노드가 표시되는지 확인합니다. 이전 내용이 그대로라면 프로필 페이지로 돌아가 활성화 상태를 확인하세요.

한 클라이언트에 여러 프로필을 저장할 수 있지만, 보통 한 번에 활성화되는 기본 프로필은 하나입니다. 일부 클라이언트는 병합, 덮어쓰기 또는 스크립트 처리도 지원하므로 디스크에 저장된 구독 원문과 코어가 최종적으로 불러온 설정이 다를 수 있습니다. 설정 항목을 확인할 때는 클라이언트의 실행 중 설정 또는 미리보기를 먼저 살펴보세요.

구독 업데이트와 규칙 세트 업데이트는 별개의 작업입니다

프로필 카드의 ‘업데이트’는 보통 원격 프로필을 다시 가져옵니다. proxy-providers를 사용하는 설정은 노드 제공자를 별도로 업데이트할 수도 있고, rule-providers를 사용하는 설정은 규칙 세트를 독립된 주기로 내려받을 수 있습니다. 기본 구독을 업데이트해도 모든 제공자 리소스가 동시에 새로 고쳐지는 것은 아닙니다.

• 노드 이름이나 개수가 예상과 다르면 구독 업데이트 시각과 해당 노드 제공자의 업데이트 결과를 확인합니다.
• 규칙 동작이 바뀌지 않았다면 현재 활성 프로필, 규칙 순서, 규칙 세트 로드 상태를 확인합니다.
• 직접 수정한 내용이 원래대로 돌아왔다면 원격 업데이트가 파일을 덮어썼을 수 있습니다. 클라이언트가 지원하는 영구 덮어쓰기 방식을 사용하세요.

구독 URL에는 인증 토큰이 포함되는 경우가 많습니다. 프로필 화면을 공유할 때는 전체 URL, QR 코드, 인증 정보를 가리세요. 도움을 요청할 때는 오류 문구, 코어 이름, 관련 설정 항목만 남기고 구독 주소 전체를 공개하지 마세요.

프록시 페이지: 모드와 프록시 그룹 구성원 선택

규칙·전역·직접 연결 모드에 따라 경로가 달라집니다

규칙 모드는 설정에 적힌 순서대로 요청을 검사한 다음 지정된 아웃바운드나 프록시 그룹으로 전달합니다. 전역 모드는 보통 요청을 전역 선택 그룹으로 보내지만, 실제로 프록시를 거치는지는 그 그룹에서 선택한 구성원에 따라 달라집니다. 직접 연결 모드에서는 코어가 처리하는 트래픽을 대상에 직접 연결합니다. 어떤 모드도 모든 앱의 트래픽을 자동으로 가져오지는 않습니다. 트래픽이 코어에 들어오는지는 시스템 프록시, TUN 또는 앱 자체 설정에 따라 달라집니다.

평소에는 규칙 모드를 사용하세요. 분기 결과를 비교하려고 잠시 전역 모드로 바꿀 수 있지만, 테스트가 끝나면 원래 모드로 되돌려야 합니다. 그렇지 않으면 직접 연결되어야 할 요청도 경로가 달라질 수 있습니다. 모드를 전환한 뒤에는 새 요청으로 확인하고, 이미 연결된 장시간 연결만 보지 마세요.

수동 그룹과 자동 그룹은 조작 방식이 다릅니다

select 그룹에서는 구성원을 직접 선택할 수 있습니다. url-test 그룹은 설정된 탐지 결과를 바탕으로 자동 선택합니다. fallback 그룹은 사용 가능 여부와 구성원 순서에 따라 다음 항목으로 전환합니다. load-balance 그룹은 설정된 정책에 따라 연결을 분산합니다. 자동 그룹을 바깥쪽 수동 그룹에서 선택하더라도, 내부에서 노드를 장기간 고정하는 기능이 제공되는 것은 아닙니다.

프록시 그룹은 다른 프록시 그룹을 참조할 수 있습니다. 예를 들어 ‘웹 트래픽’ 그룹이 ‘자동 선택’을 선택하고, ‘자동 선택’이 다시 특정 노드를 가리킬 수 있습니다. 실제 아웃바운드를 파악하려면 이 경로를 끝까지 따라가야 하며, 가장 바깥쪽 그룹 이름만 봐서는 알 수 없습니다. 설정의 DIRECT는 직접 연결, REJECT는 거부를 의미하며 프록시 서버가 아닙니다.

지연 시간 테스트는 1차 선별용입니다

‘속도 테스트’를 누르면 보통 지정된 URL에 대한 연결 가능 여부나 지연 시간을 확인하며, 전체 대역폭을 측정하는 것은 아닙니다. 예를 들어 한 번의 결과가 80 ms, 다른 노드가 120 ms로 표시됐다면 해당 테스트 조건에서 첫 번째 노드의 응답이 더 빨랐다는 뜻일 뿐입니다. 동영상 재생 속도나 초당 다운로드 용량을 예측할 수는 없습니다. 두 수치는 결과를 해석하는 방법을 설명하기 위한 예시이며, 이 사이트에서 측정한 값이 아닙니다.

시간 초과가 발생하면 테스트 주소, 네트워크 환경, 노드 상태부터 확인하세요. 모든 노드의 속도 테스트 버튼을 연속으로 빠르게 누르지 마세요. 동시 탐지는 부하를 높이고 평소 사용 환경을 판단하기 어렵게 만들 수 있습니다.

설정 페이지: 시스템 프록시, TUN, 혼합 포트 확인

‘설정 / Settings’ 또는 홈 화면 요약에는 보통 시스템 프록시, TUN 모드, 포트 설정이 있습니다. 시스템 프록시는 운영체제의 프록시 설정을 따르는 앱에 적합합니다. TUN은 가상 네트워크 인터페이스와 라우팅을 통해 조건에 맞는 트래픽을 전달하며, 관련 권한이 필요하고 다른 VPN의 라우팅과 충돌할 수도 있습니다. 처음 설정할 때는 유입 경로 하나만 검증하고 여러 스위치를 동시에 바꾸지 마세요.

혼합 포트는 하나의 수신 포트에서 HTTP 프록시와 SOCKS 프록시 연결을 모두 받습니다. 아래 예시는 로컬 혼합 포트를 7890으로 설정합니다. 설명을 위한 설정이며, 모든 클라이언트의 기본 포트가 이 값이라는 뜻도 아니고 노드와 규칙을 포함한 완전한 설정도 아닙니다.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

현재 클라이언트가 실제로 7890 포트를 수신 중이라면, 터미널에서 다음 명령으로 HTTP 프록시를 명시해 로컬 프록시 경로만 따로 확인할 수 있습니다. 먼저 포트를 확인하고 명령을 실행하세요. 예시 포트를 실제 값으로 간주하지 마세요.

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com

• HTTP 응답 헤더가 반환되면 지정한 프록시 포트로 요청에 응답했다는 뜻입니다. 다른 앱도 시스템 프록시를 따르고 있다는 의미는 아닙니다.
• 127.0.0.1:7890에 연결할 수 없다는 메시지가 나오면 코어 실행 상태, 실제 포트, 수신 설정부터 확인하세요.
• 로컬 포트에 연결한 뒤에도 시간 초과가 발생하면 대상 사이트 접속, 규칙, DNS, 상위 노드를 확인하세요. 시스템 프록시만 반복해서 전환하지 마세요.

연결 페이지: 요청에 적용된 규칙 확인

연결 페이지에서는 요청이 코어에 들어왔는지, 어떤 규칙이 적용됐는지, 최종적으로 어느 아웃바운드로 향하는지 확인할 수 있습니다. 흔히 표시되는 항목은 대상 도메인 또는 IP, 대상 포트, 네트워크 유형, 규칙, 프록시 경로, 업로드 및 다운로드 양입니다. 프로세스 이름 표시 여부는 시스템 권한, 코어 기능, 클라이언트 구현에 따라 다릅니다. 비어 있다고 해서 반드시 문제가 있는 것은 아닙니다.

1. ‘연결 / Connections’로 이동한 뒤 대상 도메인으로 먼저 필터링해 백그라운드 요청을 줄입니다.
2. 브라우저에서 대상 페이지를 열고 새 연결이 표시되는지 확인합니다. HTTPS 요청은 대상 포트 443을 사용하는 경우가 많지만, 포트만으로 앱 유형을 판단할 수는 없습니다.
3. 연결 세부 정보를 열어 적용된 규칙, 규칙 페이로드, 프록시 경로를 기록합니다.
4. 결과가 DIRECT라면 프록시가 작동하지 않는다고 바로 판단하지 말고, 먼저 직접 연결 규칙이 적용됐는지 확인하세요.

노드를 바꾼 뒤에도 기존 연결은 이전 아웃바운드를 계속 사용할 수 있습니다. HTTP 장기 연결, WebSocket, 스트리밍 세션은 한동안 유지될 수 있습니다. 다시 확인하려면 대상 앱의 연결을 닫거나 연결 페이지에서 해당 항목을 종료한 다음 새 요청을 보내세요. ‘모든 연결 닫기’는 다른 다운로드와 세션도 끊으므로 실행 전에 영향을 확인하세요.

연결 목록이 비어 있어도 노드가 원인이라고 단정할 수 없습니다. 앱이 새 요청을 보내지 않았거나 캐시를 사용했거나 시스템 프록시를 우회했을 수 있습니다. 요청이 빠르게 끝나 현재 화면에 남지 않았을 수도 있습니다. 목록을 반복해서 새로 고치는 것보다 확인 가능한 새 요청 하나를 보내고 로그를 함께 살펴보는 편이 효과적입니다.

로그 페이지: 시간순으로 로드 및 연결 시도 오류 찾기

로그 페이지에는 이벤트가 기록되며 전체 패킷 캡처가 제공되는 것은 아닙니다. 코어와 클라이언트에 따라 로그 문구는 달라질 수 있지만 확인 순서는 같습니다. 먼저 설정이 정상적으로 로드됐는지 확인하고, 다음으로 DNS, 규칙 리소스, 상위 연결을 살펴보세요. 로그 수준은 보통 silent, error, warning, info, debug이며, 실제 선택 항목은 현재 코어에 따라 다릅니다.

한 번에 문제 하나만 재현하세요

1. ‘로그 / Logs’로 이동한 뒤 표시 내용을 지우거나 현재 시각을 기록합니다.
2. 클라이언트에서 로그 수준을 변경할 수 있다면 먼저 info를 사용하고, 정보가 부족할 때만 잠시 debug로 바꿉니다.
3. 대상 사이트에 한 번만 접속한 뒤 해당 시간대의 관련 오류와 앞뒤 로그를 복사합니다.
4. 문제 해결이 끝나면 평소 로그 수준으로 되돌려 요청 정보가 과도하게 기록되지 않도록 합니다.

mihomo, 즉 이전 이름이 Clash Meta인 코어를 사용할 때는 설정이 확장 필드에 의존하는지 확인하세요. 클라이언트 화면이 비슷해도 코어 기능까지 모두 같은 것은 아닙니다. 문제를 신고하기 전에 ‘클라이언트 버전 + 코어 이름 + 코어 버전’을 기록하세요. 보통 ‘정보 / About’ 또는 코어 정보 영역에서 확인할 수 있습니다. ‘최신 버전’이라고만 적지 마세요.

첫 사용 및 문제 해결 점검 목록

각 페이지의 역할에 맞춰 확인하면 근거 없이 스위치를 바꾸는 일을 줄일 수 있습니다. 아래 순서는 ‘구독을 가져왔는데 웹페이지가 열리지 않는’ 흔한 상황에 적합합니다.

1. 프로필 페이지: 대상 프로필이 활성화되어 있고 오류 없이 로드됐는지, 프록시 페이지에 해당 그룹이 표시되는지 확인합니다.
2. 프록시 페이지: 규칙 모드를 사용하고 대상 서비스에 연결된 프록시 그룹을 확인합니다. 실수로 DIRECT 또는 사용할 수 없는 구성원을 선택하지 않았는지 살펴보세요.
3. 설정 페이지: 시스템 프록시 또는 TUN 유입 경로의 상태를 확인합니다. 터미널 테스트에서는 실제 혼합 포트를 명시하세요.
4. 연결 페이지: 새 요청을 보내 규칙과 프록시 경로를 확인합니다. 기록이 없으면 유입 경로를 먼저 확인하고, 기록이 있으면 아웃바운드를 확인하세요.
5. 로그 페이지: 요청을 재현한 시각을 기준으로 설정 파싱, DNS, 연결 시도 오류를 구분합니다. 한 번에 관련 설정 하나만 바꾸세요.

프록시 페이지에서는 선택하고, 프로필 페이지에서는 설정 출처를 확인하며, 연결 페이지에서는 실제 경로를 관찰하고, 로그 페이지에서는 실행 이벤트를 파악합니다. 요청이 어느 단계에서 막혔는지 먼저 확인한 다음 해당 페이지에서 해결하세요. 클라이언트를 바꾸더라도 같은 점검 방법을 사용할 수 있습니다.