Clash 초보자 가이드: 클라이언트 선택과 안전한 다운로드 방법
Clash는 플랫폼마다 앱 이름과 설치 방식이 달라 처음 시작할 때 혼란스럽습니다. 이 글에서 자신에게 맞는 클라이언트를 고르는 기준과 믿을 만한 다운로드 경로를 확인하고, 설치 전에 점검할 위험 신호까지 알아보세요.
클라이언트 선택이 먼저인 이유
Clash를 처음 사용할 때 가장 많이 하는 실수는 운영체제만 보고 아무 설치 파일이나 내려받는 것입니다. 실제로는 같은 Clash라는 이름을 사용해도 그래픽 화면을 제공하는 클라이언트와 트래픽을 처리하는 커널이 서로 다를 수 있습니다. Windows에서는 Clash Verge Rev, Clash for Windows 계열, Mihomo Party처럼 여러 선택지가 있고, macOS에서는 ClashX 계열이나 새로운 mihomo 기반 앱을 비교해야 합니다. Android와 iOS는 데스크톱과 설치 방식 및 권한 모델이 완전히 다르므로 별도의 기준이 필요합니다.
클라이언트는 설정 파일을 불러오고, 노드를 선택하고, 시스템 프록시 또는 TUN 모드를 켜는 사용자 인터페이스입니다. 실제 규칙 매칭과 연결 처리는 내부 커널이 담당합니다. 현재 새 프로토콜과 TUN 기능을 폭넓게 사용하려면 오리지널 Clash보다 Clash Meta에서 이름이 바뀐 mihomo 기반 클라이언트를 우선 검토하는 편이 현실적입니다. 단, 클라이언트 이름에 mihomo가 들어 있다고 해서 모든 기능이 자동으로 활성화되는 것은 아니므로 정보 화면에서 커널명과 버전을 직접 확인해야 합니다.
- 처음 시작하는 Windows 사용자라면 설정 화면이 비교적 명확하고 mihomo 커널을 선택할 수 있는 클라이언트를 고릅니다.
- macOS 사용자라면 Apple Silicon과 Intel 중 자신의 CPU에 맞는 빌드가 제공되는지, 시스템 확장 권한을 정상적으로 요청하는지 확인합니다.
- Android 사용자라면 APK 설치 여부보다 업데이트 경로와 VPN 권한, 배터리 절전 예외 설정을 먼저 살펴봅니다.
- iOS 사용자라면 App Store에서 실제로 설치 가능한지와 VPN 구성 추가 권한을 지원하는지 확인합니다. 데스크톱용 설치 파일을 iPhone에 사용할 수는 없습니다.
커널과 플랫폼별 선택 기준
커널의 유지보수 상태는 단순한 신기능 문제만이 아닙니다. 운영체제가 업데이트되면 네트워크 권한, 가상 인터페이스, TLS 라이브러리와의 호환성도 바뀔 수 있습니다. 장기간 업데이트가 멈춘 커널은 현재의 구독 설정이나 새로운 프로토콜을 처리하지 못하고, 오류가 발생해도 수정본을 기대하기 어렵습니다. 따라서 설치 전에 클라이언트의 정보 페이지에서 커널이 오리지널 Clash인지, Clash Meta 또는 mihomo인지 확인하는 습관이 필요합니다.
| 플랫폼 | 우선 확인할 항목 | 초보자에게 적합한 기준 | 주의할 점 |
|---|---|---|---|
| Windows | mihomo 지원, TUN 권한, 시스템 프록시 | 설정과 로그 메뉴가 분명한 최신 클라이언트 | 관리자 권한과 Windows 방화벽 알림 확인 |
| macOS | CPU 빌드, 네트워크 확장, 로그인 항목 | Apple Silicon 또는 Intel에 맞는 공식 빌드 | 개인정보 보호 및 보안에서 실행 허용 필요 |
| Android | VPN 서비스, 배터리 제한, 앱 권한 | 업데이트 가능한 신뢰 경로에서 받은 앱 | APK 출처와 서명 정보를 확인한 뒤 설치 |
| iOS | App Store 배포, VPN 구성 추가 | 현재 지역에서 정상적으로 내려받을 수 있는 앱 | iOS용 앱은 데스크톱 설정 파일과 동작 방식이 다름 |
| Linux | 배포 형식, 권한, TUN 장치 | 배포판과 아키텍처에 맞는 패키지 | systemd-resolved와 포트 충돌 점검 |
Windows에서 오래된 Clash for Windows를 선택하면 기존 설정과의 호환성은 얻을 수 있지만, 현재 필요한 mihomo 전용 기능이나 새로운 프로토콜 지원은 제한될 수 있습니다. 반대로 기능이 많은 클라이언트는 설정 항목이 복잡하므로 처음부터 모든 옵션을 바꾸지 않는 것이 좋습니다. 기본 모드로 구독을 가져온 뒤, 노드 선택과 시스템 프록시가 정상적으로 동작하는지 확인하고 TUN은 필요한 경우에만 단계적으로 켜세요.
클라이언트와 커널을 혼동하지 마세요
클라이언트 이름이 익숙하다는 이유만으로 최신 기능을 지원한다고 판단하면 안 됩니다. 정보, About 또는 Core 메뉴에서 커널명이 mihomo인지, 버전이 표시되는지, 마지막 업데이트 시점이 지나치게 오래되지 않았는지 함께 확인해야 합니다.
안전한 다운로드 경로 확인하기
안전한 설치의 첫 단계는 검색 결과의 첫 번째 버튼을 누르지 않는 것입니다. 검색 광고, 재배포 페이지, 파일 공유 링크, 압축 파일 안의 별도 실행 프로그램은 공식 배포 여부를 확인하기 어렵습니다. 특히 “최신 버전”, “속도 향상”, “인증 우회” 같은 문구를 앞세우면서 설치 전에 알 수 없는 권한이나 추가 프로그램을 요구하는 파일은 피해야 합니다.
이 사이트의 다운로드 센터에서는 플랫폼별 선택 기준과 설치 방식부터 확인할 수 있습니다. 다만 다운로드 페이지에 표시된 앱 이름만 보고 판단하지 말고, 자신의 운영체제와 CPU 아키텍처가 일치하는지 확인하세요. Windows용 파일을 macOS에서 실행할 수 없고, macOS의 arm64 빌드와 Intel용 x64 빌드는 서로 대체되지 않습니다.
- 운영체제와 아키텍처를 확인합니다. Windows는 시스템 정보에서 64비트 여부를 확인하고, macOS는 “이 Mac에 관하여”에서 Apple 칩 또는 Intel을 확인합니다.
- 배포 파일 형식을 확인합니다. Windows는 설치형 또는 포터블 압축 파일, macOS는 DMG 또는 앱 패키지, Android는 APK, iOS는 App Store 앱으로 구분됩니다.
- 파일 이름과 확장자를 확인합니다. 실행 파일 뒤에 이중 확장자가 붙거나, 압축 해제를 위해 별도의 “인증 도구”를 실행하라고 하면 설치를 중단합니다.
- 권한 요청을 읽습니다. 프록시와 TUN에는 네트워크 관련 권한이 필요할 수 있지만, 연락처·문자·사진 전체 접근처럼 기능과 관계없는 권한은 허용하지 않습니다.
- 설치 후 정보 화면을 확인합니다. 앱 이름, 커널 이름, 버전, 설정 디렉터리를 확인하고 예상과 다르면 구독 링크를 입력하지 않습니다.
구독 링크를 설치 파일과 함께 배포하지 마세요
구독 URL은 계정 토큰이 포함된 인증 정보입니다. 설치 프로그램이나 설정 파일에 미리 들어 있거나, 다운로드 페이지에서 무작위 문자열을 입력하라고 요구한다면 신뢰하지 마세요. 구독은 사용 중인 서비스 제공자가 발급한 주소를 직접 복사해 클라이언트의 Profiles 메뉴에 추가해야 합니다.
직접 설치하고 첫 연결 점검하기
이제 파일을 설치한 뒤 실제 연결이 정상인지 확인해 보겠습니다. 처음부터 전역 프록시와 TUN을 동시에 켜면 문제가 생겼을 때 원인을 구분하기 어렵습니다. 아래 순서는 시스템에 미치는 변경을 최소화하면서 클라이언트, 구독, 노드, 프록시 순서를 차례로 검증하는 방법입니다.
- 클라이언트를 설치하고 처음 실행합니다. Windows 방화벽이나 macOS 네트워크 확장 권한이 표시되면 앱의 네트워크 기능에 필요한 요청인지 읽은 뒤 허용합니다.
- Profiles 또는 프로필 메뉴에서 서비스 제공자가 발급한 구독 URL을 추가합니다. 주소 앞뒤에 공백이 들어가지 않도록 전체 문자열을 복사하고, 공개 채팅이나 문서에 붙여넣지 않습니다.
- 프로필 다운로드가 끝나면 해당 프로필을 선택해 활성화합니다. 프로필을 추가만 하고 선택하지 않으면 노드 목록이 나타나지 않거나 이전 설정이 계속 사용될 수 있습니다.
- 노드 또는 Proxies 메뉴에서 지연시간이 지나치게 높거나 연결 실패로 표시되는 노드를 제외하고 하나를 선택합니다. 지연시간 숫자는 연결 가능성의 참고값이지 실제 웹 체감 속도와 같은 뜻은 아닙니다.
- Mode 메뉴에서 먼저 Rule을 선택하고 시스템 프록시를 켭니다. 브라우저에서 일반 웹페이지를 열어 연결 여부를 확인한 뒤, 클라이언트 로그에서 요청이 어느 정책 그룹으로 전달됐는지 확인합니다.
- 시스템 프록시를 사용하지 않는 앱까지 처리해야 할 때만 TUN을 켭니다. TUN을 켠 뒤에는 다른 VPN, 가상 네트워크 도구, 수동 프록시를 함께 사용하지 말고 충돌 여부를 먼저 확인합니다.
- 테스트가 끝나면 프록시를 끄고 원래 네트워크로 돌아오는지 확인합니다. 종료 후에도 인터넷이 끊기면 시스템 프록시, TUN 인터페이스, 자동 시작 설정이 남아 있는지 점검합니다.
Rule 모드는 일반적으로 국내 주소는 DIRECT, 그 밖의 요청은 선택한 프록시 그룹으로 보내도록 구성됩니다. Global 모드는 모든 요청을 프록시로 보내므로 테스트에는 편리하지만 국내 서비스와 로컬 장치까지 우회할 수 있습니다. 처음부터 Global을 기본값으로 사용하기보다 Rule 모드에서 로그와 규칙 결과를 확인하는 편이 문제를 찾기 쉽습니다.
설치 전후에 살펴볼 위험 신호
악성 파일은 반드시 실행 직후 눈에 띄는 오류를 보여주지는 않습니다. 정상적인 화면과 노드 목록을 표시하면서도 과도한 권한을 요구하거나, 설정 파일과 구독 정보를 외부로 전송할 가능성이 있습니다. 아래 항목 중 하나라도 해당하면 설치를 멈추고 배포 경로를 다시 확인하세요.
- 클라이언트 본체와 관계없는 별도 “활성화 프로그램”, “패치”, “속도 최적화 도구”를 먼저 실행하라고 합니다.
- 설치 중 브라우저 확장, 검색 도구, 알 수 없는 백그라운드 프로그램을 함께 설치하도록 선택되어 있습니다.
- 앱 이름과 파일 이름이 서로 다르거나, 압축 파일 안에 실행 파일이 여러 개 있는데 어느 파일이 본체인지 설명이 없습니다.
- 프로필을 추가하기 전에 이메일 비밀번호, 지갑 정보, 운영체제 로그인 비밀번호를 입력하라고 합니다.
- Android에서 접근성 서비스, SMS, 연락처, 통화 기록을 요구하거나, iOS에서 VPN 기능과 무관한 권한을 반복적으로 요청합니다.
- 설치 후 CPU와 메모리 사용량이 계속 높고, 앱을 종료해도 알 수 없는 프로세스가 자동으로 다시 실행됩니다.
정상적인 네트워크 클라이언트도 TUN, 시스템 프록시, VPN 구성, 방화벽과 관련된 권한을 요청할 수 있습니다. 중요한 것은 권한의 종류와 기능의 관계입니다. Windows의 관리자 권한은 서비스 설치나 가상 어댑터 구성에 사용될 수 있고, Android의 VPN 연결 요청은 트래픽을 가상 VPN 인터페이스로 전달하기 위한 시스템 절차입니다. 그러나 이런 권한이 왜 필요한지 설명하지 않거나, 설치 프로그램이 임의의 개인정보를 요구한다면 허용하지 않는 것이 안전합니다.
이미 의심스러운 파일을 실행했다면
먼저 네트워크 연결을 끊고 클라이언트를 종료한 뒤, 운영체제의 앱 목록과 시작 프로그램에서 함께 설치된 항목을 확인하세요. 구독 URL이나 계정 정보가 입력된 상태였다면 서비스 제공자 관리 화면에서 해당 구독을 폐기하고 새 주소를 발급받습니다. 같은 비밀번호를 다른 곳에서 사용했다면 별도의 신뢰할 수 있는 기기에서 비밀번호도 변경하세요.
설치 후 유지 관리와 문제 예방
안전한 다운로드는 설치 순간에 끝나지 않습니다. 클라이언트와 mihomo 커널은 운영체제 업데이트, 프로토콜 변경, DNS 동작 변화의 영향을 받으므로 일정한 관리가 필요합니다. 새 버전이 나왔다는 이유만으로 무조건 덮어쓰기보다 현재 프로필과 사용자 설정을 먼저 보존하고, 변경 내역을 확인한 뒤 업데이트하세요.
- 프로필을 분리합니다. 구독에서 내려받은 원본 프로필과 직접 수정한 로컬 설정을 구분하면 갱신 때 사용자 규칙이 사라지는 문제를 줄일 수 있습니다.
- 로그를 확인합니다. 연결 실패가 발생하면 노드 자체의 문제인지, DNS 해석 실패인지, 규칙이 DIRECT로 잘못 매칭됐는지 로그에서 먼저 구분합니다.
- 자동 업데이트를 신중히 사용합니다. 출처가 불분명한 자동 업데이트 창이 뜨면 닫고 다운로드 센터에서 현재 안내된 경로를 다시 확인합니다.
- TUN을 최소한으로 사용합니다. 전체 트래픽 인수는 편리하지만 로컬 네트워크, 게임, 은행 앱과 충돌할 수 있습니다. 필요한 장치와 앱에서만 켜고 문제가 생기면 시스템 프록시 모드로 되돌립니다.
- DNS와 규칙을 함께 점검합니다. 웹페이지는 열리는데 특정 도메인만 실패하면 노드 교체 전에 DNS 모드, fake-ip 예외, 규칙의 MATCH 순서를 확인합니다.
구독 갱신이 실패할 때는 먼저 URL 만료, 계정 사용량 제한, 시스템 시간 오류를 확인합니다. TLS 연결은 기기의 날짜와 시간이 크게 어긋나면 실패할 수 있습니다. 갱신 결과가 비어 있으면 프로필을 여러 번 추가하지 말고 기존 항목을 확인한 뒤, 현재 활성 프로필과 업데이트 시각을 비교하세요. 같은 구독을 반복해서 추가하면 이름이 비슷한 프로필이 늘어나 어떤 설정이 실제로 사용되는지 판단하기 어려워집니다.
처음 사용하는 경우에는 클라이언트 선택, 안전한 설치, 프로필 추가, Rule 모드 테스트, 필요할 때만 TUN 활성화라는 순서를 지키는 것이 가장 중요합니다. 플랫폼별 메뉴가 다르더라도 이 순서는 거의 변하지 않습니다. 설치 화면이나 커널 구조가 낯설다면 사용법 보기에서 기본 모드와 프로필 적용 절차를 먼저 확인한 뒤 세부 설정으로 넘어가세요.
다음 단계
자신의 운영체제에 맞는 클라이언트와 커널을 확인한 뒤, 신뢰할 수 있는 경로에서 설치 파일을 선택하세요. 설치 후에는 구독 정보를 공개하지 않고 Rule 모드부터 테스트하면 초기 오류와 보안 위험을 함께 줄일 수 있습니다.
자주 나타나는 오류와 원인별 해결법
| 증상 | 가능한 원인 | 확인할 항목 |
|---|---|---|
| 로그인 명령이 즉시 연결 거부 | Clash가 꺼져 있거나 포트가 다름 | mixed-port, HTTP 포트, 로컬 리스닝 상태 |
| 브라우저 인증은 끝났지만 CLI가 대기 | 콜백 주소가 프록시나 보안 프로그램에 의해 차단됨 | localhost를 NO_PROXY에 포함했는지 확인 |
| TLS handshake timeout | 노드 품질 저하, 잘못된 규칙, MTU 문제 | Clash 로그, 다른 노드, TUN 사용 여부 |
| 인증 성공 후 요청만 실패 | API 요청이 다른 호스트로 이동하거나 규칙에서 DIRECT 처리됨 | 요청 도메인의规则匹配 결과와 프록시 그룹 |
| 명령을 찾을 수 없음 | CLI 설치 경로가 PATH에 없음 | codex --help, 운영체제 PATH, 설치 방식 |
| 인증 정보가 반복해서 사라짐 | 권한 문제, 임시 컨테이너, 자격 증명 저장 실패 | 설정 디렉터리 쓰기 권한과 실행 환경 |
로그인 콜백이 멈추는 경우에는 NO_PROXY가 지나치게 넓게 설정되지 않았는지 확인하세요. localhost와 127.0.0.1은 로컬 콜백을 위해 직접 연결하는 것이 일반적이지만, 외부 인증 서버 도메인을 무심코 NO_PROXY에 넣으면 브라우저 인증 페이지와 CLI의 인증 요청이 서로 다른 경로로 나갈 수 있습니다.
반대로 TUN 모드에서 localhost까지 가상 인터페이스로 보내면 콜백 서버가 정상적으로 응답하지 않을 수 있습니다. 이런 환경에서는 DNS 하이재킹과 자동 라우팅을 켜더라도 로컬 주소 예외를 유지하세요. TUN을 켠 뒤 문제가 시작됐다면 TUN을 끄고 환경 변수 방식으로 재시험하면 원인을 빠르게 분리할 수 있습니다.
프록시 오류와 인증 오류를 구분하세요
“connection refused”, “timeout”, “TLS handshake”는 대체로 네트워크 경로 문제이고, 인증 만료·권한 부족·잘못된 계정은 서버가 반환하는 인증 단계의 오류입니다. 전자는 Clash 로그와 포트를 먼저 보고, 후자는 Codex CLI의 로그아웃 후 재로그인과 계정 권한을 확인해야 합니다.
TUN과 DNS를 사용할 때의 추가 점검
Codex CLI가 실행하는 셸 명령이나 패키지 도구까지 같은 네트워크 정책으로 처리해야 한다면 TUN 모드가 편리할 수 있습니다. 다만 TUN은 단순히 브라우저를 프록시로 바꾸는 기능이 아니라 시스템 라우팅과 DNS 흐름을 변경하는 기능입니다. Windows에서는 서비스 모드와 관리자 권한이 필요할 수 있고, macOS에서는 네트워크 확장 또는 VPN 구성 허용이 요구될 수 있습니다.
mihomo 기반 클라이언트에서는 auto-route, auto-detect-interface, dns-hijack 설정이 서로 맞물립니다. 자동 라우팅이 꺼져 있으면 TUN 인터페이스가 만들어져도 일부 트래픽이 기존 네트워크 카드로 빠질 수 있습니다. DNS 하이재킹이 빠지면 도메인 조회는 운영체제 DNS로 남아 규칙 매칭이 불안정해질 수 있습니다. fake-ip을 사용하는 경우 198.18.0.1/16과 같은 가상 대역이 로컬 네트워크 규칙에 의해 차단되지 않는지도 확인하세요.
- Clash 로그에서 DNS 요청이 기록되는지 확인합니다.
nslookup또는dig결과가 매번 바뀌는지, 특정 잘못된 주소가 반복되는지 비교합니다.- 사내 도메인과 로컬 프린터 주소는
NO_PROXY또는 DIRECT 규칙으로 분리합니다. - 패키지 설치 명령이 실패하면 Codex 자체가 아니라 패키지 저장소의 인증서, 별도 프록시 설정, 저장소 정책을 확인합니다.
터미널 명령 실행을 허용할 때는 네트워크가 안정적이라는 이유만으로 모든 명령을 자동 승인하지 마세요. Codex CLI가 파일을 수정하거나 외부 패키지를 설치하도록 설정되어 있다면 프로젝트 디렉터리, 셸 권한, 환경 변수에 저장된 비밀 정보까지 함께 고려해야 합니다. 먼저 읽기 작업으로 검증하고, 변경 작업은 명령별로 확인하는 것이 안전합니다.
FAQ: Codex CLI와 Clash 연결 문제
시스템 프록시를 켰는데도 Codex CLI가 직접 연결되는 이유는 무엇인가요?
터미널 프로그램이나 내부 HTTP 라이브러리가 운영체제의 시스템 프록시를 읽지 않을 수 있습니다. 현재 셸에 HTTP_PROXY와 HTTPS_PROXY를 직접 지정한 뒤 다시 실행하세요. 그래도 로그가 보이지 않으면 TUN 모드로 비교 테스트를 진행해 프로세스가 프록시 변수를 무시하는지 확인할 수 있습니다.
HTTP_PROXY와 HTTPS_PROXY에 서로 다른 포트를 넣어야 하나요?
Clash의 mixed 포트를 사용한다면 두 변수에 같은 HTTP 주소를 넣어도 됩니다. 다만 실제 클라이언트에서 HTTP와 SOCKS 포트가 분리되어 있다면 HTTPS 요청에 SOCKS 포트를 HTTP 주소로 입력하지 않도록 주의하세요. 포트 형식과 프로토콜이 맞지 않으면 연결 거부 또는 TLS 오류가 발생합니다.
Codex 로그인 후에는 환경 변수를 삭제해도 되나요?
로그인 정보가 안전하게 저장되고 이후 요청이 직접 연결로도 허용되는 환경이라면 가능하지만, 인증 후 API 요청도 프록시가 필요한 네트워크라면 환경 변수를 계속 유지해야 합니다. 테스트할 때는 변수를 삭제한 새 셸에서 간단한 요청을 실행해 인증 경로와 실제 작업 경로가 모두 정상인지 구분하세요.
노드를 바꾸면 Codex CLI 인증을 다시 해야 하나요?
일반적으로 노드 변경만으로 저장된 인증 정보가 사라지지는 않습니다. 그러나 출구 지역이나 IP가 바뀌면서 보안 확인이 추가되거나, 이전 연결이 만료되어 재인증이 요구될 수 있습니다. 짧은 시간에 여러 지역의 노드를 반복해서 바꾸기보다 안정적인 하나의 그룹을 선택하고 Clash 로그에서 연결 상태를 확인하세요.
다음 단계: Clash 설정과 Codex 실행 환경 정리
Codex CLI 연결 문제는 대부분 클라이언트 자체보다 로컬 포트, 셸 환경 변수, DNS 경로, 규칙 순서 중 하나에서 발생합니다. 먼저 mixed 포트와 전역 연결을 이용해 기본 경로를 검증한 뒤, 규칙 모드와 TUN 모드로 범위를 좁히면 불필요한 설정 변경을 줄일 수 있습니다. 설치 파일과 클라이언트 선택이 아직 정해지지 않았다면 다운로드 센터에서 플랫폼에 맞는 mihomo 기반 클라이언트를 확인하고, 적용 후에는 단계별 튜토리얼에 따라 프로필과 프록시 모드를 설정하세요.