Clash 클라이언트 첫 실행 설정 가이드: 포트·구독·프록시 모드 체크리스트

첫 실행은 설정부터: 트래픽 연결은 그다음

Clash를 처음 사용할 때는 먼저 구독을 가져와 활성화하고, 코어가 실행 중인지와 포트가 사용 가능한지 확인한 다음 규칙 모드와 노드를 선택하세요. 마지막으로 시스템 프록시나 VPN을 켜 트래픽을 전달하면 됩니다. 데스크톱에서는 시스템 프록시로 브라우저 연결부터 확인하세요. 대상 앱이 시스템 프록시를 사용하지 않을 때만 TUN 모드를 고려하면 됩니다. 단계마다 확인할 대상이 분명해 구독, DNS, 가상 네트워크 어댑터를 한꺼번에 점검하지 않아도 됩니다.

Clash 클라이언트는 조작 화면이고, 코어는 연결을 처리하며, 구독은 노드와 정책 그룹, 경우에 따라 규칙을 제공합니다. mihomo(Clash Meta라고도 함) 코어를 사용하는 클라이언트는 원본 Clash와 지원하는 설정 항목이 완전히 같지 않습니다. 다운로드가 끝나고 화면이 열린다고 해서 구독이 활성화되었거나 프록시가 작동하는 것은 아닙니다.

코어 상태 확인: 홈 화면에 실행 중이라고 표시되어야 합니다. 로그에 설정 파싱 실패나 포트 바인딩 실패가 반복해서 나타나지 않는지도 확인하세요.
구독 가져오기: 업데이트가 완료되면 해당 설정 카드를 눌러 현재 설정으로 지정하세요.
포트 확인: 실제 혼합 포트를 기록하세요. 예를 들어 7890일 수 있지만, 다른 가이드에 나온 포트를 그대로 사용하면 안 됩니다.
아웃바운드 선택: 규칙 모드로 전환하고, 규칙에서 참조하는 정책 그룹에서 사용할 수 있는 노드를 선택하세요.
트래픽 전달 및 확인: 전달 방식을 하나 켜고 웹페이지에 접속하면서 연결 기록과 일치한 규칙을 확인하세요.

구독 가져오기: 업데이트 성공 후 설정 활성화

구독 주소, 노드 링크, 웹페이지 주소 구분하기

구독 주소는 일반적으로 토큰이 포함된 HTTPS 링크이며, 클라이언트가 이 주소를 통해 설정을 가져옵니다. 서비스 제공업체의 관리 페이지, 결제 페이지, 사용 안내 페이지는 구독 주소가 아닙니다. 개별 노드 링크도 완전한 Clash 설정으로 바로 가져올 수 있는 것은 아닙니다. 클라이언트가 변환 또는 노드 관리 기능을 제공하는지에 따라 달라집니다.

일반적인 데스크톱 클라이언트에서는 「구독」 또는 「설정」→「새로 만들기/가져오기」→ 구독 주소 붙여넣기 →「저장/다운로드」 순으로 진행합니다. 메뉴 이름은 클라이언트마다 다르므로 실제 화면을 기준으로 확인하세요. 다운로드가 끝난 뒤 설정 목록에서 해당 항목을 선택해야 합니다. “업데이트 성공”이라고만 표시되고 현재 설정이 기본값 그대로라면 노드는 자동으로 바뀌지 않습니다.

노드 목록이 비어 있음: 방금 가져온 설정을 선택했는지, 응답 내용이 클라이언트에서 지원하는 설정 형식인지 확인하세요.
HTTP 401 또는 403 오류: 먼저 구독이 만료되었는지, 토큰이 유효한지, 서버가 요청을 제한하는지 확인하세요. DNS부터 변경하지 마세요.
파싱 오류: 로그에 표시된 필드 이름과 줄 번호를 확인하세요. mihomo 전용 프로토콜이나 필드가 포함된 설정은 원본 코어에서 실행되지 않을 수 있습니다.
다운로드 시간 초과: 먼저 구독 도메인에 접속할 수 있는지 확인하세요. 클라이언트가 “프록시를 통해 구독 업데이트”를 지원하더라도 이 방법을 사용하려면 작동하는 설정이 이미 있어야 합니다.

가져온 뒤 세 가지 확인하기

첫째, 설정 카드가 현재 선택된 상태인지 확인합니다. 둘째, 프록시 화면에 노드나 정책 그룹이 표시되는지 확인합니다. 셋째, 로그에 설정 로드 완료가 표시되고 코어가 반복해서 재시작되지 않는지 확인합니다. 어떤 규칙이 포함되는지, 자동 선택 그룹이 있는지는 설정 제공자가 결정합니다. 노드가 많다는 이유만으로 트래픽 분배 설정이 완료되었다고 판단할 수는 없습니다.

혼합 포트: 7890을 외우지 말고 실제 값을 확인하세요

혼합 포트(mixed-port)는 하나의 수신 포트에서 HTTP 프록시와 SOCKS 프록시 연결을 모두 받습니다. 7890은 흔히 사용하는 값이지만 모든 클라이언트의 고정값은 아닙니다. 클라이언트의 「설정」→「포트」 또는 「설정」→「혼합 포트」에서 실제 값을 확인한 뒤 앱의 프록시 설정과 맞추세요.

항목	예시 값	확인할 점
혼합 포트	`127.0.0.1:7890`	기기 내 앱이 HTTP 또는 SOCKS 프록시를 이용할 때 연결하는 포트입니다.
별도 HTTP 포트	`port: 7890`	혼합 포트와는 별개의 설정 항목입니다. 두 수신 포트가 충돌하지 않도록 하세요.
별도 SOCKS 포트	`socks-port: 7891`	해당 수신 항목을 실제로 활성화한 경우에만 사용하세요. 항상 있는 것으로 가정하면 안 됩니다.
컨트롤 인터페이스	`127.0.0.1:9090`	화면에서 코어를 제어할 때 사용하며, 브라우저나 앱의 프록시 포트가 아닙니다.

아래 예시는 기본 필드를 알아보기 위한 조각이며, 그대로 가져올 수 있는 완전한 구독 설정이 아닙니다. 기존 클라이언트는 실행 중 설정으로 이 필드들을 덮어쓸 수 있으므로 최종 적용값을 확인하세요. 예시와 값을 맞추려고 기존 노드, 규칙, 정책 그룹을 덮어쓰지 마세요.

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

포트 사용 중 오류가 나면 이전 프로세스부터 확인하세요

로그에 address already in use 또는 포트 바인딩 실패가 나타나면 대개 같은 주소의 포트를 다른 프로세스가 사용 중이라는 뜻입니다. 기존 프록시 클라이언트를 종료한 다음 현재 클라이언트를 실행하세요. 그래도 충돌하면 혼합 포트를 17890으로 변경하고, 수동으로 입력한 앱의 프록시 주소도 함께 바꾸세요. 코어 포트만 바꾸고 앱이 계속 7890에 연결하면 요청이 실패합니다.

처음 사용할 때는 “LAN 연결 허용”을 꺼 두세요. 휴대폰에서 컴퓨터 프록시를 이용할 때 휴대폰의 127.0.0.1은 컴퓨터가 아니라 휴대폰 자신을 가리킵니다. 이는 LAN 공유에 해당하므로 수신 주소, 접근 제어, 방화벽을 별도로 설정해야 합니다. 첫 실행 설정과 함께 점검하는 것은 권장하지 않습니다.

프록시 모드 선택: 규칙·전역·직결

일상적인 사용에는 규칙 모드를 우선 선택하세요. 규칙 모드는 설정에 정의된 규칙에 따라 연결의 아웃바운드를 직결, 프록시 정책 그룹, 차단 등으로 결정합니다. “해외 웹사이트는 모두 프록시를 이용한다”는 뜻은 아닙니다. 실제 동작은 규칙 순서와 정책 그룹 선택에 따라 달라집니다. 규칙은 보통 위에서 아래로 적용되며, 일치하는 규칙이 없으면 마지막에 MATCH가 처리하는 경우가 많습니다.

규칙(Rule): 일상적인 트래픽 분배에 사용합니다. 어떤 규칙이 일치했는지와 해당 정책 그룹에서 무엇을 선택했는지 모두 확인하세요.
전역(Global): 코어로 들어온 연결을 전역 정책으로 처리합니다. 규칙과 노드 문제를 잠시 비교해 볼 때 유용하며, 전역 그룹에서 사용할 아웃바운드를 선택해야 합니다.
직결(Direct): 코어로 들어온 연결을 프록시 없이 직접 연결합니다. 임시 문제 해결에 적합하며, “프록시가 켜져 있음”과 같은 뜻은 아닙니다.

모드는 코어에 들어온 뒤 어떤 방식으로 아웃바운드할지 결정하고, 시스템 프록시나 TUN은 어떤 연결을 코어로 보낼지 결정합니다. 따라서 “전역 모드로 바꿨는데 특정 앱이 여전히 프록시를 사용하지 않는다”는 상황은 모순이 아닙니다. 해당 앱이 시스템 프록시를 사용하지 않을 수 있습니다.

노드 지연 시간 테스트만으로 실제 접속을 확인할 수는 없습니다

지연 시간 테스트는 보통 지정된 테스트 주소에만 접속합니다. 결과가 120 ms로 표시되어도 대상 웹사이트, 동영상, UDP 서비스가 모두 작동한다는 보장은 없습니다. 수동 선택 그룹에서는 노드를 직접 선택하고, 자동 선택 그룹에서는 현재 어떤 노드를 사용하는지 확인하세요. 문제를 점검할 때는 비교할 노드를 하나 고정하세요. 테스트할 때마다 아웃바운드가 바뀌면 결과를 비교하기 어렵습니다.

플랫폼별 트래픽 전달: 데스크톱 시스템 프록시와 모바일 VPN

플랫폼	먼저 할 작업	놓치기 쉬운 점
Windows	설정을 활성화하고 클라이언트의 시스템 프록시를 켭니다.	「설정」→「네트워크 및 인터넷」→「프록시」에서 로컬 주소와 포트를 확인합니다.
macOS	클라이언트가 네트워크 프록시를 변경하도록 허용하고 현재 네트워크 서비스를 확인합니다.	「시스템 설정」→「네트워크」→ 현재 연결 →「세부사항」→「프록시」에서 확인하세요. 메뉴 이름은 시스템 버전에 따라 다를 수 있습니다.
Linux	데스크톱 프록시 또는 앱 내 프록시가 설정되어 있는지 확인합니다.	터미널 프로그램은 데스크톱 시스템 프록시를 사용하지 않을 수 있습니다. 별도로 설정하거나 프록시를 명시해야 합니다.
Android	설정을 선택하고 연결을 시작한 다음 시스템 VPN 요청을 승인합니다.	기존 VPN, 앱별 분할 터널링 목록, 백그라운드 배터리 제한이 트래픽 전달에 영향을 줄 수 있습니다.
iOS	호환되는 설정을 지원하는 클라이언트를 사용하고 시스템 안내에 따라 VPN 설정을 추가합니다.	데스크톱 메뉴 구성을 그대로 적용할 수는 없습니다. 노드 프로토콜과 설정 형식이 클라이언트에서 지원되는지 확인하세요.

Windows와 macOS: 먼저 브라우저에서 시스템 프록시 확인하기

시스템 프록시와 확장 프로그램 프록시가 서로 덮어쓰지 않도록 브라우저 확장 프로그램에서 별도로 설정한 프록시를 먼저 끄세요. Windows 방화벽 알림이 모든 네트워크에서 인바운드 접속을 허용해야 한다는 뜻은 아닙니다. 필요한 네트워크 범위에서만 허용하세요. 로컬 루프백 프록시만 사용하는 경우 문제 해결을 위해 방화벽 전체를 끌 필요가 없습니다.

Linux: 브라우저가 된다고 터미널 설정까지 끝난 것은 아닙니다

터미널의 다운로드 도구, 패키지 관리자, 개발 도구는 각자 별도의 프록시 설정을 사용할 수 있습니다. 먼저 명령에 프록시를 명시해 코어가 작동하는지 확인한 뒤 환경 변수에 저장할지 결정하세요. HTTPS_PROXY를 설정할 때 변수 이름의 HTTPS는 대상 요청 유형을 뜻합니다. 일반적인 HTTP 프록시 주소는 http://127.0.0.1:7890로 지정해도 되며, 임의로 https://로 바꿀 필요는 없습니다.

Android와 iOS: VPN 충돌 및 앱 범위 확인

Android에서 VPN 서비스를 사용하는 프록시 클라이언트는 보통 다른 VPN과 동시에 작동할 수 없습니다. 앱 목록이 “선택한 앱만 프록시”로 설정되어 있다면 테스트할 브라우저도 목록에 포함해야 합니다. iOS에서는 VPN 연결 여부를 확인하고 클라이언트의 우회 규칙도 살펴보세요. 화면 상단의 VPN 표시만으로 특정 요청이 어떤 노드를 사용했는지 판단할 수는 없습니다.

연결 확인: 포트·연결 기록·웹페이지를 함께 점검하세요

확인할 때는 한 번에 설정 하나만 바꾸세요. 먼저 코어 로그가 정상인지 확인하고, 원래 직접 접속할 수 있는 웹사이트에 접속한 다음 원하는 아웃바운드가 필요한 서비스에 접속하세요. 동시에 클라이언트의 「연결」 또는 「로그」를 열어 대상 도메인, 일치한 규칙, 아웃바운드 정책을 확인합니다. 웹사이트가 열렸는데 연결 기록이 없다면 요청이 직결, 캐시, 다른 프록시를 사용했거나 현재 코어가 처리하지 않았을 수 있습니다.

프록시를 명시하는 명령으로 시스템 프록시 문제 분리하기

아래 명령은 혼합 포트가 7890이라고 가정합니다. Windows에서는 PowerShell의 curl.exe를 사용해 일부 환경의 curl 별칭으로 생길 수 있는 차이를 피하세요. macOS와 Linux에서는 curl을 사용할 수 있습니다. 포트가 다르면 명령의 숫자를 바꾸세요.

curl.exe -I --connect-timeout 10 --max-time 20 -x http://127.0.0.1:7890 https://example.com

curl -I --connect-timeout 10 --max-time 20 -x http://127.0.0.1:7890 https://example.com

여기서 10초는 연결 단계의 시간 제한이고 20초는 요청 전체의 최대 시간입니다. 속도 측정 결과가 아닙니다. 예시 도메인은 요청 경로를 확인하기 위한 것입니다. 특정 서비스를 테스트하려면 해당 서비스의 HTTPS 주소로 바꾸세요. HTTP 프록시 출력의 200 Connection established는 터널이 연결되었다는 뜻일 뿐입니다. 대상 서버의 응답과 클라이언트 연결 기록을 이어서 확인하세요.

로컬 포트 연결에 바로 실패함: 코어가 실행 중인지, 주소가 올바른지, 포트가 일치하는지 확인하세요.
프록시를 명시하면 되지만 브라우저에서는 안 됨: 시스템 프록시, 브라우저의 별도 프록시 설정, 확장 프로그램을 확인하세요. 구독부터 바꾸지 마세요.
연결 기록은 있지만 요청 시간이 초과됨: 선택한 노드, 일치한 정책, 대상 서비스 접속 가능 여부를 확인하고 다른 노드와 비교하세요.
도메인으로 접속할 때만 문제가 생김: 로그와 함께 DNS를 확인하세요. 단 한 번의 이름 확인 오류만으로 TUN을 켜야 한다고 단정할 수는 없습니다.
웹페이지에 인증서 오류가 표시됨: 먼저 시스템 시간, 인증서 발급자, 대상 도메인을 확인하세요. 인증서 검증을 끈 채 로그인하지 마세요.

첫 설정을 마친 뒤 저장 및 복구 확인

연결 확인을 마친 뒤 구독 자동 업데이트와 시작 프로그램 등록을 설정하세요. 먼저 클라이언트를 직접 한 번 재시작해 현재 설정, 모드, 정책 그룹 선택이 복구되는지 확인합니다. 데스크톱 클라이언트의 시작 설정에서는 “화면 실행”, “코어 시작”, “시스템 프록시 자동 활성화”를 구분해야 합니다. 이 세 동작이 항상 함께 실행되는 것은 아닙니다.

정상 작동 조합 기록: 클라이언트 이름, 코어 종류, 현재 구독, 혼합 포트, 프록시 모드, 트래픽 전달 방식.
로컬 수정 사항 보호: 구독 업데이트로 직접 수정한 내용이 덮어써질 수 있습니다. 지속적으로 적용할 변경은 클라이언트에서 지원하는 오버라이드 또는 병합 기능을 우선 사용하세요.
종료 후 복구 확인: 정상적으로 종료하면 시스템 프록시가 꺼지거나 원래 설정으로 복구되어야 합니다. 그렇지 않으면 앱이 이미 수신을 중단한 포트에 계속 연결할 수 있습니다.
문제 해결에 필요한 정보 보관: 오류 발생 시각과 민감 정보를 제거한 로그를 저장하세요. 구독 토큰, 인증 정보, 전체 접속 기록은 공개하지 마세요.

“설정이 활성화됨, 포트가 수신 중임, 정책 그룹이 선택됨, 트래픽이 코어에 들어옴, 대상 요청이 올바른 아웃바운드로 처리됨”의 다섯 가지를 모두 확인하면 첫 설정의 검증이 끝납니다. 이후 특정 앱이 프록시를 사용하지 않을 때는 해당 앱의 트래픽 전달 방식만 조정하세요. 모든 스위치를 처음부터 다시 바꿀 필요는 없습니다. 설정 항목과 규칙을 더 알아보려면 Clash 설정 설명서를 확인하고, 명확한 오류가 발생했다면 자주 묻는 질문을 참고해 문제 범위를 좁혀 보세요.