Clash 초보자 첫 주에 가장 많이 묻는 10가지: 구독 가져오기부터 시스템 프록시까지 한 번에 정리

1. 클라이언트 선택: Clash, Clash Meta, mihomo는 어떤 관계인가

질문 1: 어떤 Clash 클라이언트를 다운로드해야 하나요

정답부터 말하면, 먼저 사용 중인 운영체제에 맞춰 현재 유지 관리되고 그래픽 인터페이스를 제공하는 클라이언트를 선택한 다음, 현재 구독에서 사용하는 프로토콜을 지원하는지 확인하세요. Windows와 macOS 초보자는 설정 관리, 시스템 프록시, TUN 모드를 지원하는 데스크톱 클라이언트를 우선 선택하면 됩니다. Android에서는 설정 가져오기와 앱별 분할 라우팅을 지원하는 클라이언트가 적합합니다. 처음부터 여러 클라이언트를 동시에 설치할 필요는 없습니다. 한 기기에서 두 개의 프록시 프로그램을 실행하면 오히려 포트 충돌이 발생하기 쉽습니다.

“Clash”는 원래 Clash 코어를 가리킬 수도 있고, Clash 설정 형식을 사용하는 클라이언트를 통칭할 수도 있습니다. 원본 프로젝트는 이미 업데이트가 중단되었으며, 현재 많이 사용되는 클라이언트는 대부분 mihomo 코어를 사용합니다. mihomo는 한때 Clash Meta라는 이름으로 불렸고, 설정 구조는 Clash YAML을 계승하면서 프로토콜, 규칙 집합, DNS, 투명 프록시 기능을 확장했습니다. “Meta 코어” 또는 “mihomo 코어”라는 표현을 보면 같은 기술 계열을 시기별로 다르게 부르는 이름이라고 이해하면 됩니다.

기본적인 웹 프록시만 필요한 경우: 그래픽 클라이언트, 규칙 모드, 시스템 프록지만으로 대부분의 작업을 처리할 수 있습니다.
게임 런처, 명령줄 또는 스토어 앱이 필요한 경우: TUN 모드를 지원하는 클라이언트를 선택하세요.
기존 YAML을 가져와야 하는 경우: 구독 링크뿐 아니라 로컬 설정 파일도 지원하는지 확인하세요.
기기 아키텍처가 다른 경우: Windows에서는 x64와 arm64가 일반적입니다. Apple Silicon Mac은 arm64, Intel Mac은 x64를 선택하세요.

2. 구독 링크 확인 및 올바른 가져오기 방법

질문 2: 클라이언트 설치 후 노드가 표시되지 않는 이유는 무엇인가요

Clash 클라이언트는 일반적으로 설정을 읽고, 규칙을 실행하며, 연결을 전달하는 역할만 합니다. 사용 가능한 노드를 자동으로 생성하지는 않습니다. 노드 정보는 사용자가 보유한 서비스 설정, 조직 내부 설정 또는 네트워크 서비스 제공업체가 발급한 구독 주소에서 가져옵니다. 구독 주소는 대개 HTTPS로 시작하는 전용 URL이며 접근 토큰이 포함될 수 있습니다. 계정 자격 증명처럼 관리하고 스크린샷, 포럼 또는 공개 코드 저장소에 올리지 마세요.

일반적인 가져오기 경로는 「설정」→「새 설정」→「URL에서 가져오기」입니다. 일부 클라이언트에서는 「Profiles」→「New Profile」→「URL」로 표시됩니다. 구독 주소를 붙여 넣은 뒤 먼저 다운로드를 실행하고, 새 설정을 현재 설정으로 지정하세요. 설정이 목록에 보인다고 해서 활성화된 것은 아닙니다. 해당 설정 옆에 “현재 사용 중”, “선택됨” 또는 선택 표시가 나타나는지 확인해야 합니다.

전체 구독 주소를 복사하고 시작 부분이 https://인지 확인하세요.
클라이언트의 「설정」 또는 「Profiles」 페이지로 이동하세요.
「URL에서 가져오기」를 선택한 뒤 주소를 붙여 넣고 다운로드하세요.
방금 다운로드한 설정을 선택하고 프록시 그룹과 노드 목록이 표시될 때까지 기다리세요.
「프록시」 페이지로 이동해 대상 정책 그룹에서 노드를 선택하세요.
홈으로 돌아가 「시스템 프록시」를 켠 다음 브라우저에서 접속을 테스트하세요.

질문 3: 구독 가져오기 또는 업데이트에 실패하면 어떻게 해야 하나요

먼저 “주소를 다운로드할 수 없음”과 “다운로드 후 파싱할 수 없음”을 구분하세요. 전자는 대개 시간 초과, HTTP 401, 403 또는 404로 나타납니다. 후자는 YAML 파싱 오류, 필드 형식 오류 또는 설정 검증 실패로 표시되는 경우가 많습니다. 401과 403은 토큰 만료, 계정 상태 변경 또는 서버 측 제한일 가능성이 높고, 404는 주소가 변경되었을 수 있습니다. 파싱 오류라면 구독에서 Clash 또는 mihomo가 인식할 수 있는 설정 형식을 출력하는지 확인하세요.

화면에 표시되는 안내	일반적인 원인	처리 순서
Request timeout	현재 네트워크에서 구독 서버에 접속할 수 없음	다른 네트워크로 테스트한 뒤 시스템 시간과 DNS를 확인하세요
401 / 403	구독 토큰 또는 계정 상태 이상	구독 주소를 다시 발급받고 토큰을 직접 수정하지 마세요
YAML parse error	응답 내용이 유효한 YAML이 아님	구독 출력 형식을 확인하고 오류가 발생한 줄 번호를 확인하세요
설정은 있지만 노드가 비어 있음	구독 내용이 비어 있거나 설정 유형이 맞지 않음	원본 응답과 클라이언트 코어의 호환성을 확인하세요

처음 가져올 때는 자동 업데이트, 설정 오버라이드, 스크립트 처리를 동시에 켜지 마세요. 먼저 원본 설정이 정상적으로 로드되는지 확인한 다음 기능을 하나씩 추가하세요. 브라우저에서 구독 주소를 직접 열었을 때 로그인 페이지나 HTML 오류 페이지가 표시된다면 클라이언트 역시 이를 YAML로 파싱할 수 없습니다. 구독 주소는 유효하지만 클라이언트에서 계속 오류가 발생하면 「설정」→「로그」에서 로그 수준을 잠시 debug로 바꾸고 한 번 재현한 뒤 실패 단계를 확인하세요. 문제 해결이 끝나면 info로 되돌리세요.

3. 규칙, 전체, 직접 연결 모드 중 무엇을 선택해야 하나요

질문 4: Rule, Global, Direct의 차이는 무엇인가요

Rule 규칙 모드는 설정에 정의된 규칙에 따라 도메인, IP, 프로세스 또는 규칙 집합을 하나씩 매칭한 뒤 연결을 지정된 정책 그룹으로 전달합니다. 일상적인 사용에 적합하며 대부분의 구독 설정에서 기본 모드로 사용됩니다. 중국 본토 사이트는 직접 연결하고, 프록시가 필요한 대상은 프록시 정책으로 보내며, 로컬 네트워크 주소는 보통 직접 연결로 유지합니다.

Global 전체 모드는 대부분의 연결을 GLOBAL이라는 정책 그룹으로 전달하며, 특정 노드로 연결할 수 있는지 임시로 확인할 때 적합합니다. 그렇다고 모든 트래픽이 반드시 로컬 네트워크를 벗어나는 것은 아닙니다. 로컬 네트워크, 예약 주소, 클라이언트 자체 연결은 여전히 코어 규칙에 따라 처리될 수 있습니다. 전체 모드를 장기간 사용하면 구독에서 설계한 분할 라우팅 로직을 우회하게 됩니다.

Direct 직접 연결 모드는 프록시 노드를 거치지 않고 대상에 직접 연결합니다. 프록시 경로가 문제의 원인인지 확인하거나 전달 기능을 잠시 중지할 때 적합합니다. Direct는 클라이언트를 종료하는 기능이 아닙니다. 시스템 프록시가 여전히 로컬 포트를 가리키고 있다면 트래픽은 먼저 클라이언트에 도달한 뒤 클라이언트가 직접 연결합니다.

일상적인 사용에서는 「모드」→「규칙」을 선택하세요.
「프록시」→대상 정책 그룹으로 이동해 지연 시간 테스트에 성공한 노드를 선택하세요.
특정 웹사이트에 문제가 생기면 전체 모드로 잠시 전환해 비교하세요.
전체 모드에서는 작동하지만 규칙 모드에서 실패한다면 규칙 매칭 결과와 정책 그룹 선택을 우선 확인하세요.
전체 모드에서도 실패한다면 노드, 네트워크, 포트, DNS를 우선 확인하세요.

연결이 어떤 규칙에 매칭되었는지 확인하는 방법

「연결」 또는 「Connections」 페이지를 열고 대상 웹사이트에 다시 접속한 다음 도메인으로 필터링하세요. 기록에는 일반적으로 대상 호스트, 대상 포트, 업로드·다운로드량, 매칭된 규칙, 실제 정책 경로가 표시됩니다. 예를 들어 기록에 DOMAIN-SUFFIX가 Proxy에 매칭되고 현재 Proxy에서 특정 노드를 선택한 상태라면 분할 라우팅 경로를 확인할 수 있습니다. MATCH → DIRECT로 표시되면 마지막 기본 규칙이 연결을 직접 연결로 전달했다는 뜻입니다.

4. 시스템 프록시는 켜져 있는데 브라우저가 연결되지 않는 이유

질문 5: 시스템 프록시 스위치는 실제로 무엇을 하나요

시스템 프록시 스위치는 보통 운영체제의 HTTP 및 HTTPS 프록시 주소를 127.0.0.1과 로컬 포트로 설정합니다. 예를 들어 설정에 mixed-port: 7890이 있다면 시스템 프록시는 127.0.0.1:7890을 가리킵니다. 애플리케이션이 이 설정을 따르는지는 애플리케이션 자체에 달려 있습니다. 주요 브라우저는 대체로 시스템 프록시를 읽지만, 일부 게임, 터미널 프로그램, 스토어 앱 및 자체 네트워크 스택을 사용하는 소프트웨어는 이를 무시할 수 있습니다.

원인을 노드 교체로 가리지 않도록 다음 순서대로 확인하세요:

클라이언트 홈에서 코어 상태가 실행 중인지 확인하세요. 인터페이스만 실행된 상태가 아니어야 합니다.
「설정」→「포트 설정」으로 이동해 Mixed Port의 실제 값을 확인하세요.
시스템 프록시 주소가 해당 포트와 일치하는지 확인하세요. 예: 127.0.0.1:7890
「연결」 페이지를 열고 브라우저를 새로 고친 뒤 새 연결이 나타나는지 확인하세요.
연결은 있지만 접속에 실패한다면 규칙 매칭, 노드, DNS를 확인하세요.
연결이 전혀 없다면 브라우저 프록시 확장 프로그램, 시스템 프록시 덮어쓰기, 애플리케이션 자체 설정을 확인하세요.

브라우저에 프록시 확장 프로그램이 함께 설치되어 있으면 확장 프로그램이 시스템 프록시를 덮어쓸 수 있습니다. 문제를 확인하는 동안 확장 프로그램을 “시스템 프록시 사용”으로 바꾸거나 잠시 비활성화하세요. 명령줄 도구는 환경 변수를 읽을 수도 있습니다. Windows PowerShell에서는 HTTP_PROXY와 HTTPS_PROXY를 확인하고, macOS 또는 Linux 터미널에서는 env | grep -i proxy를 실행할 수 있습니다. 이전 변수가 다른 포트를 계속 가리키면 브라우저는 정상인데 터미널만 실패하는 현상이 발생합니다.

질문 6: 언제 TUN 모드를 켜야 하나요

TUN 모드는 가상 네트워크 인터페이스를 통해 더 많은 시스템 트래픽을 수신합니다. 시스템 프록시를 무시하는 애플리케이션, UDP 트래픽, 일부 게임 런처, 트래픽을 일괄적으로 가로채야 하는 명령줄 프로그램에 적합합니다. TUN은 “속도 향상” 스위치가 아닙니다. 브라우저와 일반 데스크톱 앱만 사용한다면 시스템 프록시가 대체로 관리하기 쉽습니다. 대상 애플리케이션이 시스템 프록시를 읽지 않는다는 사실을 확인한 뒤 TUN을 활성화하는 편이 좋습니다.

일반적인 경로는 「설정」→「네트워크 설정」→「TUN 모드」입니다. 처음 켤 때 관리자 권한이 필요하거나 가상 네트워크 구성 요소를 설치해야 할 수 있습니다. 활성화한 뒤 클라이언트에서 TUN이 정상적으로 실행 중인지 확인하고, 시스템에 다른 VPN, 가상 네트워크 카드 도구 또는 이전 클라이언트가 라우팅을 동시에 사용하고 있지 않은지 확인하세요. Windows에서 활성화에 실패하면 클라이언트를 완전히 종료한 뒤 관리자 권한으로 한 번 실행해 서비스 설치를 완료해 보세요. 이후에도 관리자 권한이 필요한지는 클라이언트의 서비스 구현에 따라 달라집니다.

5. 노드 시간 초과, 포트 충돌, DNS 문제 확인 방법

질문 7: 지연 시간 테스트에 Timeout이 표시되면 노드를 반드시 사용할 수 없다는 뜻인가요

반드시 그렇지는 않습니다. 지연 시간 테스트는 보통 설정에 지정된 테스트 URL에 요청을 보내고 고정된 시간 제한을 적용합니다. 테스트 주소에 연결할 수 없거나, 노드가 해당 대상에 대한 접속을 허용하지 않거나, DNS 조회가 실패하거나, 로컬 네트워크에서 패킷 손실이 발생해도 Timeout이 표시될 수 있습니다. 최소한 다음 세 가지를 교차 검증하세요. 설정을 업데이트하고, 서로 다른 지역의 노드 두 개로 전환하며, HTTPS를 명확히 지원하는 대상에 브라우저로 접속해 보세요.

지연 시간 수치는 다운로드 속도도 아닙니다. 한 번의 테스트에서 80ms가 나왔다면 당시 해당 테스트 요청이 약 80밀리초 만에 완료되었다는 뜻일 뿐, 지속적인 처리량을 의미하지는 않습니다. 세 번 연속으로 85ms, 92ms, 410ms가 측정되었다면 회선 변동이 큰 상태입니다. 동영상과 일반 웹페이지에서는 안정적인 140ms 노드가 400ms까지 자주 튀는 저지연 노드보다 실제로 더 사용하기 좋을 수 있습니다.

모든 노드에서 동시에 시간 초과가 발생함: 먼저 구독 상태, 로컬 네트워크, DNS, 클라이언트 로그를 확인하세요.
한 노드에서만 시간 초과가 발생함: 같은 그룹의 다른 노드로 전환한 뒤 잠시 후 다시 테스트하세요.
지연 시간 테스트는 정상인데 웹페이지가 열리지 않음: 규칙 매칭, 브라우저 프록시, 대상 사이트 제한을 확인하세요.
TCP 페이지는 정상인데 게임이 실패함: 클라이언트가 UDP를 인계하는지, TUN 설정이 적용되었는지 확인하세요.

질문 8: “포트 7890이 사용 중입니다”라는 메시지가 표시되면 어떻게 해야 하나요

다른 프로세스가 같은 포트를 이미 사용 중이라는 뜻입니다. 흔한 원인은 이전 클라이언트가 백그라운드에서 계속 실행 중이거나, 같은 클라이언트가 두 번 실행되었거나, 다른 네트워크 도구가 7890을 사용 중인 경우입니다. 포트를 계속 바꾸기 전에 먼저 어떤 프로세스가 사용 중인지 확인하세요. Windows에서는 명령 프롬프트에서 다음 명령을 실행할 수 있습니다:

netstat -ano | findstr :7890
tasklist /fi "PID eq 프로세스 번호"

macOS와 Linux에서는 다음 명령을 사용할 수 있습니다:

lsof -nP -iTCP:7890 -sTCP:LISTEN
lsof -nP -iUDP:7890

이전 인스턴스가 원인이라면 해당 프로세스를 정상적으로 종료한 뒤 현재 클라이언트를 다시 시작하세요. 포트를 반드시 다른 프로그램이 사용해야 한다면 「설정」→「포트 설정」에서 Mixed Port를 7891 또는 사용하지 않는 다른 포트로 변경하세요. 변경 후에는 시스템 프록시도 새 포트를 가리키도록 반드시 갱신해야 합니다. YAML을 직접 관리하는 경우 해당 설정은 다음과 같이 작성할 수 있습니다:

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

allow-lan: false는 로컬 네트워크 기기에 프록시 진입점을 제공하지 않는다는 뜻입니다. 휴대폰에서 컴퓨터의 프록시를 사용해야 한다면 로컬 네트워크 접근을 활성화하고 운영체제 방화벽 및 신뢰할 수 있는 네트워크 범위를 함께 설정하세요. 수신 포트만 변경해서는 안 됩니다.

질문 9: 웹페이지는 열리지만 도메인 조회가 느리거나 DNS 오류가 발생하면 어떻게 해야 하나요

Clash 또는 mihomo의 DNS 모듈은 규칙 매칭과 연결 수립 사이에서 도메인 조회를 조정합니다. 대표적인 향상 모드로 fake-ip와 redir-host가 있습니다. fake-ip은 먼저 예약 주소 매핑을 반환한 뒤 코어가 원래 도메인을 복원합니다. 규칙 매칭 효율이 높고 TUN 인계에도 적합하지만, 일부 로컬 네트워크 기기, 기업용 소프트웨어 또는 실제 IP에 의존하는 프로그램은 fake-ip-filter에 추가해야 할 수 있습니다.

문제의 원인을 확인하기 전에는 DNS 서버를 여러 개 겹쳐 설정하지 마세요. 먼저 안정적인 조회 경로 두 개만 사용하고 로그에 시간 초과가 발생하는지 관찰하세요. 기본 구조는 다음과 같지만 실제 설정은 현재 클라이언트와 구독 요구 사항을 따라야 합니다:

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"
    - "+.stun.*.*"

설정을 변경한 뒤 「설정」→「다시 불러오기」를 실행하고 애플리케이션 자체 캐시를 삭제한 다음 다시 테스트하세요. Windows에서는 ipconfig /flushdns를 실행해 시스템 DNS 캐시를 삭제할 수 있고, macOS에서는 대상 애플리케이션을 종료했다가 다시 열면 됩니다. 클라이언트 로그에 DNS timeout이 계속 나타난다면 fallback 수를 늘리기보다 현재 네트워크에서 입력한 DNS 서버에 연결할 수 있는지 먼저 테스트하세요.

6. 설정 업데이트, 자동 선택, 장애 복구

질문 10: 첫 주가 끝나기 전에 어떤 설정을 유지해야 하나요

먼저 최소 재현 상태를 유지하세요. 유효한 구독 하나, 현재 설정 하나, 규칙 모드, 사용 가능 여부를 확인한 노드 하나, 올바른 로컬 포트, 그리고 시스템 프록시 또는 TUN 중 명확히 선택한 트래픽 인계 방식이 필요합니다. 여러 자동 선택 스크립트, 원격 규칙 오버라이드, 실험적인 DNS 옵션을 동시에 켜지 마세요. 기본 경로가 안정된 뒤 자동 업데이트, 지연 시간 테스트, 규칙 집합 기능을 추가하세요.

구독 자동 업데이트 간격을 지나치게 짧게 설정하지 마세요. 노드 정보는 보통 1분마다 갱신할 필요가 없으므로 6시간, 12시간 또는 24시간으로 설정하는 편이 상태를 관찰하기 쉽습니다. 클라이언트가 절전 모드에서 깨어나 네트워크가 복구되면 설정을 한 번 수동으로 업데이트할 수 있습니다. 업데이트에 실패하더라도 현재 사용 가능한 설정을 바로 삭제하지 마세요. 이전 설정으로 연결이 유지될 수 있습니다. 먼저 로그의 HTTP 상태 코드를 확인한 다음 구독 주소를 다시 발급받을지 결정하세요.

기록해 두면 좋은 6가지 정보

클라이언트 이름, 버전, 시스템 아키텍처. 예: Windows 11 x64
코어 이름과 버전. 예: mihomo 1.19.x
현재 모드: Rule, Global 또는 Direct
트래픽 진입점: 시스템 프록시, TUN 또는 애플리케이션 내 수동 프록시
Mixed Port 실제 값. 예: 7890 또는 7891
장애 발생 시간, 로그 오류 줄, 매칭된 정책 그룹

이 6가지 정보가 있으면 단순히 “연결되지 않는다”고 말하는 것보다 문제를 훨씬 쉽게 좁힐 수 있습니다. 예를 들어 Windows 11 x64, mihomo 1.19.x, 규칙 모드, 시스템 프록시, mixed-port 7890, 브라우저 연결은 Proxy에 매칭되지만 로그에는 connection timeout이 표시된다고 기록할 수 있습니다. 이 정보만으로도 클라이언트를 반복해서 재설치하지 않고 노드 경로로 범위를 바로 좁힐 수 있습니다.

5분 안에 끝내는 고정 문제 해결 순서

코어 확인: 실행 상태를 확인하고 로그에 설정 로드 실패가 없는지 확인하세요.
진입점 확인: 시스템 프록시 포트 또는 TUN 인계 상태를 확인하세요.
연결 확인: 대상 애플리케이션을 새로 고치고 Connections에 기록이 나타나는지 확인하세요.
규칙 확인: 기록에 표시된 규칙, 정책 그룹, 최종 노드를 확인하세요.
출구 확인: 다른 노드로 전환해 전체 모드와 규칙 모드의 결과를 비교하세요.

Direct에서는 접속되지만 Rule에서 실패하고 Connections에 요청이 잘못된 정책 그룹으로 들어간 기록이 있다면 규칙 또는 정책 그룹 선택을 수정하세요. Direct와 프록시 모두 실패한다면 로컬 네트워크와 DNS를 다시 확인하세요. 브라우저에는 연결 기록이 있지만 대상 애플리케이션에는 기록이 전혀 없다면 해당 애플리케이션이 시스템 프록시를 읽는지 확인하고 TUN 사용 여부를 결정하세요. 진입점, 규칙, 출구를 단계별로 확인하는 편이 설정을 삭제하고 재설치하는 것보다 유효한 단서를 보존하기 쉽습니다.