Clash 첫 설치 후 초기 설정 가이드: 시스템 프록시, 포트, TUN 모드와 오류 해결

설치 전 확인: 시스템 아키텍처, 클라이언트와 코어

처음 설정할 때는 연결 경로가 제대로 작동하는지 단계별로 확인해야 합니다. 애플리케이션이 요청을 보내면 로컬 프록시 포트가 이를 받아 코어가 규칙에 따라 직접 연결하거나 프록시를 거쳐 대상 서비스에 전달합니다. 설치 파일이 실행되는 것은 그래픽 인터페이스가 시작됐다는 뜻일 뿐입니다. 구독 다운로드, 코어 실행, 애플리케이션 연결은 각각 따로 확인해야 합니다.

아키텍처에 맞는 설치 파일을 선택하고 코어 지원 여부 확인

• Windows: 「설정」→「시스템」→「시스템 정보」에서 시스템 종류를 확인하세요. 일반적인 Intel·AMD PC에는 x64 설치 파일을 사용합니다. Windows on ARM 기기라면 클라이언트에서 제공하는 ARM64 버전을 우선 선택하세요.
• macOS: Apple 메뉴→「이 Mac에 관하여」에서 칩을 확인하세요. Apple Silicon에는 arm64, Intel 모델에는 x64 패키지를 사용합니다. Universal 패키지가 제공된다면 릴리스 안내에 따라 선택하세요.
• Linux: uname -m을 실행하세요. 출력이 x86_64라면 일반적으로 amd64/x64, aarch64라면 arm64에 해당합니다. 설치 파일 형식과 배포판 지원 여부도 확인하세요.
• Android: 클라이언트의 릴리스 안내에 따라 APK 아키텍처를 선택하세요. 앱에서 활성화하는 VPN 서비스는 기기의 트래픽을 처리하기 위한 것으로, 데스크톱 시스템에서 수동으로 설정하는 HTTP 프록시와는 다릅니다.
• iOS: 해당 구성 형식을 지원하는 클라이언트를 사용하세요. 데스크톱용 Clash의 전체 YAML을 모든 iOS 클라이언트에서 바로 읽을 수 있다고 가정해서는 안 됩니다. 가져오기 전에 구독 형식을 확인하세요.

Clash 그래픽 클라이언트는 구독 관리, 켜기·끄기, 상태 표시를 담당하고, Clash 또는 Clash Meta(mihomo) 코어는 설정을 해석하고 트래픽을 전달합니다. 최신 프로토콜과 설정 항목의 지원 여부는 실제로 실행 중인 코어와 버전에 따라 달라집니다. 가져오는 중 지원하지 않는 프록시 유형 오류가 발생하면 시스템 프록시를 반복해서 바꾸기보다 클라이언트의 「정보」 또는 코어 정보 화면을 확인하고 설정 요구 사항을 살펴보세요.

구독 가져오기: 다운로드 후 설정을 활성화해야 합니다

구독 링크는 보통 접근 자격 정보가 포함된 URL입니다. 전체 YAML을 반환하기도 하고 노드 목록만 반환하기도 합니다. 전체 설정에는 대개 proxies 또는 proxy-providers, proxy-groups, rules가 포함됩니다. 노드 목록만 제공되는 경우에는 클라이언트 템플릿으로 정책 그룹과 규칙을 보완해야 합니다. 두 형식은 모든 가져오기 메뉴에서 공통으로 사용할 수 있는 것이 아닙니다.

1. 클라이언트의 「설정」 또는 「구독」 화면에서 URL 가져오기를 선택하고 서비스 제공자가 안내한 전체 링크를 붙여 넣으세요. 메뉴 이름은 클라이언트마다 다를 수 있으므로 현재 버전의 설정 관리 화면을 기준으로 진행하세요.
2. 다운로드 또는 업데이트를 실행한 뒤 최근 업데이트 시간과 오류 메시지를 확인하세요. HTTP 401·403 오류가 발생하면 링크 자격 정보, 계정 상태, 서비스 제공자의 접근 제한을 확인하세요. 404 오류라면 먼저 주소가 만료되지 않았는지, 복사 과정에서 누락되지 않았는지 확인하세요.
3. 가져온 설정을 선택하고 활성화 상태인지 확인한 다음 프록시 그룹 화면을 여세요. 다운로드가 완료됐다고 해서 코어가 해당 설정으로 전환된 것은 아닙니다.
4. 실제 규칙에서 참조하는 선택 그룹에서 사용할 수 있는 노드를 선택하세요. 자동 지연 시간 측정 그룹은 구성원을 자동 선택할 수 있지만, 수동 선택 그룹에서는 직접 골라야 합니다. DIRECT에 그대로 머물러 있지 않은지 확인하세요.
5. 코어 로그에서 설정 구문 오류가 있는지 확인하세요. YAML 들여쓰기에는 공백을 사용하고 탭 문자를 섞지 마세요. 편집기에서 파일이 열린다는 이유만으로 유효한 설정이라고 판단해서는 안 됩니다.

구독 업데이트와 로컬 수정 사항을 따로 관리하세요

다운로드한 구독 파일을 직접 수정하면 다음 업데이트에서 변경 내용이 덮어써질 수 있습니다. 고정 포트, DNS, 규칙을 변경할 때는 클라이언트가 지원하는 오버라이드·병합·확장 설정 기능을 우선 사용하세요. 변경한 항목과 설정 위치를 기록하고 업데이트 후 최종 적용 설정을 다시 확인하세요. 오류를 공유할 때는 구독 URL, 노드 비밀번호, 제어 인터페이스 키를 가리고 진단에 필요한 항목과 오류 줄만 남기세요.

시스템 프록시와 혼합 포트: 주소와 포트 일치 여부 확인

데스크톱 시스템 프록시는 시스템 프록시 설정을 읽는 애플리케이션을 로컬 프록시 포트로 연결합니다. 모든 프로그램의 트래픽이 자동으로 Clash를 통과하는 것은 아닙니다. 처음 점검할 때는 시스템 프록시를 사용해 브라우저 요청이 코어에 도달하는지 확인한 뒤, 게임이나 명령줄 도구 등 시스템 프록시 설정을 따르지 않는 프로그램을 별도로 살펴보세요.

로컬 포트 예시: 127.0.0.1:7890

아래는 기본 항목을 확인하기 위한 예시이며, 노드에 바로 연결할 수 있는 전체 설정은 아닙니다. mixed-port는 HTTP 프록시와 SOCKS5 프록시 연결을 모두 받습니다. 7890은 예시 값이므로 실제 적용 값은 클라이언트 설정을 기준으로 확인하세요. 일부 클라이언트는 그래픽 설정으로 파일에 지정된 포트를 덮어씁니다.

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

플랫폼별 시스템 설정 확인 경로

• Windows 11: 「설정」→「네트워크 및 인터넷」→「프록시」→「수동 프록시 설정」으로 이동하세요. 클라이언트가 시스템 프록시를 관리한다면 클라이언트에서 기능을 켠 뒤 이 화면에 올바른 로컬 주소와 포트가 지정됐는지 확인하세요. 출처를 알 수 없는 스크립트 설정을 동시에 남겨 두지 마세요.
• macOS: 「시스템 설정」→「네트워크」→현재 네트워크 서비스→「세부사항」→「프록시」로 이동하세요. 웹 프록시, 보안 웹 프록시 또는 SOCKS 프록시의 주소와 포트를 확인하고, 클라이언트를 종료한 뒤 설정이 복원되는지도 살펴보세요.
• Linux: 데스크톱 환경의 네트워크 프록시 설정과 터미널 환경 변수는 별도로 적용됩니다. 데스크톱 프록시를 설정해도 명령줄 도구에서는 추가 옵션이나 HTTP_PROXY, HTTPS_PROXY 등의 환경 변수가 필요할 수 있습니다. 자세한 내용은 해당 도구의 문서를 확인하세요.

연결 확인: 포트·규칙·노드 문제 구분하기

연결을 점검할 때는 한 번에 조건 하나만 바꾸세요. 먼저 포트 연결을 확인하고, 다음으로 규칙 적용 여부를 살핀 뒤 원격 노드를 점검하세요. 클라이언트의 노드 지연 시간 테스트는 보통 지정된 테스트 주소에 요청해 걸린 시간을 측정합니다. 다운로드 속도를 측정하는 것도 아니며 모든 웹사이트에 접속할 수 있음을 보장하지도 않습니다.

시스템 설정의 영향을 배제하려면 프록시를 명시해 요청하세요

Windows PowerShell에서는 일부 환경에서 curl이 다른 명령으로 해석될 수 있으므로 curl.exe를 사용하세요. macOS와 Linux에서는 curl을 사용할 수 있습니다. 아래 명령은 예시 포트로 테스트 웹페이지에 요청하며 최대 대기 시간은 15초입니다. 실행 전에 실제 수신 포트로 바꾸세요.

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

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

• 로컬 포트에 연결할 수 없음: 코어가 실행 중인지, 포트가 일치하는지, 로그에 수신 실패가 기록됐는지 확인하세요. 요청이 아직 프록시 계층에 도달하지 않은 상태이므로 이때 원격 노드를 바꾸는 것은 대개 도움이 되지 않습니다.
• HTTP 응답 헤더를 받음: 해당 요청이 프록시 진입점과 대상 접속 경로를 통과했다는 뜻입니다. 다만 규칙 모드에서는 대상이 직접 연결로 처리됐을 수도 있으므로 연결 기록에서 실제 접속 경로를 확인하세요.
• 요청 시간 초과: 연결 기록에 해당 도메인이 나타나는지, 어떤 규칙이 적용됐는지, 어떤 노드가 선택됐는지 확인하세요. 기록이 없다면 먼저 애플리케이션 연결을 점검하세요. 기록이 있다면 DNS, 노드 연결 상태, 대상 서비스 순으로 살펴보세요.

일상적인 사용은 규칙 모드부터 시작하세요

mode: rule은 설정에 적힌 순서대로 연결을 규칙과 대조하며, 마지막에는 보통 MATCH가 기본 처리 규칙으로 적용됩니다. 전역 모드는 특정 대상이 잘못된 정책에 배정됐는지 잠시 확인할 때 유용하지만, 노드 장애나 구독 형식 오류를 해결해 주지는 않습니다. 점검을 마치면 규칙 모드로 되돌리고 연결 기록에서 규칙 이름, 정책 그룹, 최종 노드를 확인하세요. 웹페이지가 열린다는 이유만으로 프록시를 통해 접속했다고 단정하지 마세요.

TUN 모드: 권한·라우팅·DNS 확인 순서

TUN 모드는 가상 네트워크 인터페이스와 라우팅을 사용해 트래픽을 처리하므로 시스템 프록시를 읽지 않는 애플리케이션에 적합합니다. 시스템 프록시와는 별개의 연결 방식이며 모든 연결을 원격 노드로 보내는 기능은 아닙니다. 트래픽이 코어에 들어온 뒤에도 규칙에 따라 DIRECT, 프록시 그룹 또는 다른 동작이 선택됩니다.

일반 프록시 연결을 확인한 다음 TUN을 활성화하세요

1. 프록시를 명시한 요청과 노드 연결이 정상인지 먼저 확인하세요. 일반 프록시 경로가 작동하지 않는다면 TUN으로 변수를 늘리지 말고 구독, 포트, 노드부터 해결하세요.
2. 클라이언트에서 서비스 모드나 권한 설치 기능을 제공하는지 확인하세요. Windows 클라이언트는 설치된 백그라운드 서비스나 관리자 권한이 필요할 수 있고, macOS에서는 보조 구성 요소의 승인이 필요할 수 있습니다. Linux에서는 권한 상승이나 네트워크 관리 권한이 필요한 경우가 많습니다.
3. TUN을 활성화한 뒤 가상 인터페이스, 라우팅, 코어 로그를 확인하세요. 권한 오류가 발생하면 해당 클라이언트의 설치 문서에 따라 서비스를 승인하세요. 관련 없는 프로그램을 장기간 과도한 권한으로 실행하지 마세요.
4. 다른 VPN의 트래픽 처리를 잠시 끄고 웹페이지, 대상 애플리케이션, LAN 리소스를 테스트하세요. VPN 두 개가 기본 경로나 DNS를 동시에 변경하면 요청이 잘못된 인터페이스로 들어갈 수 있습니다.

mihomo 설정에서 tun.enable은 TUN 활성화 여부를 제어하고, auto-route는 자동 라우팅과 관련되며, dns-hijack은 지정된 DNS 트래픽을 가로채는 데 사용할 수 있습니다. 지원 여부는 플랫폼, 코어 버전, 클라이언트 오버라이드에 따라 달라집니다. TUN 설정 일부를 붙여 넣기만 하면 라우팅, DNS, 권한이 모두 준비됐다고 가정하지 마세요.

DNS 문제와 규칙 분기는 따로 확인하세요

도메인 접속은 실패하지만 다른 연결은 응답한다면 DNS 로그와 현재 DNS 설정부터 확인하세요. 브라우저의 보안 DNS, 앱 내장 해석기, 시스템 DNS는 서로 다른 경로를 사용할 수 있습니다. 일반 DNS 요청을 가로채더라도 모든 암호화 DNS가 처리되는 것은 아닙니다. fake-ip 모드에서는 앱이 가상 주소 풀의 주소를 받을 수 있으며, 이는 코어가 도메인과 주소를 매핑하는 방식입니다. 해당 주소를 hosts 파일에 임의로 추가하지 마세요.

프린터, NAS, 사내 네트워크 접속에 문제가 생기면 무조건 전역 프록시로 바꾸기보다 LAN 직접 연결 규칙, 라우팅 제외 설정, 내부 DNS를 확인하세요. Android의 VPN 승인 창은 앱이 VPN 인터페이스를 만들도록 허용하는 절차입니다. 일반적으로 한 사용자 환경에서는 VPN 서비스를 하나만 활성화할 수 있으므로 다른 VPN 앱이 대체되거나 연결이 끊길 수 있습니다.

첫 실행 때 자주 발생하는 오류: 원인 계층에 따라 해결하기

시스템 보안 기능에 의해 설치가 차단됨

Windows에서 SmartScreen 또는 보안 프로그램 경고가 나타나면 먼저 다운로드 출처와 게시자 정보, 현재 시스템에 맞는 설치 파일인지 확인하세요. 회사 기기에는 앱 실행 정책이 적용될 수 있으므로 관리자에게 권한을 확인하세요. macOS에서 개발자 확인 경고가 나타나면 출처를 확인한 뒤 「시스템 설정」→「개인정보 보호 및 보안」에서 해당 앱을 허용하는 옵션이 있는지 살펴보세요. 시스템에서 앱이 컴퓨터를 손상시키거나 파일이 손상됐다고 경고하면 실행을 중단하고 출처와 릴리스 안내를 다시 확인하세요. 모든 경고를 같은 문제로 취급해서는 안 됩니다.

address already in use: 로컬 포트가 이미 사용 중

이 오류는 코어가 특정 주소나 포트에 바인딩하지 못했다는 뜻입니다. 클라이언트가 중복 실행 중이라면 먼저 종료한 뒤 포트를 사용 중인 프로세스를 확인하세요. Windows에서는 아래 명령으로 7890 수신 상태를 조회하고 작업 관리자의 「세부 정보」에서 PID와 프로세스를 대조할 수 있습니다. 포트가 사용 중이라는 이유만으로 정체를 알 수 없는 시스템 프로세스를 종료하지 마세요.

netstat -ano | findstr ":7890"

macOS에서는 lsof -nP -iTCP:7890 -sTCP:LISTEN, Linux에서는 ss -lntp 명령으로 수신 정보를 확인할 수 있습니다. 다른 포트로 변경했다면 시스템 프록시도 함께 수정하세요. 제어 인터페이스 포트 충돌과 트래픽 수신 포트 충돌은 각각 따로 해결해야 합니다.

인증서 오류: 시간·대상 도메인·신뢰 체인부터 확인

일반적인 HTTP CONNECT 또는 SOCKS5 전달에는 브라우저에 루트 인증서를 설치할 필요가 없습니다. 「인증서가 만료됨」, 「인증서 이름이 일치하지 않음」 또는 TLS 핸드셰이크 오류가 발생하면 시스템 날짜와 시간대, 접속 도메인, 인증서 발급자를 먼저 확인하세요. 웹 로그인 인증이 필요한 네트워크에 연결된 것은 아닌지도 살펴보세요. 회사 네트워크에서 관리형 TLS 검사 기능을 사용하는 경우 조직의 인증서 배포 절차를 따르세요.

클라이언트를 종료한 뒤에도 인터넷에 연결되지 않음

먼저 시스템 프록시를 끄고 수동 프록시 주소가 제거됐는지 확인하세요. 이어서 TUN 라우팅, VPN 서비스 또는 다른 클라이언트의 트래픽 처리가 남아 있는지 살펴보세요. 정상 종료 시 클라이언트가 관련 설정을 복원하지만 비정상 종료 후에는 직접 복구해야 할 수 있습니다. 원격으로 PC를 조작 중이라면 기본 경로를 변경하기 전에 예비 연결을 마련해 관리 세션이 끊기지 않도록 하세요.

초기 설정 완료 확인 목록

연결이 정상적으로 작동하는 것을 확인한 뒤 시작 프로그램 등록이나 구독 자동 업데이트 같은 일상 기능을 활성화하세요. 필요한 설정을 기록해 두면 업데이트하거나 네트워크를 바꾼 뒤 설정 변경과 네트워크 장애를 빠르게 구분할 수 있습니다.

• 구독의 최근 업데이트가 성공으로 표시되고 현재 설정이 선택되어 있으며, 코어 시작을 막는 구문 오류가 로그에 없습니다.
• 클라이언트 이름, 코어 버전, 실제 mixed-port를 기록하고 시스템 프록시 주소와 포트가 일치하는지 확인하세요.
• 프록시를 명시한 요청이 응답하고, 연결 기록에서 규칙 적용, 정책 그룹, 최종 접속 경로를 확인할 수 있습니다.
• TUN이 필요한 앱을 따로 테스트했고, LAN 기기와 내부 서비스에도 예상대로 접속할 수 있습니다.
• 클라이언트를 종료한 뒤 일반 인터넷 연결이 복구되고, 재부팅 후 프록시 스위치와 서비스 상태도 예상대로 작동합니다.
• 구독을 업데이트한 뒤 오버라이드 설정을 다시 확인하세요. 자격 정보는 백업에 안전하게 보관하고 전체 구독 링크를 공개 질문 게시물에 붙여 넣지 마세요.

이후 문제 해결도 「설정 유효성 확인 → 코어 수신 상태 확인 → 애플리케이션 연결 확인 → 규칙 적용 확인 → 노드 연결 확인」 순서로 진행하세요. 용어는 용어 설명에서, 규칙과 코어 설정은 기술 참고 자료에서 확인할 수 있습니다.