첫 설정 순서: 구독을 가져온 뒤 트래픽을 프록시로 전달
처음 사용할 때는 ‘클라이언트 설치 → 설정 가져오기 및 활성화 → 정책 선택 → 트래픽 전달 활성화 → 연결 확인’ 순서로 진행하세요. 먼저 연결 하나가 제대로 되는지 확인한 다음 TUN, DNS, 시작 프로그램 설정을 조정하면 문제가 발생한 단계를 쉽게 찾을 수 있습니다.
Clash는 프록시 코어와 관련 클라이언트 생태계를 통칭하는 경우가 많으며, 모든 플랫폼에서 동일한 설치 프로그램을 뜻하지는 않습니다. Clash Meta는 이후 mihomo라는 이름을 사용하며, 이를 채택한 GUI 클라이언트는 각기 다른 설정 화면을 제공합니다. 구독 호환 여부는 실제 코어와 설정 형식에 따라 달라지므로 앱 이름만으로 판단할 수 없습니다.
- 운영체제와 프로세서 확인: Windows는 x64와 ARM64, macOS는 Intel과 Apple Silicon을 구분해야 합니다. Android 설치 파일도 arm64-v8a 등 아키텍처별로 나뉠 수 있습니다.
- 호환되는 구독 준비: 서비스 제공업체가 제공하는 Clash 또는 mihomo 설정 링크가 필요합니다. 노드 목록이나 웹페이지 주소, 다른 클라이언트 전용 링크는 바로 가져오지 못할 수 있습니다.
- 다른 프록시나 VPN은 잠시 종료: 여러 클라이언트가 동시에 시스템 프록시, 가상 네트워크 어댑터 또는 라우팅을 변경하지 않도록 합니다.
- 현재 네트워크 상태 기록: 먼저 일반 웹사이트가 열리는지 확인한 뒤 설정을 시작하세요. 수동 프록시를 사용 중인 컴퓨터라면 기존 설정을 미리 기록해 두세요.
구독 가져오기와 정책 그룹: 설정을 가져왔다고 바로 활성화되는 것은 아닙니다
클라이언트의 ‘구독’, ‘설정’ 또는 Profiles 화면에서 URL 가져오기를 선택한 뒤 전체 주소를 붙여 넣고 다운로드하세요. 클라이언트마다 메뉴 이름이 다를 수 있으므로, 특정 앱의 버튼을 공통 경로로 간주하지 않고 기능을 기준으로 설명합니다.
처음 가져온 뒤 확인할 네 가지
- 다운로드가 완료됐는지: 설정 목록에 이름, 업데이트 시간 또는 사용 가능한 항목이 표시되어야 합니다. 오류 메시지만 계속 표시된다면 가져오기에 실패한 것입니다.
- 현재 설정으로 활성화됐는지: 일부 클라이언트는 가져온 뒤 ‘활성화’를 따로 눌러야 합니다. 설정 카드가 목록에 추가된 것만으로 코어가 전환된 것은 아닙니다.
- 정책 그룹에 사용할 항목이 있는지: ‘프록시’ 또는 Proxies 화면에서 기본 정책 그룹을 펼친 뒤 노드를 직접 선택하세요.
DIRECT또는REJECT를 잘못 선택하지 않도록 주의하세요. - 모드가 규칙 모드인지: 처음에는 설정에 따라 직접 연결 또는 프록시를 결정하는 Rule/규칙 모드를 권장합니다. Global/전역 모드는 잠깐 비교 테스트할 때 사용할 수 있으며, Direct/직접 연결 모드에서는 프록시 노드를 거치지 않습니다.
가져오는 중 YAML 파싱 오류가 발생하면 구독 링크가 실제로 설정 파일을 반환하는지 먼저 확인하세요. 만료된 링크는 로그인 페이지를 반환할 수 있고, 주소를 복사할 때 매개변수를 빠뜨리면 서버에서 잘못된 내용을 보낼 수 있습니다. 오류가 난다고 설정 파일의 들여쓰기를 임의로 삭제하지 마세요. YAML은 들여쓰기로 계층을 표현하므로 수정하면 다른 오류가 생길 수 있습니다.
지원하지 않는 프록시 유형이나 설정 항목이라는 메시지가 표시되면 클라이언트에서 사용하는 코어를 확인한 뒤 제공업체에 호환되는 형식을 요청하세요. 가져오기에 성공하려고 연결 프로토콜, 암호화 또는 TLS 매개변수를 함부로 삭제하지 마세요. 설정 파일을 불러올 수 있는 것과 노드에 연결할 수 있는 것은 별개의 문제입니다.
Windows·macOS: 시스템 프록시부터 확인하고 TUN은 나중에 설정
데스크톱에서 처음 사용할 때는 클라이언트의 ‘시스템 프록시’를 켜고 브라우저에서 연결을 확인하세요. 이 설정은 보통 시스템의 HTTP/HTTPS 프록시를 로컬 수신 포트로 지정합니다. 모든 앱의 트래픽이 프록시를 거친다는 뜻은 아닙니다. 시스템 프록시를 사용하지 않는 앱은 계속 직접 연결될 수 있습니다.
| 운영체제 | 확인 경로 | 중점 확인 사항 |
|---|---|---|
| Windows 11 | 설정 → 네트워크 및 인터넷 → 프록시 | 수동 프록시가 현재 클라이언트의 로컬 주소와 포트를 가리키는지 확인하세요. |
| macOS | 시스템 설정 → 네트워크 → 현재 네트워크 서비스 → 세부사항 → 프록시 | 웹 프록시와 보안 웹 프록시가 클라이언트 설정과 일치하는지 확인하세요. |
| 클라이언트 설정 | 시스템 프록시, 포트, 실행 로그 | 화면이 열려 있는지만 확인하지 말고 코어가 시작되고 포트 수신에 성공했는지 확인하세요. |
로컬 주소와 포트를 함께 확인
일반적으로 혼합 포트는 7890이지만 클라이언트마다 다를 수 있으므로 현재 화면이나 적용된 설정을 기준으로 확인하세요. 예를 들어 클라이언트는 127.0.0.1:7890에서 수신 중인데 시스템 프록시는 이전 프로그램의 127.0.0.1:7897을 가리키면 브라우저에서 프록시 연결 오류가 발생할 수 있습니다. 혼합 포트가 HTTP와 SOCKS5 연결을 모두 받을 수 있어도 시스템 설정이 자동으로 동기화되는 것은 아닙니다.
macOS에서 네트워크 설정을 처음 변경하거나 보조 서비스를 설치할 때 관리자 인증을 요청할 수 있습니다. Windows에서도 서비스를 설치하거나 TUN 가상 네트워크 어댑터를 설정할 때 관리자 권한이 필요할 수 있습니다. 요청을 보낸 앱의 이름과 출처를 먼저 확인한 뒤 권한을 부여하세요. 일반적인 데스크톱 시스템 프록시 테스트를 위해 클라이언트를 항상 관리자 권한으로 실행할 필요는 없습니다.
설치 후 반드시 켜야 하는 기능은 아닌 TUN
TUN은 가상 네트워크 인터페이스로 트래픽을 전달하므로 시스템 프록시를 따르지 않는 앱에 유용하지만, 라우팅·DNS·권한 등 추가 변수가 생깁니다. 일반 브라우저 연결을 확인한 뒤 활성화하고, 한 번에 하나씩 설정을 변경하세요. 활성화 후 로컬 네트워크 기기, 사내 네트워크 또는 다른 VPN에 연결할 수 없다면 먼저 TUN을 끄고 비교하세요. DNS 설정을 여러 개 겹쳐 적용하지 마세요.
Android·iOS: VPN 권한과 백그라운드 제한을 따로 확인
Android: VPN 연결을 허용한 뒤 백그라운드 안정성 확인
Android 클라이언트는 보통 시스템 VPN 인터페이스를 사용해 트래픽을 전달합니다. 처음 시작 버튼을 누르면 시스템에서 VPN 연결 요청이 표시됩니다. 허용하면 상태 표시줄에 VPN 아이콘이 나타나는 경우가 많습니다. 이 아이콘은 VPN 인터페이스가 만들어졌다는 뜻일 뿐, 구독이 유효하거나 프록시 노드에 연결됐다는 의미는 아닙니다.
- 설정을 가져와 활성화하고, 정책 그룹에서 노드를 선택한 다음 연결을 시작하세요.
- 시스템에서 이미 VPN이 연결되어 있다고 알리면 기존 연결을 먼저 끊으세요. 일반적인 개인 사용 환경에서는 시스템 VPN 인터페이스를 사용하는 서비스를 한 번에 하나만 활성화할 수 있습니다.
- 화면을 잠근 뒤 약 5분 후 다시 웹페이지를 열어 인터넷 연결이 유지되는지 확인하세요. 간단한 재확인 방법이며 배터리 사용 시간을 측정하는 테스트는 아닙니다.
- 백그라운드에서 실제로 연결이 끊기는 경우에만 ‘설정 → 앱 → 해당 클라이언트 → 배터리’에서 백그라운드 제한을 확인하세요. 제조사에 따라 ‘자동 실행’이나 백그라운드 잠금 설정이 별도로 있을 수 있습니다.
Android 13 이상에서는 알림 권한을 별도로 요청할 수 있습니다. 알림 권한과 VPN 권한은 서로 다릅니다. 상시 알림은 연결 상태를 확인하는 데 도움이 되지만, 알림을 허용한다고 프록시 연결이 설정되는 것은 아닙니다. 처음부터 모든 백그라운드 유지 옵션을 켜기보다는 기본 설정이 안정적으로 작동하는지 먼저 확인하세요.
iOS: 앱별 설정 형식과 네트워크 확장 지원 확인
iOS의 프록시 앱을 모두 같은 Clash 클라이언트로 보면 안 됩니다. 앱마다 지원하는 구독 형식, 규칙 문법, 정책 그룹 기능이 다릅니다. 가져오기 전에 앱 안내를 확인해 Clash 설정을 직접 지원하는지, 아니면 서비스 제공업체에서 전용 형식을 받아야 하는지 확인하세요.
처음 실행하면 VPN 설정 추가를 허용해야 하는 경우가 많습니다. ‘설정 → 일반 → VPN 및 기기 관리’에서 관련 설정을 확인할 수 있지만, 앱 내부의 활성화 상태와 시스템 VPN 상태를 모두 확인해야 합니다. 학교나 회사에서 관리하는 기기에서는 VPN 추가가 제한될 수 있습니다. 관리 정책 안내가 표시되면 기기 관리자에게 문의하고, 출처를 알 수 없는 프로파일을 설치해 제한을 우회하지 마세요.
포트 충돌과 인증서 경고: 오류 유형별 해결 방법
포트 충돌: 프로세스를 확인하고 모르는 서비스를 함부로 종료하지 마세요
로그에 address already in use가 표시되거나 포트 바인딩에 실패한다면 해당 포트를 이미 다른 프로그램이 사용 중일 가능성이 큽니다. 이전 클라이언트와 중복 실행된 프로세스를 종료한 뒤 포트를 확인하세요. 아래 명령은 7890을 예로 들었습니다. 실제 확인할 때는 현재 수신 포트로 바꿔 입력하세요.
Windows 명령 프롬프트에서 실행:
netstat -ano | findstr :7890
로컬 주소에 해당하는 LISTENING 행을 확인하세요. 마지막 열에 PID가 표시됩니다. 그런 다음 작업 관리자의 ‘세부 정보’에서 PID로 프로그램을 찾으세요. macOS에서는 터미널에서 다음 명령을 실행할 수 있습니다.
lsof -nP -iTCP:7890 -sTCP:LISTEN
포트를 사용 중인 프로그램을 계속 실행해야 한다면 프록시 클라이언트의 혼합 포트를 사용하지 않는 번호(예: 7891)로 변경한 뒤 시스템 프록시를 다시 적용하세요. 프록시를 수동으로 설정한 브라우저, 터미널 및 기타 프로그램의 포트도 함께 변경해야 합니다. 설정 파일만 바꾸고 시스템 프록시 주소를 그대로 두지 마세요.
앱 서명, 웹사이트 인증서, 노드 TLS 오류 구분하기
- 앱 개발자를 확인할 수 없음: 설치 출처 또는 시스템 서명 확인 문제입니다. 프로젝트의 공식 배포 채널에서 운영체제 요구 사항과 설치 파일 출처를 확인하세요. 시스템 보안 기능 전체를 끄지 마세요.
- 브라우저에 웹사이트 인증서 오류가 표시됨: 먼저 시스템 날짜와 시간대, 웹사이트 도메인, 공용 Wi-Fi에서 웹 로그인이 필요한지 확인하세요. 민감한 페이지에서는 경고를 무시하고 계속 접속하지 마세요.
- 로그에 TLS 인증서 검증 실패가 표시됨: 노드 설정의 서버 이름과 인증서 유효기간, 시스템 시간을 확인한 뒤 서비스 제공업체에 문의하세요. 인증서 검증을 건너뛰는 방법을 일반적인 해결책으로 사용하지 마세요.
연결 확인: 노드·규칙·트래픽 전달 범위를 나눠 점검
지연 시간 테스트에 숫자가 표시된다고 실제 웹사이트 접속까지 확인된 것은 아닙니다. 테스트 주소에 응답했다는 것은 해당 탐색이 성공했다는 뜻일 뿐입니다. 규칙, DNS, 계정 상태 또는 출구 네트워크 제한으로 대상 사이트가 열리지 않을 수도 있습니다. 변수를 한꺼번에 바꾸지 말고 다음 순서로 확인하세요.
- 코어 로그 확인: 설정 불러오기 실패, 포트 수신 실패 또는 반복적인 재시작이 없는지 먼저 확인하세요.
- 연결 기록 확인: 프록시가 필요한 웹사이트를 브라우저에서 열고 해당 도메인의 연결 기록이 생성되는지 확인하세요. 기록이 전혀 없다면 먼저 시스템 프록시, VPN 또는 TUN이 해당 앱의 트래픽을 전달하는지 확인하세요.
- 적용된 정책 확인: 연결이 의도한 정책 그룹을 거치는지, 실수로
DIRECT에 연결되지 않았는지 확인하세요. 기록에서 거부된 것으로 표시되면 차단 규칙에 일치했는지 살펴보세요. - 노드 하나만 바꿔 재확인: 설정과 규칙은 그대로 두고 노드만 변경하세요. 연결이 복구되면 클라이언트를 다시 설치하지 말고 기존 노드를 점검하세요.
- 필요한 경우에만 잠시 전역 모드로 전환: 전역 모드에서는 연결되지만 규칙 모드에서는 안 된다면 규칙과 정책 그룹 선택을 중점적으로 확인하세요. 테스트가 끝나면 규칙 모드로 되돌리세요. 전역 모드로 바꿔도 시스템 프록시가 트래픽을 전달하는 범위가 넓어지지는 않습니다.
브라우저에서는 연결되지만 터미널에서는 안 되는 경우는 트래픽 전달 범위가 다른 흔한 사례입니다. 많은 명령줄 도구는 데스크톱 시스템 프록시 설정을 자동으로 사용하지 않습니다. 7890이 현재 HTTP 또는 혼합 포트인지 확인한 뒤 명시적으로 프록시를 지정해 요청을 비교해 보세요.
curl --proxy http://127.0.0.1:7890 --head https://example.com
Windows에서는 일부 PowerShell 환경에서 같은 이름의 별칭이 명령에 영향을 주지 않도록 curl.exe를 사용할 수 있습니다. 이 명령은 지정한 요청이 로컬 프록시를 거치는지만 확인합니다. 모든 앱의 트래픽이 전달된다는 뜻은 아니며, 대상 웹사이트의 HTTP 상태도 연결 로그와 함께 확인해야 합니다.
설정 완료 후: 필요한 설정만 유지하고 종료 상태 확인
처음 연결에 성공한 뒤 구독 자동 업데이트, 시작 프로그램 등록, TUN 설정을 검토하세요. 구독을 업데이트하면 직접 수정한 내용이 덮어써질 수 있습니다. 오래 유지해야 하는 변경 사항은 클라이언트에서 지원하는 오버라이드 또는 병합 기능을 우선 사용하고, 해당 클라이언트 안내에 따라 설정하세요.
- 필요한 정보 기록: 나중에 문제를 확인할 수 있도록 클라이언트 이름과 버전, 코어 버전, 수신 포트, 트래픽 전달 방식을 기록하세요.
- 로컬 네트워크 연결 설정 확인: 이 기기에서만 사용할 경우 ‘로컬 네트워크 연결 허용’을 끈 상태로 두세요. 같은 네트워크의 다른 기기에 프록시 포트를 노출할 필요가 없습니다.
- 정상적으로 한 번 종료: 시스템 프록시를 먼저 끈 다음 앱을 종료하고 일반 네트워크가 복구됐는지 확인하세요. 프로세스를 강제 종료하면 시스템 프록시가 더 이상 수신하지 않는 로컬 포트를 계속 가리킬 수 있습니다.
- 재부팅 후 다시 확인: 설정이 계속 활성화되어 있는지, VPN을 다시 연결해야 하는지, 포트가 바뀌었는지 확인하세요. 시스템 트레이 아이콘만 보고 판단하지 마세요.
문제가 생기면 ‘설정을 불러올 수 있는지, 코어가 시작되는지, 트래픽이 전달되는지, 정책이 올바른지, 노드에 연결되는지’를 다섯 단계로 나눠 확인하세요. 도움을 요청할 때는 운영체제와 클라이언트 버전, 민감 정보를 가린 오류 로그를 제공하세요. 구독 토큰과 노드 비밀번호 등은 반드시 삭제해야 합니다. 자세한 설정 방법은 입문 가이드에서 확인하고, 개별 설정값은 고급 설정을 참고하세요.