클라이언트 화면, 코어, 현재 프로필을 구분하세요
Clash 클라이언트 창은 설정을 보여주고, 코어는 연결을 처리하며, 프로필 파일은 노드, 정책 그룹, DNS, 규칙을 정의합니다. mihomo 코어를 사용하는 클라이언트는 대체로 비슷한 페이지 구성을 갖지만 버튼 이름과 위치는 다를 수 있습니다. 아래 설명은 흔히 쓰이는 한국어 UI의 ‘프록시’, ‘프로필’, ‘로그’, ‘연결’, ‘설정’을 기준으로 합니다. 일부 클라이언트에서는 ‘프로필’을 ‘구독’, ‘프록시’를 ‘프록시 그룹’이라고 표시합니다.
이 글은 화면 조작 방법을 안내하며 특정 클라이언트 버전에 한정되지 않습니다. 메뉴 이름이 다르면 스크린샷의 위치를 그대로 따라 누르기보다 설정의 기능을 확인하세요. Clash 배포 스테이션은 클라이언트 정보와 사용법을 제공하며, 클라이언트 공식 개발팀과는 무관합니다.
| 페이지 | 우선 확인할 항목 | 확인할 수 있는 내용 |
|---|---|---|
| 프록시 | 실행 모드, 정책 그룹, 현재 선택 항목 | 규칙이 프록시 그룹을 선택했다면 최종적으로 어떤 출구를 사용하나요? |
| 프로필 | 현재 적용된 프로필, 업데이트 상태, 오버라이드 내용 | 코어가 실제로 불러온 프로필은 무엇인가요? |
| 로그 | 시간, 수준, 대상, 매칭 규칙, 오류 원인 | 요청 처리의 어느 단계에서 문제가 발생했나요? |
| 연결 | 대상 주소, 규칙, 프록시 체인, 활성 연결 | 진행 중인 요청은 어떤 경로를 사용하나요? |
| 설정 | 시스템 프록시, TUN, 수신 포트 | 앱 트래픽이 코어로 전달되고 있나요? |
프록시 페이지: 실행 모드를 먼저, 정책 그룹은 다음에 확인
규칙·전역·직결 모드의 차이
프록시 페이지 상단에는 보통 ‘규칙’, ‘전역’, ‘직결’ 모드가 있습니다. 모드는 연결에 적용할 정책을 결정할 뿐, 시스템의 모든 앱이 이미 프록시를 사용하도록 연결됐는지는 결정하지 않습니다. 전역 모드로 바꿔도 시스템 프록시 설정을 읽지 않거나 TUN으로 트래픽을 전달하지 않는 프로그램은 코어를 우회할 수 있습니다.
- 규칙 모드(Rule):
rules의 순서대로 규칙을 확인하고, 처음 일치한 규칙에 지정된 정책을 사용합니다. 정책은DIRECT,REJECT, 노드 또는 프록시 그룹일 수 있습니다. - 전역 모드(Global): 전역 정책 그룹에서 현재 선택된 항목을 사용합니다. 출구를 확인하려면
GLOBAL또는 UI의 전역 선택 영역으로 이동해야 합니다. 일반 정책 그룹만 확인해서는 안 됩니다. - 직결 모드(Direct): 코어에 전달된 연결은 직결 정책을 사용합니다. 클라이언트를 종료하거나 시스템 프록시를 끄는 것과는 다릅니다.
처음 사용할 때는 보통 규칙 모드를 유지합니다. 일시적으로 전역 모드로 바꾸면 분기 규칙이 접속에 영향을 주는지 확인할 수 있지만, 테스트가 끝나면 원래 모드로 되돌리세요. 전역 모드에서는 되지만 규칙 모드에서는 안 된다면 규칙 매칭 결과와 연결된 정책 그룹을 확인해야 합니다. 노드가 고장 났다고 바로 단정할 수는 없습니다.
정책 그룹은 서로 무관한 노드 목록이 아닙니다
프록시 페이지의 ‘노드 선택’, ‘자동 선택’, ‘미디어 서비스’ 같은 이름은 보통 프로필의 proxy-groups에서 가져오며, 클라이언트에 고정된 기능이 아닙니다. 그룹은 노드뿐 아니라 다른 그룹도 참조할 수 있습니다. 따라서 ‘자동 선택’을 선택했다면 현재 그룹이 다음 선택을 하위 그룹에 맡겼다는 뜻입니다.
select: 수동 선택입니다. 항목을 누르면 이후 관련 연결에 해당 선택이 적용됩니다.url-test: 설정된 테스트 주소, 간격, 허용 오차를 기준으로 자동 선택합니다. 모든 사이트에서 지연 시간이 가장 낮다는 뜻은 아닙니다.fallback: 설정된 순서에 따라 사용 가능한 항목을 선택합니다. 일반적으로 테스트 지연 시간이 낮은 순서로 정렬하지는 않습니다.load-balance: 설정된 분배 정책에 따라 여러 출구를 사용합니다. 하나의 다운로드 연결에서 모든 노드의 대역폭을 합산한다는 뜻은 아닙니다.
노드를 바꾼 뒤에도 이미 연결된 장시간 연결은 이전 출구를 계속 사용할 수 있습니다. 확인하려면 요청을 새로 보내세요. 필요한 경우 ‘연결’ 페이지에서 대상 연결을 종료할 수 있습니다. 웹페이지 하나를 확인하려고 모든 연결을 끊으면 다운로드나 회의에 영향을 줄 수 있으니 피하세요.
프로필 페이지: 적용 중인 프로필과 구독 업데이트 확인
가져오기·업데이트·활성화는 각각 다른 작업입니다
‘프로필’ 페이지의 카드 하나는 보통 로컬 또는 원격 프로필 하나를 나타냅니다. 가져오기에 성공해도 프로필 원본이 클라이언트에 저장됐다는 뜻일 뿐, 현재 프로필로 선택됐다는 보장은 없습니다. ‘활성화’, ‘이 프로필 사용’을 누르거나 카드를 선택한 다음 현재 프로필 표시를 확인하고 파싱 오류가 있는지도 살펴보세요.
- ‘프로필’을 열고 현재 적용 중인 카드의 이름과 선택 표시를 확인하세요.
- 카드 메뉴에서 ‘정보 수정’ 또는 ‘상세 정보’를 열어 구독 주소가 예상한 출처인지 확인하세요. 전체 주소가 보이도록 화면을 캡처해 공개하지 마세요.
- ‘업데이트’를 실행하고 업데이트 시간과 오류 메시지를 확인하세요. 그런 다음 ‘프록시’ 페이지로 돌아가 그룹 이름과 노드 목록이 예상과 일치하는지 살펴보세요.
- 업데이트 후 활성화에 실패하면 ‘로그’에서 파싱 오류를 확인하세요. 들여쓰기, 필드 형식, 코어 지원 여부를 먼저 점검하세요.
일반적으로 구독 업데이트는 원격 콘텐츠를 다시 가져오는 작업이지 클라이언트 프로그램 업데이트가 아닙니다. 개별 proxy-provider를 업데이트하면 노드 목록만 새로고침되고 기본 프로필의 규칙과 DNS는 바뀌지 않을 수 있습니다. 노드는 바뀌었는데 규칙이 그대로라면 프로필 업데이트를 실행했는지, 제공자 업데이트를 실행했는지 먼저 확인하세요.
로컬 수정, 오버라이드, 최종 실행 프로필
원격 구독에서 내려받은 파일을 직접 수정하면 다음 업데이트 때 변경 사항이 덮어써질 수 있습니다. 분기 규칙을 계속 유지하려면 클라이언트가 지원하는 ‘오버라이드’, ‘확장 설정’ 또는 병합 기능을 사용하세요. 클라이언트마다 병합 순서가 다르므로 규칙이 끝에 추가되는지 앞쪽에 삽입되는지 특히 확인해야 합니다.
아래는 규칙 일부이며 완전한 프로필이 아닙니다. 기존 프로필에 Proxy라는 정책 그룹이 있어야 합니다. 단독 구독으로 바로 가져올 수 없습니다:
rules:
- DOMAIN-SUFFIX,example.com,Proxy
- GEOIP,CN,DIRECT
- MATCH,ProxyDOMAIN-SUFFIX,example.com,Proxy는 해당 도메인과 하위 도메인에 매칭됩니다. GEOIP,CN,DIRECT는 대상 IP의 지리 데이터베이스 결과를 기준으로 판단합니다. MATCH,Proxy는 앞선 규칙에 매칭되지 않은 연결을 처리합니다. 도메인 규칙을 MATCH 뒤에 두면 앞의 기본 규칙이 먼저 매칭되므로 적용되지 않습니다.
클라이언트에 ‘실행 중인 프로필 보기’ 또는 ‘런타임 프로필’ 기능이 있다면 수정 후 최종 결과를 확인하세요. 편집기에 규칙이 있다고 해서 코어가 그 규칙을 불러왔다는 뜻은 아닙니다. 프로필 전환 실패, 비활성화된 오버라이드, 잘못된 규칙 추가 위치 때문에 두 내용이 달라질 수 있습니다.
로그 페이지: 요청 한 번으로 규칙과 출구 확인
로그 수준은 info부터, 필요할 때만 잠시 debug 사용
일반적인 로그 수준에는 debug, info, warning, error, silent가 있습니다. 평소 문제를 확인할 때는 info를 사용하세요. 더 자세한 처리 정보가 필요할 때만 잠시 debug로 전환합니다. UI에 ‘수준 필터’와 설정의 ‘로그 수준’이 모두 있다면, 전자는 표시 내용만 필터링하고 후자가 코어에서 생성할 로그를 결정할 수 있습니다.
- ‘로그’를 열고 자동 스크롤을 멈추거나 현재 표시 내용을 지운 뒤 시작 시간을 기록하세요.
- 브라우저로 돌아가 확인할 페이지에 한 번만 접속하세요.
- 로그로 돌아와 도메인 키워드로 필터링하세요. 테스트 사이트를 여러 개 동시에 열지 마세요.
- 네트워크 유형, 대상, 규칙 유형, 출구 순서로 확인한 다음 오류 설명을 살펴보세요.
다음은 구조를 보여주는 예시이며 특정 버전의 로그를 그대로 옮긴 것이 아닙니다. 클라이언트에 따라 같은 정보가 여러 열로 나뉘거나 다른 형식으로 표시될 수 있습니다:
[info] [TCP] 127.0.0.1:53124 --> www.example.com:443
match DomainSuffix(example.com) using Proxy[노드 A]TCP: 해당 로그는 TCP 연결에 관한 것입니다. 다른 UDP 트래픽도 정상적으로 처리된다고 판단할 수는 없습니다.127.0.0.1:53124: 예시의 로컬 출발지 주소와 임시 출발지 포트입니다. 시스템 설정에 입력할 프록시 수신 포트가 아닙니다.www.example.com:443: 대상 도메인과 HTTPS에서 흔히 사용하는 포트입니다. 443이 표시된다고 해서 클라이언트가 HTTPS 콘텐츠를 복호화하고 있다는 뜻은 아닙니다.DomainSuffix(example.com): 도메인 접미사 규칙에 매칭됐습니다.Proxy[노드 A]: Proxy 정책 그룹을 거쳐 노드 A를 사용한다는 예시입니다. 그룹이 여러 단계로 연결되어 있다면 ‘연결’ 페이지에서 전체 프록시 체인도 확인하세요.
오류가 발생한 단계에 따라 로그 읽기
| 로그 키워드 | 먼저 확인할 항목 | 바로 단정하면 안 되는 내용 |
|---|---|---|
timeout | 시간 초과가 발생한 대상, 노드 연결 상태, DNS 요청 단계 | 모든 시간 초과가 구독 만료 때문이라는 판단 |
connection refused | 오류 메시지에 표시된 호스트와 포트, 해당 서비스의 수신 여부 | 반드시 로컬 프록시 포트 오류라는 판단 |
lookup 또는 DNS 오류 | 조회 대상, DNS 업스트림, 부트스트랩 DNS 확인, 네트워크 연결 상태 | 아무 노드나 바꾸면 해결된다는 판단 |
REJECT | 매칭된 차단 규칙과 규칙 순서 | 노드 연결 실패 |
| 프로필 파싱 오류 | 오류 행 주변의 YAML 들여쓰기, 필드 값, 참조 이름 | 브라우저 프록시를 바꾸면 복구된다는 판단 |
브라우저에서 페이지를 열 수 없는데 관련 로그가 없다면 필터 조건과 로그 수준을 먼저 확인한 다음 요청이 코어에 전달됐는지 점검하세요. 브라우저 캐시와 기존 연결 재사용도 확인 결과에 영향을 줄 수 있습니다. 노드를 반복해서 바꾸기보다 대상 요청을 새로 보내면 로그와 요청을 더 쉽게 연결할 수 있습니다.
설정·연결 페이지: 트래픽 유입 경로 확인
‘시스템 프록시’와 ‘TUN 모드’는 서로 다른 방식으로 트래픽을 연결합니다. 시스템 프록시는 시스템 프록시 설정을 읽는 앱에 프록시 주소를 제공합니다. 일부 명령줄 도구, 게임, 자체 네트워크 설정을 사용하는 프로그램은 시스템 프록시를 따르지 않습니다. TUN은 가상 네트워크 인터페이스와 라우팅을 이용해 트래픽을 전달하며, 적용 범위는 라우팅 제외 설정, 권한, DNS 설정, 다른 VPN의 영향도 받습니다.
포트는 기본값을 외우기보다 현재 설정을 확인하세요
예를 들어 실행 중인 프로필에 아래 두 항목이 있으면 HTTP 또는 SOCKS를 지원하는 앱은 각 프로토콜에 맞춰 로컬 포트 7890에 연결할 수 있습니다. 7890은 예시 설정값이며 모든 클라이언트에서 기본값으로 사용되는 것은 아닙니다:
mixed-port: 7890
allow-lan: false같은 기기에서 프록시를 직접 설정할 때 주소는 보통 127.0.0.1을 사용하며, 포트는 ‘설정’의 ‘혼합 포트’와 일치해야 합니다. external-controller는 제어 인터페이스이며 브라우저에서 사용하는 프록시 포트가 아닙니다. allow-lan: false로 설정되어 있다면 다른 LAN 기기에서 해당 프록시를 바로 사용할 수 있다고 기대해서는 안 됩니다.
토글 색상만 보지 말고 연결 기록으로 확인하세요
시스템 프록시나 TUN을 켠 뒤 ‘연결’ 페이지에서 대상 도메인을 검색하고 규칙과 프록시 체인을 확인하세요. 대상이 198.18.0.0/16 대역의 주소로 표시된다면 Fake-IP를 사용하도록 설정된 경우 정상적으로 매핑된 주소일 수 있습니다. 낯선 주소라는 이유만으로 잘못된 서버에 접속했다고 단정하지 말고 도메인과 DNS 설정을 함께 확인하세요.
시스템 프록시와 규칙 설정을 알아보려면 시스템 프록시 설정 방법과 규칙 설정 안내를 확인하세요. TUN은 시스템 라우팅에 영향을 주므로 활성화 전에 기존 설정을 보존하세요. 네트워크 문제가 발생하면 새로 추가한 트래픽 전달 기능부터 끈 다음 항목별로 점검하세요.
전체 점검 순서: 프로필에서 규칙 매칭까지
화면 사용에 익숙해졌다면 다음 순서로 한 번 점검해 보세요. 한 번에 조건 하나만 바꾸고 변경 전후 결과를 기록하면 구독, 노드, DNS, 모드를 동시에 바꿔 원인을 놓치는 일을 줄일 수 있습니다.
- 프로필 확인: ‘프로필’ 페이지에서 현재 카드를 확인하고, 업데이트 후 정상적으로 불러왔는지 확인하세요. 필요하면 최종 실행 프로필도 살펴보세요.
- 모드 확인: ‘프록시’ 페이지에서 규칙 모드를 선택하고 대상 규칙이 가리키는 그룹을 찾아 그룹 내 현재 선택 항목을 확인하세요.
- 연결 방식 확인: ‘설정’에서 시스템 프록시 또는 TUN 상태를 확인하세요. 앱에 프록시를 직접 설정했다면 주소, 프로토콜, 포트를 점검하세요.
- 요청 보내기: 대상에 새로 접속한 다음 ‘로그’ 또는 ‘연결’ 페이지에서 같은 도메인을 찾으세요.
- 경로 확인: 매칭된 규칙, 그룹 이름, 최종 출구를 확인하세요. 규칙이 예상과 다르면 순서를 점검하고, 출구가 다르면 그룹 참조 관계를 살펴보세요.
- 평소 설정으로 복원: 임시 전역 모드와 debug 설정을 되돌리고, 검증을 마친 설정은 유지하세요.
프록시 페이지에서는 ‘어떤 출구를 선택했는지’, 프로필 페이지에서는 ‘어떤 설정을 불러왔는지’, 로그 페이지에서는 ‘이번 연결에서 실제로 무슨 일이 있었는지’를 확인할 수 있습니다. 트래픽 유입 경로까지 함께 확인해야 프로필 미적용, 규칙 미매칭, 노드 연결 불가, 앱 미연결 문제를 구분할 수 있습니다. 원인을 찾기 어렵다면 문제 해결에서 문제 유형별 점검 방법을 확인하세요.