클라이언트 화면과 프록시 코어 구분하기

Clash 클라이언트는 보통 그래픽 인터페이스와 프록시 코어로 구성됩니다. 인터페이스에서는 구독을 가져오고 프록시 그룹을 표시하거나 시스템 프록시를 전환합니다. 코어는 설정을 읽고 규칙을 매칭해 연결을 처리합니다. Clash Verge Rev, FlClash 등은 메뉴 위치가 서로 다르며, mihomo를 사용하는 클라이언트는 원본 Clash에 없는 설정 기능도 제공할 수 있습니다. 화면에 “Clash”라고 표시된다는 이유만으로 모든 필드와 기능이 같다고 볼 수는 없습니다.

이 글에서는 데스크톱 클라이언트에서 흔히 볼 수 있는 화면을 기준으로 설명합니다. 경로에 나오는 “프록시”, “설정”, “로그”는 각 기능 페이지를 뜻하며, 일부 클라이언트에서는 “설정”을 “구독”이라고 부릅니다. Clash Verge Rev의 일반적인 화면 구성을 예로 들면 왼쪽 메뉴의 「설정」에서 파일을 가져온 다음 「프록시」에서 그룹을 선택하고, 마지막으로 「설정」에서 시스템 프록시를 확인합니다. 릴리스 버전에 따라 버튼 이름이 달라질 수 있으므로 현재 화면의 문구와 실제 적용된 설정을 기준으로 확인하세요.

페이지 또는 영역주요 기능먼저 확인할 항목
프록시 페이지모드 선택, 프록시 그룹 확인, 출구 전환현재 모드와 규칙에서 실제로 참조하는 그룹
설정 페이지설정 가져오기, 업데이트, 선택현재 활성화된 항목과 최근 업데이트 결과
로그 페이지코어 이벤트와 오류 확인오류 발생 시각, 레벨, 대상 주소
연결 페이지활성 연결과 매칭된 규칙 확인연결이 DIRECT 또는 특정 프록시 그룹을 통하는지
설정 페이지프록시 연결, 서비스, 시작 동작 관리시스템 프록시, TUN, 수신 포트

프록시 페이지: 모드, 프록시 그룹, 노드 선택

규칙·전역·직결은 노드 세 개가 아닙니다

프록시 모드는 트래픽의 경로를 결정합니다. rule은 설정의 rules를 위에서 아래로 매칭하고, global은 보통 코어로 들어온 연결을 전역 프록시 그룹으로 보냅니다. direct는 코어로 들어온 연결을 직접 연결합니다. 사이트별로 트래픽을 나누려면 보통 “규칙” 모드를 선택하면 됩니다. “전역”으로 바꿔도 클라이언트에 들어오지 않은 앱 트래픽까지 자동으로 처리하지 않으며, TUN을 켠 것과도 다릅니다.

  • 규칙 모드: 로컬 네트워크와 지정한 사이트는 직접 연결하고 나머지 대상은 프록시를 사용하도록 설정할 때 적합합니다.
  • 전역 모드: 문제가 트래픽 분기 규칙에서 발생했는지 임시로 확인할 때 유용합니다. 확인이 끝나면 원래 모드로 되돌리세요.
  • 직결 모드: 로컬 네트워크와 비교할 때 사용할 수 있습니다. 다만 코어의 DNS 처리는 계속 적용될 수 있으므로 클라이언트를 완전히 종료한 상태와 같지는 않습니다.

규칙에서 참조하는 프록시 그룹부터 확인하세요

“노드”는 실제 프록시 출구이고, “프록시 그룹”은 출구를 선택하는 방식입니다. select 유형의 그룹에서는 직접 노드를 고를 수 있고, url-test는 상태 검사 결과에 따라 출구를 자동 선택하며, fallback은 사용 가능 여부와 순서에 따라 선택합니다. 프록시 그룹 카드가 여러 개 보여도 모두 바꿀 필요는 없습니다. 먼저 연결 페이지에서 대상 트래픽이 어느 그룹에 매칭됐는지 확인한 뒤 해당 그룹만 변경하세요.

아래는 화면 간 관계를 설명하기 위한 설정 예시이며, 완전한 구독 설정은 아닙니다. 手动选择의 후보에는 DIRECT만 있으므로 해외 프록시 출구를 제공하지 않습니다. 실제 구독에서는 여기에 정의된 노드나 프록시 제공자를 참조합니다.

mode: rule
proxy-groups:
  - name: 수동 선택
    type: select
    proxies:
      - DIRECT
rules:
  - DOMAIN-SUFFIX,example.com,手动选择
  - MATCH,DIRECT

이 설정에서는 example.com과 그 하위 도메인에 접속할 때 “수동 선택” 그룹이 매칭되고, 나머지 대상은 마지막 규칙인 MATCH에 매칭됩니다. 화면에 다른 그룹이 더 있어도 규칙에서 참조하지 않으면 해당 그룹을 바꿔도 이번 연결의 출구는 달라지지 않습니다.

지연 시간 테스트 결과는 테스트 대상에 한정됩니다

프록시 페이지의 “속도 테스트”는 보통 지정된 URL에 연결해 연결 상태나 지연 시간을 확인하는 기능이며, 다운로드 속도를 측정하는 테스트는 아닙니다. 예를 들어 한 번 80ms가 표시됐다면 당시 해당 테스트 대상에 대한 결과일 뿐입니다. 동영상 로딩 속도를 단정하거나 모든 사이트에 접속할 수 있다고 판단할 수는 없습니다. “시간 초과”는 테스트 대상에 접속할 수 없거나 DNS에 문제가 있거나 노드가 고장 난 경우에도 발생할 수 있으므로 로그와 함께 확인하세요.

설정 페이지: 구독 가져오기·활성화·업데이트

가져오기에 성공해도 현재 설정으로 활성화된 것은 아닙니다

설정 페이지에는 코어가 불러올 설정의 출처가 저장됩니다. 원격 구독은 보통 URL에서 YAML을 가져오고, 로컬 설정은 파일로 가져옵니다. 클라이언트에 따라 노드 링크 하나나 다른 구독 형식도 지원할 수 있지만, Clash YAML만 허용하는 경우도 있습니다. 파싱에 실패했다면 업데이트를 반복해서 누르기보다 먼저 형식이 맞는지 확인하세요.

  1. 「설정」 또는 「구독」 페이지로 이동해 URL 입력란이나 원격 설정 추가 메뉴에 구독 주소를 붙여 넣습니다.
  2. “가져오기” 또는 “다운로드”를 실행하고 설정 카드가 나타날 때까지 기다린 뒤 파싱 오류가 표시되는지 확인합니다.
  3. 해당 설정을 선택하고 “현재”, “활성화됨” 표시나 선택 표시가 있는지 확인합니다. 새 카드가 추가되어도 현재 설정이 자동으로 바뀌는 것은 아닙니다.
  4. 「프록시」 페이지로 돌아가 원하는 프록시 그룹이 표시되는지 확인합니다. 이전 그룹이 계속 보인다면 설정 전환이 실패했는지 살펴보세요.

구독 주소에는 액세스 토큰이 포함되는 경우가 많으므로 비밀번호처럼 안전하게 보관해야 합니다. 문제를 문의할 때는 도메인, 상태 코드, 오류 유형만 설명하고 전체 주소를 공개 댓글에 올리지 마세요. 클라이언트에 표시되는 QR 코드에도 같은 인증 정보가 들어 있을 수 있습니다.

구독 업데이트는 클라이언트 업그레이드와 다릅니다

설정 카드의 “업데이트”는 보통 원격 콘텐츠를 다시 다운로드해 노드, 규칙, 프록시 그룹을 갱신합니다. 소프트웨어 업데이트는 클라이언트 프로그램을 교체하고, 코어 업데이트는 프록시 엔진을 교체합니다. 각각의 역할이 다릅니다. 특정 프로토콜을 지원하지 않는다면 구독을 업데이트해도 해결되지 않을 수 있습니다. 현재 코어가 해당 프로토콜과 필드를 지원하는지 확인하세요.

원격 설정을 직접 수정하면 다음 구독 업데이트 때 변경 사항이 덮어써질 수 있습니다. 포트, DNS, 규칙을 장기간 유지해야 한다면 클라이언트에서 제공하는 오버라이드, 병합 또는 확장 설정 기능을 우선 사용하세요. 저장 후에는 “실행 설정” 또는 “적용된 설정”도 확인해야 합니다. 원본 파일에 필드를 작성했더라도 클라이언트가 병합한 뒤 같은 값으로 적용된다는 보장은 없습니다.

  • HTTP 401 또는 403: 먼저 구독 인증 정보, 서비스 상태, 접근 권한을 확인하세요.
  • HTTP 404: 주소가 완전한지, 경로가 만료되지 않았는지 확인하고 웹페이지 주소를 구독 주소로 착각하지 않도록 주의하세요.
  • YAML 파싱 오류: 들여쓰기와 필드 유형을 확인하고, 서버가 HTML 오류 페이지를 반환하지 않았는지도 살펴보세요.
  • 다운로드 시간 초과: 로컬 네트워크에서 구독 도메인에 접속할 수 있는지 확인하세요. 클라이언트가 프록시를 통한 업데이트를 지원한다면 업데이트에 사용하는 프록시도 정상 작동하는지 점검해야 합니다.

설정 페이지: 시스템 프록시, 포트, TUN

Clash Verge Rev의 일반적인 화면에서는 「설정」의 관련 설정 영역에서 시스템 프록시와 TUN을 찾을 수 있습니다. 다른 클라이언트에서는 홈 화면에 스위치가 있을 수도 있습니다. “시작 시 실행”을 “프록시 사용”으로 오해하지 말고, 스위치 이름으로 찾아보세요. 시작 시 실행은 프로그램을 자동으로 시작하는 기능이며, 서비스 모드는 보통 코어 실행에 필요한 시스템 권한을 제공합니다.

시스템 프록시는 운영체제 설정을 따르는 앱에서만 작동합니다

시스템 프록시는 운영체제의 HTTP 프록시를 로컬 수신 주소로 지정합니다. 아래에서는 설명을 위해 127.0.0.1:7890을 사용하지만, 모든 클라이언트의 기본 포트가 이 값인 것은 아닙니다. 적용된 설정의 mixed-port가 7897이라면 프록시를 직접 설정하는 앱에도 7897을 입력해야 합니다. 안내에 나온 7890을 그대로 사용하면 안 됩니다.

# 로컬 연결 설정 예시이며, 전체 설정은 아닙니다
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

mixed-port는 하나의 포트에서 HTTP와 SOCKS 프록시를 모두 제공합니다. allow-lan: false는 로컬 네트워크의 접근을 제한합니다. 다른 기기에서 이 컴퓨터의 프록시를 사용하려면 수신 주소, 방화벽, 인증도 설정해야 합니다. “일단 시험해 보려고” 로컬 네트워크 공유를 켜지는 마세요.

TUN은 더 많은 트래픽을 처리합니다

TUN은 가상 네트워크 어댑터와 라우팅을 통해 더 많은 트래픽을 코어로 전달하며, 시스템 프록시를 따르지 않는 앱에 주로 사용됩니다. 운영체제 권한, 가상 네트워크 어댑터, 코어 지원이 필요하므로 시스템 프록시 스위치와 같은 기능이 아닙니다. 처음 사용하는 경우 일반 브라우저가 시스템 프록시를 통해 정상 접속되는지 먼저 확인한 다음 TUN을 시도하세요. 네트워크가 끊기면 TUN을 끄고 기본 연결이 복구되는지 확인합니다.

로그 페이지: 레벨 필터와 오류 확인

로그 레벨 필터와 기록되는 레벨을 구분하세요

로그 페이지에서는 코어의 실행 이벤트를 확인합니다. 구독 노드 목록을 보는 곳은 아닙니다. 일반적인 로그 레벨은 debug, info, warning, error이며, 설정에서 silent를 사용하면 일반 로그 출력을 끌 수 있습니다. 화면의 레벨 필터는 이미 기록된 항목 중 무엇을 표시할지 결정하고, 코어 설정의 log-level은 어떤 기록을 생성할지 결정합니다. 코어가 info 이상만 출력하도록 설정되어 있으면 화면에서 Debug를 선택해도 이전에 생성되지 않은 디버그 정보가 나타나지는 않습니다.

일상적인 사용에는 info면 충분합니다. 복잡한 문제를 재현해야 할 때는 코어 로그 레벨을 잠시 debug로 바꾸고 설정을 다시 불러온 뒤 같은 작업을 한 번 더 수행한 다음 원래대로 되돌리세요. 디버그 로그에는 도메인, IP, 연결 정보가 포함될 수 있으므로 공유 전에 구독 토큰과 인증 정보, 공개할 필요가 없는 접속 기록을 삭제하세요.

오류를 구체적인 작업과 연결해 확인하세요

  1. 예를 들어 14:32처럼 시간을 기록한 뒤 문제가 생긴 웹사이트에 한 번만 접속합니다.
  2. 로그 페이지에서 해당 시각 전후의 기록을 찾고 대상 도메인, 출구 이름, 오류 원인을 우선 확인합니다.
  3. 연결 페이지에서 매칭된 규칙과 프록시 체인을 확인해 예상한 노드를 통하는지 살펴봅니다.
  4. 노드 변경처럼 조건 하나만 바꾼 뒤 다시 접속해 결과를 비교합니다.
로그 내용일반적인 원인다음 단계
address already in use수신 주소 또는 포트가 이미 사용 중중복 실행된 코어를 종료하고 로컬 수신 포트를 확인하세요
connection refused대상에서 연결을 거부했거나 서비스가 수신 대기 중이 아님대상 주소와 포트, 서비스 상태를 확인하세요
i/o timeout연결 또는 데이터 송수신이 제한 시간 초과대상과 출구를 함께 확인하고 다른 노드와 비교하세요
DNS 조회 관련 오류이름 조회가 완료되지 않았거나 비정상적인 결과를 반환함DNS 설정과 DNS 서버에 접속할 수 있는지 확인하세요
설정 파싱 실패필드, 들여쓰기 또는 참조에 문제가 있음설정 페이지로 돌아가 오류가 난 줄과 필드 호환성을 확인하세요

오류 문구는 단서이지 유일한 진단 결과가 아닙니다. 예를 들어 시간 초과는 프록시 서버나 대상 사이트에서 발생할 수 있습니다. timeout이 한 번 표시됐다고 구독이 만료됐다고 단정하지 마세요. 발생 시각, 실패 범위, 비교 테스트를 함께 살펴봐야 합니다.

연결 페이지와 첫 사용 시 확인 순서

“이 사이트가 실제로 어떤 경로로 연결되는가?”를 확인할 때는 지연 시간 테스트보다 연결 페이지가 더 유용합니다. 일반적으로 대상 도메인 또는 IP, 송수신 데이터량, 매칭된 규칙, 프록시 체인을 표시합니다. 프로세스 이름은 플랫폼, 권한, 코어 설정에 따라 표시 여부가 달라집니다. 앱이 연결 페이지에 나타나지 않는다고 해서 클라이언트에 문제가 있다고 단정할 수는 없습니다. 새 연결이 아직 없거나 트래픽이 코어로 들어오지 않은 경우일 수 있습니다.

네 페이지를 차례로 확인해 연결을 점검하세요

  1. 설정 페이지: 대상 설정이 활성화되어 있고 불러오는 중 오류가 없는지 확인합니다.
  2. 프록시 페이지: 규칙 모드를 선택하고 대상 프록시 그룹의 출구를 사용할 수 있는지 확인합니다.
  3. 설정 페이지: 시스템 프록시를 켜고 로컬 포트를 확인합니다. 처음 점검할 때는 TUN을 동시에 켜지 마세요.
  4. 연결 페이지와 로그 페이지: 대상 사이트에 접속한 뒤 새 연결의 규칙과 출구를 확인하고 같은 시간대의 오류를 살펴봅니다.

브라우저는 정상인데 특정 앱만 작동하지 않는다면 먼저 해당 앱이 시스템 프록시를 따르는지 확인하세요. 필요하면 앱에 HTTP 또는 SOCKS 프록시를 별도로 설정한 다음 TUN 사용을 검토합니다. 모든 앱이 실패한다면 설정을 불러왔는지, 코어가 실행 중인지, 포트 충돌이 있는지부터 확인하고 마지막으로 노드와 DNS를 살펴보세요. 각 페이지의 역할에 따라 차례로 확인하면 구독을 계속 바꾸거나 클라이언트를 다시 설치하는 것보다 문제 범위를 빠르게 좁힐 수 있습니다.

클라이언트를 종료하기 전 시스템 프록시 설정이 원래대로 복구됐는지도 확인하세요. 프로그램이 비정상 종료된 뒤 브라우저에서 인터넷에 접속할 수 없다면 Windows에서는 「설정」→「네트워크 및 인터넷」→「프록시」에서 수동 프록시 항목을 확인할 수 있습니다. macOS에서는 「시스템 설정」→「네트워크」→현재 네트워크 서비스→「세부사항」→「프록시」를 확인하세요. 클라이언트가 남긴 로컬 프록시 설정만 정리하고 회사나 학교에서 요구하는 프록시 설정은 임의로 변경하지 마세요.