Clash 초보자 자주 묻는 질문: 구독 가져오기, 모드 선택과 연결 점검 10가지

클라이언트와 코어 선택 방법

1. Clash를 다운로드할 때 클라이언트 이름과 운영체제 버전 중 무엇을 먼저 확인해야 하나요?

먼저 운영체제와 프로세서 아키텍처를 확인한 뒤 클라이언트가 사용하는 코어를 살펴보세요. Clash는 프록시 설정과 규칙 체계를 통칭하는 이름으로 널리 쓰이며, 실제로 사용하려면 그래픽 클라이언트나 명령줄 프로그램이 필요합니다. Windows, macOS, Android, iOS와 Linux는 설치 방식이 서로 다르고, 같은 이름의 설치 패키지도 x64, ARM64 등 아키텍처별로 나뉠 수 있습니다.

일반적인 Windows PC는 대개 x64 설치 패키지를 사용하며, ARM 프로세서 기기는 ARM64 버전이 필요합니다. macOS는 Intel과 Apple Silicon도 구분해야 합니다. 호환되지 않는 패키지를 선택하면 설치되지 않거나, 실행 직후 종료되거나, 별도의 호환 변환이 필요할 수 있습니다. 아키텍처를 판단하기 어렵다면 기기 출시 연도가 아니라 시스템 정보의 ‘시스템 유형’ 또는 ‘칩’을 먼저 확인하세요.

코어의 경우 현재 유지 관리되는 클라이언트는 대체로 Mihomo를 사용합니다. Mihomo는 Clash Meta에서 이어져 발전한 코어로, 일반적인 Clash 설정 구조와 호환되며 프록시 프로토콜, 규칙, DNS와 TUN 기능을 확장합니다. 클라이언트 인터페이스와 코어는 서로 다른 계층입니다. 인터페이스는 구독 관리, 스위치와 로그 표시를 담당하고, 코어는 연결 수립, 규칙 실행과 트래픽 처리를 담당합니다. 따라서 클라이언트를 비교할 때는 코어 버전, 업데이트 상태와 설정 호환 범위도 함께 확인해야 합니다.

2. 설치를 마쳤는데도 왜 바로 인터넷에 접속할 수 없나요?

클라이언트 설치가 끝났다는 것은 프로그램을 실행할 수 있다는 뜻일 뿐, 프록시 연결이 이미 구축되었다는 의미는 아닙니다. 유효한 설정, 연결 가능한 노드, 그리고 앱의 트래픽을 Clash로 전달하는 접속 방식이 최소한 필요합니다. 가장 일반적인 순서는 구독 또는 로컬 설정 가져오기, 설정 업데이트, 프록시 노드 선택, 시스템 프록시 활성화 후 브라우저로 테스트하는 것입니다.

인터페이스에 빈 설정 페이지만 보이거나 프록시 그룹에 노드가 하나도 없다면 사용할 수 있는 원격 출구가 없는 상태입니다. 노드를 선택했더라도 시스템 프록시를 켜지 않으면 브라우저가 직접 연결할 수 있습니다. 일부 앱은 운영체제 프록시 설정을 무시하므로 일반 시스템 프록시만으로는 트래픽을 가로챌 수 없습니다. 이 경우 앱에서 프록시 주소를 별도로 입력하거나, 필요성을 확인한 뒤 TUN 모드를 활성화해야 합니다.

구독 가져오기와 업데이트 확인 방법

3. 구독 링크는 브라우저에 붙여넣어야 하나요, 아니면 클라이언트로 가져와야 하나요?

구독 주소는 클라이언트의 설정, 구독 또는 Profiles 페이지에 추가해야 합니다. 브라우저에서 링크를 여는 것은 서버가 콘텐츠를 반환하는지 확인하는 용도일 뿐, 클라이언트 가져오기를 대신할 수 없습니다. 서비스마다 YAML 설정, 인코딩된 노드 목록 또는 서버 변환이 필요한 전용 형식으로 응답할 수 있습니다. 클라이언트가 해당 구조를 인식해야 노드와 프록시 그룹을 생성할 수 있습니다.

가져올 때는 주소 전체를 복사하고 앞뒤 공백, 줄바꿈 또는 메신저가 덧붙인 문장 부호가 들어가지 않도록 하세요. 구독 링크에는 계정 식별에 사용되는 매개변수가 포함되는 경우가 많으므로 민감한 인증 정보처럼 취급해야 합니다. 공개 페이지, 스크린샷 또는 로그에 게시하지 마세요. 서비스에서 Clash 또는 Mihomo 전용 구독 항목을 제공한다면 다른 클라이언트 형식의 링크를 붙여넣지 말고 해당 항목을 우선 사용하세요.

가져오기가 끝나면 세 가지를 확인하세요. 설정 항목에 업데이트 시간이 표시되는지, 프록시 그룹에 노드가 있는지, 로그에 파싱 오류가 기록되지 않았는지 살펴봅니다. ‘다운로드 성공’만으로는 설정을 불러올 수 있다고 볼 수 없습니다. 다운로드는 성공했지만 YAML 구조가 호환되지 않으면 코어가 활성화를 거부할 수 있습니다.

4. 구독 업데이트가 실패하거나 업데이트 후에도 노드가 바뀌지 않는다면 무엇부터 확인해야 하나요?

먼저 ‘요청으로 콘텐츠를 받지 못한 경우’와 ‘콘텐츠는 받았지만 적용되지 않은 경우’를 구분하세요. 전자는 시간 초과, 연결 실패, 비정상적인 HTTP 상태로 나타나는 경우가 많고, 후자는 설정 파싱 오류, 빈 프록시 그룹 또는 이전 버전이 여전히 활성 설정으로 남아 있는 경우가 많습니다. 다음 순서로 확인해 보세요.

1. 기기 자체에서 구독 서버에 접속할 수 있는지 확인하고, 시스템 날짜·시간과 시간대가 정확한지 점검하세요.
2. 구독 주소 전체를 다시 복사하고 계정 상태와 구독 유효기간에 변동이 없는지 확인하세요.
3. 클라이언트 로그를 확인해 오류가 다운로드, 파싱 또는 설정 전환 중 어느 단계에서 발생했는지 판단하세요.
4. 업데이트가 끝난 뒤 새 설정이 목록에 저장만 된 것이 아니라 현재 활성 설정으로 지정되었는지 확인하세요.
5. 프록시 그룹 선택을 확인하세요. 설정을 업데이트하면 노드 목록이 다시 만들어질 수 있지만 프록시 그룹은 기존 선택을 유지하거나 기본 항목으로 돌아갈 수 있습니다.

자동 업데이트 주기는 클라이언트 또는 설정의 구독 제공자 매개변수에 따라 결정되며, 모든 클라이언트가 시작 즉시 새로 고침을 수행하는 것은 아닙니다. 수동 업데이트를 할 때도 빠르게 연속 클릭하지 마세요. 동시에 여러 요청을 보내면 서버 제한에 걸릴 수 있습니다. 업데이트 후 노드 이름이 같아 보여도 내용이 바뀌지 않았다는 뜻은 아닙니다. 서버 주소, 포트와 전송 매개변수는 이름을 유지한 채 변경될 수 있습니다.

완전한 원격 설정을 사용하면 업데이트 과정에서 로컬에서 직접 수정한 규칙이 덮어써질 수 있습니다. 오래 유지해야 하는 사용자 지정 규칙은 클라이언트가 지원하는 오버라이드, 병합 또는 스크립트 기능을 사용하고, 수정 전에 되돌릴 수 있도록 원본 설정을 보관하세요. 오버라이드 문법은 클라이언트마다 구현이 완전히 같지 않으므로 클라이언트를 바꿀 때 다시 검증해야 합니다.

Rule, Global, Direct와 TUN 사용법

5. Rule, Global, Direct 세 가지 모드는 어떻게 다른가요?

일상적인 사용에는 보통 Rule, 즉 규칙 모드를 선택합니다. 코어는 위에서 아래로 규칙을 확인하다가 일치하는 규칙을 찾으면 지정된 프록시 그룹에 연결을 넘기거나 직접 연결 또는 차단으로 처리합니다. 규칙은 도메인, 도메인 접미사, IP 대역, 프로세스 등의 조건으로 매칭할 수 있으며, 지원 범위는 코어와 클라이언트에 따라 다릅니다. 규칙 목록의 마지막에는 앞에서 일치하지 않은 요청을 처리하는 기본 항목이 있는 경우가 많습니다.

Global은 전역 모드입니다. Clash로 들어온 연결을 하나의 전역 프록시 그룹으로 처리하지만, 로컬 네트워크 주소나 코어가 보유한 연결 등은 설정과 구현에 따라 제한될 수 있습니다. 따라서 ‘전역’이 모든 규칙 경계를 우회한다는 뜻은 아닙니다. 규칙 분류 오류 때문에 특정 웹사이트에 접속할 수 없는지 임시로 확인하거나 짧은 시간 동안 출구를 통일할 때 유용하지만, 모든 문제를 해결하는 유일한 방법으로 사용하는 것은 권장하지 않습니다.

Direct는 직접 연결 모드입니다. 코어로 들어온 연결은 일반적으로 원격 프록시로 전달되지 않고 로컬 네트워크를 통해 직접 접속합니다. 프록시 노드가 문제의 원인인지 빠르게 확인할 때 사용할 수 있습니다. Direct에서도 접속할 수 없다면 문제는 로컬 네트워크, DNS, 대상 서비스 또는 앱 자체에 있을 가능성이 큽니다. Direct는 정상인데 Rule만 비정상이라면 규칙 매칭과 프록시 그룹을 계속 확인해야 합니다.

6. TUN 모드는 언제 켜야 하나요?

먼저 시스템 프록시를 사용하세요. 앱이 시스템 프록시를 읽지 않거나, 더 많은 유형의 트래픽을 가로채야 하거나, 여러 프로그램을 한꺼번에 처리해야 할 때만 TUN을 고려하면 됩니다. 시스템 프록시는 주로 운영체제 프록시 설정을 따르는 앱에 HTTP 또는 SOCKS 접속을 제공하고, TUN은 가상 네트워크 인터페이스를 통해 IP 트래픽을 받아 적용 범위가 더 넓은 편입니다. 대신 라우팅, DNS, 권한과 방화벽에 관한 변수가 추가됩니다.

TUN을 켜기 전에 일반 노드 테스트가 정상이고 Rule 모드에서 브라우저 연결이 작동하는지 먼저 확인하세요. 그렇지 않으면 TUN을 바로 활성화했을 때 ‘노드 문제’와 ‘가상 네트워크 카드 문제’가 겹칠 수 있습니다. Windows에서는 관리자 권한이나 서비스 설치가 필요할 수 있고, macOS에서는 네트워크 확장 권한을 요청할 수 있으며, Linux에서는 네트워크 장치 권한과 라우팅 규칙을 확인해야 합니다. 권한을 부여하지 않으면 인터페이스의 스위치는 켜져도 실제 인터페이스가 만들어지지 않을 수 있습니다.

TUN을 다른 VPN, 가상 머신 네트워크, 컨테이너 네트워크 또는 보안 프로그램과 함께 실행하면 라우팅 우선순위 충돌이 발생할 수 있습니다. 전체 네트워크가 끊기거나 로컬 네트워크 기기에 접근할 수 없거나 클라이언트를 종료한 뒤에도 이상이 계속되면 먼저 TUN을 끄고 다른 가상 네트워크 프로그램을 종료한 다음 시스템 네트워크를 다시 테스트하세요. DNS와 라우팅 매개변수를 한꺼번에 많이 수정하지 말고, 한 번에 하나만 바꿔야 어느 계층이 결과에 영향을 주었는지 판단할 수 있습니다.

노드, 시스템 프록시, DNS와 로그 점검

7. 노드 지연 시간은 정상인데 왜 웹페이지가 열리지 않나요?

지연 시간 테스트는 특정 테스트 방식으로 클라이언트가 응답을 받았다는 사실만 보여 줄 뿐, 대상 웹사이트 연결 전체를 보장하지는 않습니다. 클라이언트마다 TCP 핸드셰이크, HTTP 요청 또는 지정된 테스트 주소로 지연 시간을 측정할 수 있습니다. 테스트가 성공한 뒤에도 실제 접속은 노드 출구, 대상 웹사이트, DNS 해석, 규칙 분류와 전송 프로토콜 상태의 영향을 받을 수 있습니다.

접속할 때 로그에 해당 도메인이 나타나는지 먼저 확인하세요. 로그가 전혀 없다면 트래픽이 Clash로 들어오지 않았을 가능성이 크므로 시스템 프록시, 브라우저 프록시, TUN 상태 또는 앱 자체의 네트워크 설정을 점검해야 합니다. 로그에 도메인이 나타나지만 예상과 다른 프록시 그룹에 배정되었다면 규칙이나 프록시 선택이 문제입니다. 로그에 시간 초과, 핸드셰이크 실패 또는 연결 거부가 표시되면 같은 프록시 그룹의 다른 노드로 바꿔 단일 노드의 문제인지 비교해 보세요.

지연 시간 수치를 대역폭이나 안정성과 동일하게 볼 수도 없습니다. 지연 시간이 낮은 노드가 혼잡할 수 있고, 지연 시간이 높은 노드가 지속적인 전송에서는 더 안정적일 수도 있습니다. 노드를 선택할 때는 연결 성공률, 연속 접속 결과와 다운로드 속도를 함께 고려하고 목록에서 숫자가 가장 작은 항목만 고르지 마세요.

8. 시스템 프록시를 켰는데도 트래픽이 없을 때 어떤 포트를 확인해야 하나요?

먼저 클라이언트 설정의 프록시 수신 포트가 운영체제에 현재 입력된 포트와 같은지 확인하세요. 일반적인 설정에는 HTTP 포트, SOCKS 포트 또는 두 종류의 트래픽을 동시에 받는 mixed-port가 있습니다. 컨트롤러 포트는 클라이언트 인터페이스와 코어 간 통신에 사용되며 브라우저용 프록시 포트가 아니므로 혼용하면 안 됩니다.

예를 들어 아래 설정은 로컬 앱이 7890 혼합 포트에 연결할 수 있음을 뜻합니다. 로컬 네트워크 기기의 접속 허용 여부는 allow-lan과 수신 주소가 함께 결정합니다.

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

로컬에서만 사용할 때는 수신 범위를 좁게 유지하고, 문제를 확인한다는 이유로 로컬 네트워크 접속을 개방하지 마세요. 포트를 다른 프로그램이 사용 중이면 코어 로그에 대개 bind, listen 또는 address already in use와 같은 오류가 나타납니다. 이 경우 해당 프로그램을 종료하거나 포트를 바꾼 뒤 시스템 프록시 설정도 함께 업데이트하세요. YAML만 수정하고 설정을 다시 불러오지 않으면 현재 실행 중인 수신 포트는 바뀌지 않습니다.

브라우저 확장 프로그램, 개발자 도구와 다른 프록시 소프트웨어가 시스템 설정을 덮어쓸 수 있습니다. 문제를 해결할 때는 추가 프록시 진입점을 일시적으로 비활성화하고 한 가지 접속 방식만 남기세요. 그렇지 않으면 브라우저가 이전 포트에 연결하거나 ‘브라우저 프록시가 다른 프록시 프로그램을 가리키고, 다시 Clash로 전달되는’ 순환이 생길 수 있습니다.

9. 어떤 현상이 DNS 문제와 관련이 있나요?

IP 주소로는 서비스에 접속되지만 도메인으로는 실패하거나, 일부 도메인이 계속 비정상적인 주소로 해석되거나, 네트워크를 바꾼 뒤에도 이전 결과가 남아 있다면 DNS를 점검해야 합니다. Clash 설정은 코어가 DNS를 처리하도록 하고 fake-ip 또는 redir-host 등의 모드와 규칙을 연동할 수 있습니다. 구체적인 필드와 동작은 코어 버전에 따라 다릅니다. 초보자는 출처가 불분명한 대량의 DNS 설정을 그대로 복사하지 마세요. 수신 주소, 상위 DNS 유형과 강화 모드는 현재 접속 방식에 맞아야 합니다.

문제를 확인할 때는 먼저 로그의 도메인이 정상적으로 해석되었는지 보고, 운영체제의 DNS 요청이 Clash로 들어오는지도 확인하세요. 시스템 프록시는 앱이 만드는 프록시 연결을 주로 처리할 뿐, 모든 독립 DNS 요청을 가로챈다고 보장할 수 없습니다. TUN 모드에서는 DNS 하이재킹과 가상 주소 라우팅도 확인해야 합니다. Clash를 꺼도 해석이 계속 비정상이라면 운영체제의 DNS 캐시를 지우고 네트워크 연결을 다시 시작한 뒤 라우터나 로컬 네트워크가 제공하는 DNS가 정상인지 확인하세요.

fake-ip를 사용하면 앱에는 예약 주소 대역의 가상 결과가 보이고, 코어가 해당 주소를 도메인으로 다시 매핑해 규칙 매칭을 수행합니다. 이러한 가상 주소를 실제 서버 주소로 간주해 장기간 기록해서는 안 됩니다. 일부 로컬 네트워크 서비스, 게임 또는 특수한 DNS 동작에 의존하는 프로그램은 호환 목록에 추가해야 할 수 있지만, 로그와 실제 장애를 근거로 항목을 하나씩 추가하고 많은 도메인을 한 번에 제외하지 마세요.

10. 전혀 연결되지 않을 때 가장 효과적인 점검 순서는 무엇인가요?

효율적인 문제 해결은 클라이언트를 반복해서 재설치하는 것이 아니라 계층별로 진행하는 데 달려 있습니다. 변수가 가장 적은 상태에서 시작해 문제를 설정, 노드, 트래픽 접속, 규칙 또는 시스템 네트워크 중 어느 계층에 둘지 좁혀 보세요.

1. 로컬 네트워크 확인: Direct로 전환하거나 프록시를 잠시 끄고 일반 웹사이트에 직접 접속할 수 있는지 확인하세요. 기본 네트워크가 끊겨 있다면 먼저 Wi-Fi, 유선 네트워크 또는 모바일 네트워크를 복구하세요.
2. 설정 로드 확인: 현재 활성 설정의 이름과 업데이트 시간을 확인하고, 로그에 YAML 파싱 오류, 지원하지 않는 필드 또는 파일 읽기 오류가 있는지 살펴보세요.
3. 노드 연결 확인: 현재 프록시 그룹에 실제로 존재하는 노드를 하나 선택해 지연 시간 테스트를 실행하고, 웹페이지에 접속할 때 실시간 로그를 관찰하세요.
4. 트래픽 유입 확인: 시스템 프록시를 켠 뒤 운영체제 프록시 주소와 포트를 확인하세요. 요청 로그가 전혀 없다면 접속 문제를 우선 해결해야 합니다.
5. 규칙 결과 확인: Rule 모드에서 대상 도메인이 어떤 규칙에 매칭되었고 어느 프록시 그룹으로 전달되었는지 확인한 다음 해당 그룹의 현재 선택 항목을 점검하세요.
6. Global과 Direct 비교: Global은 규칙이 잘못된 출구를 선택했는지 판단하는 데 도움이 되고, Direct는 로컬 네트워크에서 직접 접속할 수 있는지 확인하는 데 도움이 됩니다.
7. 마지막으로 TUN과 DNS 확인: 기본 프록시 연결이 작동한 뒤에만 TUN, DNS 강화 기능과 앱별 호환 설정을 활성화하세요.

로그 수준은 보통 info면 초기 판단에 충분합니다. 더 자세한 위치를 확인해야 할 때는 잠시 로그 상세도를 높일 수 있지만, 로그에 접속 도메인, 노드 이름, 서버 주소와 로컬 네트워크 정보가 포함될 수 있습니다. 공유하기 전에 계정 매개변수와 민감한 설정을 삭제하세요. 문제 해결이 끝나면 일반 로그 수준으로 되돌려 불필요한 기록이 장기간 쌓이지 않도록 하세요.

수정 후 새 문제가 생겼다면 설정을 계속 덧붙이기보다 마지막으로 정상 작동했던 설정으로 돌아가는 편이 효율적입니다. 구독, 오버라이드 규칙, DNS와 TUN은 각각 따로 검증하세요. 먼저 원본 구독이 로드되는지 확인한 뒤 로컬 오버라이드를 추가하고, 시스템 프록시가 작동하는지 확인한 뒤 TUN을 활성화합니다. 이 순서를 따르면 ‘가져오기는 성공했지만 연결되지 않는’ 문제 대부분을 구체적인 단계로 좁힐 수 있습니다.