Clash 초보자 필수 FAQ 10가지: 클라이언트 선택부터 시스템 프록시 설정, 웹사이트 접속 오류까지

1. Clash, 클라이언트, mihomo 코어는 각각 무엇인가요?

먼저 운영체제에 맞는 클라이언트를 고르고, 코어와 구독 설정의 호환성을 확인하세요. 클라이언트는 구독 관리, 프록시 선택, 설정 화면을 제공하고, 코어는 설정을 읽고 규칙을 적용해 연결을 처리합니다. 클라이언트를 설치했다고 사용할 수 있는 프록시 서버까지 제공되는 것은 아닙니다. 사용 권한이 있는 구독이나 설정을 직접 가져와야 합니다.

Clash는 이 도구 및 설정 생태계에서 널리 쓰이는 이름입니다. 원래 Clash 코어와 이후 포크 버전이 같은 기능을 제공한다고 볼 수는 없습니다. Clash Meta는 나중에 mihomo로 이름이 바뀌었으며, 새 프로토콜·규칙·DNS 기능의 지원 여부는 실제 사용하는 코어 버전에 따라 달라집니다. 클라이언트 이름에 Clash가 들어 있다고 해서 어떤 코어를 쓰는지 판단할 수는 없습니다.

Windows: 설정 관리 기능을 갖춘 데스크톱 클라이언트인 Clash Verge Rev부터 사용해 볼 수 있습니다. 설치 전에 「설정」→「시스템」→「시스템 정보」에서 시스템 종류를 확인하고 x64와 ARM64 중 맞는 설치 파일을 선택하세요.
macOS: Apple 메뉴→「이 Mac에 관하여」에서 Apple 칩인지 Intel인지 확인한 다음 해당하는 설치 파일을 고르세요. 클라이언트가 지원하는 최소 macOS 버전도 확인해야 합니다.
Android: 유지 관리 상태, 코어, 시스템 요구 사항을 명확히 안내하는 클라이언트를 선택하세요. 예를 들면 Clash Meta for Android가 있습니다. 설치 파일 아키텍처가 기기와 호환되는지도 확인하세요.
iOS: 클라이언트가 실제로 지원하는 구독 형식에 맞춰 선택하세요. 모든 프록시 앱이 Clash YAML을 그대로 가져올 수 있는 것은 아닙니다.

설치 파일은 클라이언트 다운로드 페이지에서 확인하세요. 설정 파일의 항목을 인식하지 못한다면 클라이언트 버전, 코어 이름, 오류가 난 줄 번호를 기록한 뒤 호환성을 확인하세요. 모르는 항목을 곧바로 삭제하지 마세요.

2. 구독 링크는 어떻게 가져오나요? 붙여넣은 뒤 형식 오류가 나는 이유는 무엇인가요?

구독 URL은 설정을 가져오는 주소이지 클라이언트 자체가 아니며, 반드시 Clash 설정을 반환하는 것도 아닙니다. 데스크톱 클라이언트의 「구독」 또는 「프로필」 화면에서 URL 가져오기 기능을 찾아 전체 링크를 붙여넣고 다운로드한 뒤 해당 설정을 선택하세요. Clash Verge Rev의 일반적인 화면에서는 「구독」 페이지의 링크 입력란에 URL을 붙여넣고 「가져오기」를 누르면 됩니다. 메뉴 문구는 버전에 따라 다를 수 있습니다.

구독 제공업체에서 Clash 또는 mihomo용 링크를 복사하고, 쿼리 매개변수는 그대로 유지하세요. 따옴표나 공백을 덧붙이지 마세요.
가져온 뒤에는 설정이 목록에만 보이는 것이 아니라 실제로 활성화됐는지 확인하세요.
프록시 페이지에서 선택 가능한 정책 그룹 항목이 있는지 확인하세요. 설정 이름만 표시되고 리소스가 아직 로드되지 않았을 수도 있습니다.
로컬 .yaml 또는 .yml 파일이라면 파일 가져오기를 사용하세요. 디스크 경로를 구독 URL로 입력하면 안 됩니다.

일반적인 전체 설정 파일에는 proxies, proxy-groups, rules 같은 항목이 있으며, proxy-providers로 외부 리소스를 참조할 수도 있습니다. ss://, vmess:// 같은 공유 링크나 Base64로 인코딩된 노드 목록만으로는 보통 완전한 YAML 설정으로 바로 불러올 수 없습니다.

3. 시스템 프록시를 켜면 어떤 프로그램이 프록시를 사용하나요?

시스템 프록시는 해당 설정을 따르는 앱에만 적용되며, 기기의 모든 연결을 가로채는 기능은 아닙니다. 데스크톱 브라우저는 보통 시스템 설정을 따르지만, 명령줄 도구·게임·자체 네트워크 요청을 구현한 프로그램은 따르지 않을 수 있습니다. 클라이언트에 시스템 프록시가 켜져 있다고 표시되더라도 모든 트래픽이 코어를 거친다는 뜻은 아닙니다.

주소와 수신 포트부터 확인

아래 예시는 클라이언트가 실제로 mixed-port: 7890에서 요청을 수신하는 경우입니다. 이 포트는 HTTP와 SOCKS 프록시 요청을 받을 수 있습니다. 7890은 예시일 뿐, 모든 클라이언트의 고정값이 아닙니다. Windows 11에서는 「설정」→「네트워크 및 인터넷」→「프록시」에서 수동 프록시 주소가 127.0.0.1인지, 포트가 클라이언트 설정과 일치하는지 확인하세요.

클라이언트가 시스템 프록시를 자동으로 관리한다면 클라이언트의 스위치로 설정하세요. 시스템 설정과 클라이언트가 서로 값을 덮어쓰지 않도록 주의해야 합니다. 테스트할 때는 프록시 클라이언트를 하나만 실행하고, 브라우저에서 별도의 프록시 서버를 지정하는 확장 프로그램은 꺼 두세요.

브라우저에서는 접속되지만 터미널에서는 안 된다면 노드를 바로 바꾸지 말고 터미널 프로그램에 프록시가 설정되어 있는지 확인하세요.
모든 브라우저에서 접속되지 않는다면 코어 실행 여부, 포트 수신 상태, 설정 유효성을 확인하세요.
클라이언트를 종료한 뒤 웹페이지가 열리지 않는다면 시스템 프록시가 이미 수신을 중단한 로컬 포트를 가리키는지 확인하세요.

4. TUN 모드와 시스템 프록시는 무엇이 다르며, 둘 다 켜야 하나요?

TUN은 가상 네트워크 인터페이스와 라우팅을 통해 트래픽을 연결하며, 시스템 프록시가 적용되지 않는 상황에 유용합니다. 데스크톱에서는 보통 적절한 권한과 서비스 또는 드라이버가 필요합니다. Android에서는 대개 클라이언트가 시스템 VPN 인터페이스를 통해 트래픽을 연결합니다. TUN은 노드 속도를 높이는 기능이 아니며, 만료된 구독이나 연결할 수 없는 원격 서버 문제도 해결하지 못합니다.

방식	주요 연결 경로	처음 사용할 때 권장 사항
시스템 프록시	앱이 시스템 HTTP 등 프록시 설정을 따름	먼저 브라우저로 구독을 가져왔는지와 노드가 작동하는지 확인
TUN 모드	가상 인터페이스와 라우팅·DNS 설정을 통해 연결	그다음 시스템 프록시를 따르지 않는 앱을 테스트

일부 클라이언트에서는 두 방식을 함께 사용할 수 있지만, 초보자가 문제를 찾을 때는 한 번에 한 항목만 바꾸는 것이 좋습니다. 먼저 TUN을 끄고 시스템 프록시로 브라우저가 작동하는지 확인하세요. 그런 다음 클라이언트 안내에 따라 서비스를 설치하고 권한을 허용한 뒤 TUN을 켜세요. TUN을 켰을 때만 문제가 생긴다면 노드 탓으로만 돌리지 말고 라우팅, DNS, 다른 VPN, 가상 네트워크 어댑터와의 충돌을 확인하세요.

회사 VPN, 다른 프록시 클라이언트, 가상화 소프트웨어가 라우팅을 바꿀 수 있습니다. 테스트 전에 해당 프로그램의 상태를 기록하세요. TUN을 켜려고 시스템 네트워크 어댑터를 임의로 삭제하거나 보안 기능을 통째로 끄지 마세요.

5. 규칙·전역·직접 연결 모드 중 무엇을 선택해야 하나요?

일상적인 사용은 보통 규칙 모드로 시작한 뒤, 어떤 정책 그룹이 선택됐는지 확인하면 됩니다. 모드는 코어가 연결 경로를 선택하는 방식을 정하고, 정책 그룹은 특정 규칙에 따라 프록시 또는 직접 연결 중 무엇을 사용할지 정합니다.

규칙 모드(rule): 규칙 목록을 위에서 아래로 확인하며, 보통 처음 일치하는 규칙에 따라 연결 경로가 결정됩니다. 마지막의 MATCH는 흔히 기본 처리 규칙으로 사용됩니다.
전역 모드(global): 전역 정책을 사용해 연결 경로를 선택합니다. 전역 그룹에서 실제로 어떤 항목이 선택됐는지 확인해야 합니다. 모드를 바꿨다고 트래픽이 원격 노드를 통과한다고 단정할 수는 없습니다.
직접 연결 모드(direct): 코어가 원격 프록시 서버를 거치지 않고 대상에 직접 연결합니다.

전역 모드에서는 열리지만 규칙 모드에서는 열리지 않는 사이트가 있다면 연결 기록에서 도메인, 일치한 규칙, 정책 경로를 확인하세요. 예를 들어 해당 도메인에 DIRECT가 적용됐는데 현재 네트워크에서 직접 연결이 실패한다면 관련 분기 규칙을 점검해야 합니다. 사이트 하나를 고치려고 전체 트래픽을 계속 전역 모드로 보내지는 마세요.

사용자 지정 규칙의 저장 방식도 확인해야 합니다. 다운로드한 구독 설정을 직접 수정하면 다음 업데이트 때 변경 사항이 덮어써질 수 있습니다. 클라이언트가 지원하는 오버라이드 또는 병합 기능을 사용하고, 업데이트 후 실제 적용된 설정을 다시 확인하세요. 자세한 항목은 전체 설정 가이드를 참고하세요.

6. 노드 지연 시간은 짧은데 웹페이지가 느린 이유는 무엇인가요?

지연 시간 테스트는 특정 테스트 요청의 결과만 보여 줍니다. 다운로드 속도, 지속적인 처리량, 대상 사이트의 접속 가능성을 보장하지는 않습니다. 예를 들어 목록에 45 ms라고 표시되어도 클라이언트의 측정 방식으로 그 순간 해당 값이 나왔다는 뜻일 뿐, 대용량 파일이 특정 속도로 다운로드된다는 보장은 없습니다. 이 수치는 판단 방법을 설명하기 위한 예시이며, 이 사이트에서 직접 측정한 결과가 아닙니다.

조건을 고정해 비교

대상 사이트 하나, 같은 연결 방식, 같은 시간대를 정한 뒤 노드 두 개를 각각 테스트하세요.
각 노드를 3회 반복 테스트하고 성공 여부, 페이지 로딩이 시작되기까지 걸린 시간, 연결이 도중에 끊기는지 기록하세요.
백그라운드 다운로드와 클라우드 동기화를 일시 중지하세요. 그런 다음 다른 사이트도 비교해 특정 사이트 문제인지 전반적인 문제인지 구분하세요.
노드는 그대로 둔 채 Wi-Fi와 휴대폰 핫스팟을 비교해 로컬 네트워크가 영향을 주는지 확인하세요.

테스트가 시간 초과됐다고 해서 노드를 전혀 사용할 수 없다는 뜻은 아닙니다. 테스트 URL에 접속할 수 없거나 테스트 요청과 실제 대상에 접속하는 경로가 다를 수 있습니다. 반대로 속도 테스트가 성공해도 대상 사이트의 지역·계정 제한이나 원격 출구 제한이 없다고 보장할 수는 없습니다. 실제 요청 결과와 클라이언트 연결 로그를 함께 확인하세요.

7. 포트가 사용 중이라고 나옵니다. 7890과 9090은 각각 어떤 역할인가요?

먼저 포트를 사용하는 프로세스를 확인한 다음 중복 실행을 종료할지 포트를 바꿀지 결정하세요. mixed-port는 앱이 프록시로 연결하는 포트이고, external-controller는 관리 인터페이스 주소입니다. 브라우저 프록시 포트로 사용하면 안 됩니다. 아래 내용은 항목의 의미를 설명하기 위한 것이며, 그대로 가져올 수 있는 완전한 구독 설정은 아닙니다.

mixed-port: 7890
external-controller: 127.0.0.1:9090
allow-lan: false
mode: rule

Windows 로그에 address already in use가 표시되면 터미널에서 다음 명령을 실행하세요. 첫 번째 명령으로 수신 중인 포트를 찾고, 두 번째 명령으로 앞 명령의 마지막 열에 표시된 PID의 프로세스 이름을 확인합니다.

netstat -ano | findstr ":7890"
tasklist /FI "PID eq 1234"

1234는 설명용 PID입니다. 실행할 때는 실제로 확인한 번호로 바꾸세요. macOS에서는 lsof -nP -iTCP:7890 -sTCP:LISTEN으로 수신 프로세스를 확인할 수 있습니다. 정체를 모르는 시스템 프로세스를 강제로 종료하지 마세요.

다른 프록시 클라이언트가 포트를 사용 중인 것이 확실하다면 중복으로 실행된 프로그램을 먼저 종료하세요. 프록시 포트를 7891로 변경한다면 시스템 프록시, 브라우저의 별도 설정, 터미널 프록시 변수도 함께 바꿔야 합니다. 관리 인터페이스는 로컬에서만 접근하도록 제한하고 인증을 설정하세요. 문제를 찾겠다고 LAN이나 인터넷에 그대로 공개하지 마세요.

8. 웹페이지가 열리지 않을 때 어떤 순서로 문제를 찾아야 하나요?

‘기본 네트워크→코어→연결 방식→규칙→DNS’ 순서로 확인하고, 한 번에 변수 하나만 바꾸세요. 먼저 접속에 실패한 사이트, 브라우저 오류, 클라이언트 로그 시간을 기록한 다음 아래 테스트를 진행하세요. 설정을 한꺼번에 바꾸면 어떤 변경이 효과가 있었는지 알기 어렵습니다.

기본 네트워크 확인: 클라이언트의 시스템 프록시와 TUN을 끄고 일반적으로 직접 접속할 수 있는 사이트를 테스트하세요. 계속 실패한다면 Wi-Fi 로그인, 인터넷 회선 또는 시스템 네트워크 문제부터 해결하세요.
코어 확인: 현재 설정이 선택되어 있는지, 로그에 설정 파싱 오류가 없는지, 프록시 포트가 수신 중인지 확인하세요.
연결 방식 확인: 시스템 프록시만 켠 뒤 브라우저로 대상에 접속하면서 클라이언트에 새 연결 기록이 생기는지 확인하세요.
출구 확인: 규칙이 최종적으로 어떤 노드를 선택했는지 확인하고, 다른 노드로 바꿔 테스트를 반복하세요. 필요하다면 잠시 전역 모드로 비교한 뒤 규칙 모드로 되돌리세요.
DNS 확인: 로그에 이름 확인 시간 초과가 표시되거나 TUN을 켜고 끌 때 결과가 달라진다면 DNS 설정, 리졸버 연결 상태, 트래픽을 가로채는 방식을 점검하세요.

프록시를 명시한 요청으로 원인 범위 좁히기

로컬 HTTP 또는 혼합 포트가 7890이라고 가정하면 Windows에서 아래 명령을 실행할 수 있습니다. macOS와 Linux에서는 curl.exe를 curl로 바꾸세요. 예시 주소는 실제로 접속에 실패한 사이트 주소로 바꿔도 됩니다.

curl.exe -I --max-time 15 --proxy http://127.0.0.1:7890 https://example.com/

프록시를 명시한 요청은 성공하는데 브라우저에서는 실패한다면 브라우저 확장 프로그램, 별도 프록시 설정, 캐시 상태를 먼저 확인하세요. 로컬 포트에 연결할 수 없다는 메시지가 바로 뜬다면 수신 상태와 포트 번호를 확인하세요. 403 같은 HTTP 응답을 받았다면 서버가 응답을 반환한 것이므로 로컬 포트 오류로 단정하면 안 됩니다. 인증서 오류가 발생하면 시스템 시간과 인증서 환경을 확인하고, 인증서 검증을 끄는 방식으로 문제를 덮지 마세요.

9. 구독 업데이트, 클라이언트 업데이트, 코어 업데이트는 같은 작업인가요?

세 업데이트는 서로 다른 대상을 다루므로 대신할 수 없습니다. 구독을 업데이트해도 보통 설정이나 리소스만 새로 가져옵니다. 오래된 코어가 새 프로토콜을 자동으로 지원하게 되는 것은 아닙니다. 새 클라이언트를 설치했다고 구독 제공업체의 서버 주소까지 갱신되는 것도 아닙니다.

업데이트 대상	주요 변경 사항	업데이트 후 확인 사항
구독 설정	노드, 정책 그룹, 규칙 등의 설정 내용	현재 설정, 그룹 내 선택 항목, 오버라이드가 유지되는지
클라이언트	관리 화면, 서비스 통합, 앱 기능	시스템 프록시, 권한, 기존 설정이 정상적으로 작동하는지
코어	프로토콜 구현, 설정 파싱, 네트워크 처리 기능	시작 로그, 항목 호환성, 실제 연결

구독 업데이트에 실패하면 먼저 DNS 오류인지, 연결 시간 초과인지, HTTP 상태 오류인지 확인하세요. 401과 403은 접근 권한이나 서버 정책 문제일 수 있고, 404는 링크가 만료됐을 가능성이 있습니다. 정확한 원인은 제공업체 안내도 확인해야 합니다. 구독 주소에 프록시 연결이 필요하다면 클라이언트에 ‘프록시를 통해 업데이트’ 옵션이 있는지 확인할 수 있지만, 사용할 수 있는 프록시가 없는데 무턱대고 이 기능에 의존하지 마세요.

업데이트 전에 기존 버전과 주요 설정을 기록하세요. 업데이트 후에는 기존에 작동하던 설정으로 먼저 테스트하세요. 계속 실패한다면 구독 업데이트 문제 해결을 참고하고, 로그를 공유하기 전에 액세스 토큰·인증 정보·개인 경로를 삭제하세요.

10. 클라이언트를 종료한 뒤 인터넷이 끊겼다면 어떻게 복구하고 처음 설정을 마치나요?

먼저 연결이 끊긴 프록시 설정을 해제한 다음 프로그램을 종료하세요. 시스템이 계속 127.0.0.1:7890으로 요청을 보내는데 해당 코어가 이미 종료됐다면 브라우저에 프록시 서버가 연결을 거부했다는 메시지가 표시될 수 있습니다. 대개는 연결 설정이 남아 있는 문제이지, 시스템을 다시 설치하거나 네트워크를 전부 초기화해야 하는 상황은 아닙니다.

복구 순서

클라이언트를 다시 실행할 수 있다면 먼저 시스템 프록시와 TUN을 끈 다음 클라이언트 메뉴에서 정상적으로 종료하세요.
Windows 11에서 「설정」→「네트워크 및 인터넷」→「프록시」로 이동해 로컬 포트를 가리키는 수동 프록시 설정이 남아 있는지 확인하세요. 직접 설정한 항목만 해제하세요.
macOS에서 「시스템 설정」→「네트워크」→현재 네트워크 연결→「세부사항」→「프록시」로 이동해 HTTP, HTTPS, SOCKS 항목을 확인하세요.
Android에서는 시스템 VPN 연결과 ‘항상 켜기 VPN’, ‘VPN 없이 연결 차단’ 등의 설정을 확인하세요. 연결을 종료한 뒤 일반 네트워크가 작동하는지 테스트하세요.
터미널에서만 문제가 생긴다면 해당 터미널 세션의 HTTP_PROXY, HTTPS_PROXY, ALL_PROXY 변수가 이전 포트를 가리키고 있는지 확인하세요.

조직에서 관리하는 기기라면 조직이 배포한 프록시·인증서·VPN 설정을 바로 삭제하지 말고 먼저 관리 정책을 확인하세요. 처음부터 시스템 네트워크를 초기화하는 것도 권장하지 않습니다. 다른 네트워크 소프트웨어에도 영향을 주어 복구 작업이 늘어날 수 있습니다.

첫 설정 완료 기준

구독을 가져와 활성화했고, 코어에 설정 파싱 오류가 없습니다.
시스템 프록시를 통해 연결 기록이 생성되고 대상 사이트에서 정상적인 콘텐츠를 불러옵니다.
규칙 모드에서 연결에 적용된 규칙과 선택된 출구를 설명할 수 있습니다.
TUN이 필요한 경우에만 따로 켜고, 스위치 색상만 보지 말고 대상 앱이 작동하는지 확인합니다.
프록시를 끄고 클라이언트를 종료한 뒤에도 원래 직접 접속할 수 있던 사이트가 열립니다.

이 다섯 가지를 확인한 다음 자동 업데이트, 앱별 분기, 시작 시 실행을 차례대로 설정하세요. 정상 작동이 확인된 설정을 기록해 두면 모든 기능을 한 번에 켜는 것보다 나중에 문제를 찾기 쉽습니다.