Clash 클라이언트 첫 설치 가이드: 플랫폼별 초기 설정과 자주 발생하는 문제

1. 설치 전 확인할 사항: 플랫폼, 아키텍처, 설정 파일 출처

Clash 클라이언트를 처음 설치한다면 먼저 세 가지를 확인하세요. 기기의 운영체제, 프로세서 아키텍처, 사용할 수 있는 설정 파일의 보유 여부입니다. 클라이언트는 로컬 프록시 연결 기능을 제공할 뿐, 연결 가능한 프록시 노드를 자동으로 만들지는 않습니다. 설정 파일이 없으면 시스템 프록시나 TUN 모드를 바꿔도 대개 문제가 해결되지 않습니다.

Clash는 프록시 코어와 관련 생태계를 통칭할 때 흔히 쓰이는 이름이며, 클라이언트는 설정 관리, 노드 선택, 시스템 설정을 담당합니다. Clash Meta는 이후 mihomo로 이름이 바뀐 생태계의 코어입니다. 클라이언트마다 사용하는 코어가 다를 수 있으므로 화면이 비슷하다고 해서 설정 항목까지 모두 호환된다고 볼 수는 없습니다. 설정을 가져오기 전에 클라이언트의 ‘정보’ 또는 코어 정보를 확인하고, 문제를 문의할 때 클라이언트와 코어 버전도 함께 알려주세요.

2. 첫 실행: 권한은 용도에 따라 확인

처음 실행할 때는 먼저 앱 화면이 정상적으로 열리는지 확인하고, 설정을 가져온 뒤 필요한 경우에만 시스템 프록시나 가상 네트워크 어댑터를 켜세요. 데스크톱의 시스템 프록시, 코어 실행, TUN 서비스는 서로 다른 기능입니다. 모든 권한 안내가 관리자 권한을 요구하는 것은 아닙니다.

Windows 및 macOS

• Windows: TUN 기능에서 서비스 설치나 관리자 권한을 요청하면 먼저 안내에 표시된 프로그램 경로를 확인하세요. 일반적인 화면 조작을 위해 항상 관리자 계정을 사용할 필요는 없습니다. Windows 보안에서 파일을 차단했다면 ‘바이러스 및 위협 방지’ → ‘보호 기록’에서 해당 항목을 확인하세요. 실시간 보호 전체를 먼저 끄지는 마세요.
• macOS: 시스템에서 실행을 차단하면 다운로드 출처와 제품이 지원하는 macOS 버전을 먼저 확인하세요. 출처가 분명하고 실행이 필요한 앱이라면 시스템 안내에 따라 ‘시스템 설정’ → ‘개인정보 보호 및 보안’을 확인하세요. 시스템 보안 기능을 전체적으로 꺼서 경고를 우회하지 마세요.
• 서비스 권한: 일부 클라이언트는 보조 서비스를 이용해 라우팅을 설정합니다. 서비스 설치에 실패하면 클라이언트의 서비스 상태와 로그를 확인하세요. 시스템 프록시를 켤 수 있다고 해서 TUN에 필요한 서비스까지 설치된 것은 아닙니다.

Android, iOS 및 Linux

• Android: 처음 프록시에 연결할 때 시스템 VPN 연결 요청이 표시되는 경우가 많습니다. 요청을 보낸 앱이 방금 설치한 클라이언트인지 확인하세요. 다른 VPN 앱이나 일부 로컬 방화벽·필터링 앱이 시스템 VPN 슬롯을 사용 중이면 먼저 연결을 해제하세요.
• iOS: 처음 연결할 때 시스템 안내에 따라 VPN 구성을 추가하고 기기 인증을 완료하세요. VPN 권한 설정과 구독 가져오기는 별개의 작업입니다. 구독을 가져온 뒤에도 연결을 시작해야 합니다.
• Linux: 그래픽 클라이언트의 시스템 프록시는 데스크톱 환경에 따라 다르게 작동할 수 있고, TUN에는 추가 권한이나 서비스가 필요한 경우가 많습니다. 제품 안내에 따라 서비스를 설정하세요. 클라이언트 디렉터리 전체에 과도한 권한을 재귀적으로 부여하거나 모든 화면을 root로 실행하지 마세요.

모바일에서는 시스템이 허용한 VPN 확장 프로그램이나 서비스를 통해 연결을 처리하므로 앱을 계속 화면에 띄워 둘 필요는 없습니다. Android에서 화면을 잠근 뒤 연결이 끊긴다면 ‘설정’ → ‘앱’ → 해당 클라이언트 → ‘배터리’에서 백그라운드 제한을 확인하세요. 메뉴 이름은 제조사마다 다를 수 있습니다. iOS에서는 VPN 상태와 클라이언트 연결 로그를 먼저 확인하세요. 백그라운드 앱 정리 방지를 연결 문제 해결책으로 대신할 수는 없습니다.

3. 설정 가져오기: 내용을 확인한 뒤 연결 시작

1. 클라이언트의 ‘설정’ 또는 ‘구독’ 화면에서 ‘새로 만들기’, ‘추가’ 또는 가져오기 메뉴를 선택하세요. 제품마다 메뉴 이름은 다르지만, 새 설정 항목을 만드는 작업입니다.
2. 서비스 제공자가 안내한 호환 구독 링크를 붙여 넣거나 로컬 YAML 파일을 선택하세요. 계정 관리 웹페이지 주소를 구독 주소로 사용하지 마세요.
3. 다운로드와 파싱이 끝날 때까지 기다린 뒤 업데이트 시간, 노드 목록, 프록시 그룹이 표시되는지 확인하세요. 구독 이름만 목록에 보인다고 설정을 사용할 수 있는 것은 아닙니다.
4. 해당 설정을 현재 사용 항목으로 지정하세요. 클라이언트에서 ‘다운로드’와 ‘사용’을 따로 구분한다면 사용 설정도 완료해야 합니다.
5. ‘프록시’ 화면에서 설정에 포함된 선택 그룹의 노드를 하나 고른 다음 연결을 테스트하세요.

구독 업데이트에 실패하면 먼저 오류가 발생한 단계를 확인하세요. 다운로드 시간 초과는 가져오기 단계의 문제입니다. 로그인 페이지, 인증 코드 화면, 오류 안내 페이지가 반환된다면 응답 내용에 문제가 있습니다. YAML 줄 번호나 필드 형식 오류가 표시될 때 설정 파싱을 점검하세요. 모든 실패를 노드 문제로 단정하지 마세요.

로컬에서 YAML을 편집할 때는 공백으로 들여쓰고 Tab과 섞어 쓰지 마세요. proxy-providers 또는 rule-providers가 포함된 설정은 원격 리소스도 다운로드해야 할 수 있습니다. 기본 설정을 가져온 뒤 제공자 리소스가 모두 로드됐는지 확인하세요. 구형 코어가 새 필드를 인식하지 못하면 오류를 없애려고 필드를 무작정 삭제하지 말고, 설정에서 요구하는 코어 기능을 확인하세요.

4. 초기 설정: 혼합 포트, 트래픽 모드, 로컬 수신

데스크톱에서는 먼저 간단한 연결 경로를 확인하는 것이 좋습니다. 현재 설정이 유효한지, 코어가 실행 중인지 확인하고 규칙 모드를 선택한 다음 로컬 수신 포트를 확인하고 시스템 프록시를 켜세요. Android와 iOS는 보통 클라이언트의 연결 버튼으로 시스템 VPN을 시작하므로 데스크톱의 시스템 프록시 설정을 그대로 따라 할 필요는 없습니다.

규칙·전역·직접 연결 모드 차이

‘규칙’은 현재 설정의 매칭 순서에 따라 연결 방식을 선택합니다. ‘전역’은 코어가 처리하는 트래픽을 전역 선택 그룹으로 보냅니다. ‘직접 연결’은 기기에서 대상에 바로 접속합니다. 전역 모드로 바꿔도 시스템 프록시를 사용하지 않는 앱이 자동으로 코어에 연결되는 것은 아닙니다. 특정 사이트에 접속할 수 없다면 규칙 문제인지 확인하기 위해 모드를 잠시 바꿔 볼 수 있습니다. 테스트가 끝나면 원래대로 돌려놓으세요. 전역 모드를 시스템 전체 트래픽을 처리하는 스위치로 사용해서는 안 됩니다.

최소 설정 예시의 용도

아래 내용은 mihomo에서 자주 사용하는 필드를 이해하기 위한 예시일 뿐, 완전한 네트워크 설정이 아니며 구독 설정을 그대로 덮어쓰는 용도가 아닙니다. 포트는 이 기기에 설정된 실제 값에 맞추세요. 그래픽 클라이언트가 해당 필드를 생성하거나 덮어쓸 수도 있습니다.

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

127.0.0.1은 기기의 루프백 주소입니다. 프록시 포트와 컨트롤러 포트는 용도가 다릅니다. 브라우저 프록시 서버에 대시보드 연결용 컨트롤러 주소를 입력하지 마세요. 처음 설치할 때 컨트롤러를 LAN 기기에 개방할 필요도 없습니다.

5. 연결 확인 순서: 코어, 명시적 프록시, 브라우저

트레이 아이콘이나 연결 스위치만 보고 성공 여부를 판단하지 마세요. 아래 순서대로 테스트하고 한 번에 조건 하나씩만 바꾸세요. 먼저 로그에 설정 로드나 포트 수신 오류가 없는지 확인한 다음 노드를 선택하고, 명시적 프록시 요청과 브라우저 접속 결과를 비교하세요.

요청 한 번으로 로컬 포트 확인

아래 명령은 혼합 포트가 실제로 7890이라고 가정합니다. Windows PowerShell에서는 일부 환경에서 curl이 다른 명령으로 해석되는 일을 피하기 위해 curl.exe를 사용하세요. macOS와 Linux에서는 curl을 사용합니다. 최대 대기 시간은 15초이며 시스템 프록시 설정은 변경하지 않습니다.

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

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

• 연결 거부: 먼저 코어가 실행 중인지, 포트 번호가 맞는지, 클라이언트가 다른 주소에서만 수신 중인지 확인하세요.
• CONNECT 성공 메시지만 표시됨: HTTP 프록시 터널은 연결됐을 수 있지만, 대상 사이트의 후속 응답도 확인해야 합니다. 이 메시지만으로 HTTPS 요청 전체가 성공했다고 판단할 수는 없습니다.
• 대상 사이트의 응답을 받음: 이번 요청이 로컬 프록시를 거쳐 완료됐다는 뜻입니다. 403 등의 상태 코드는 대상 사이트의 정책에 따른 것일 수 있으며, 모든 사이트에 접속할 수 있다는 의미는 아닙니다.
• 시간 초과 또는 TLS 오류: 클라이언트 로그에서 노드, DNS, 시스템 시간, 대상 사이트를 확인하세요. 인증서 검증을 바로 비활성화하지 마세요.

명시적 프록시 요청은 성공하지만 브라우저에서 실패한다면 브라우저 프록시 확장 프로그램, 사용자 지정 프록시, 시스템 예외 목록을 확인하세요. 브라우저는 되지만 터미널에서 직접 요청이 실패해도 클라이언트 문제라고 단정할 수 없습니다. 터미널 도구는 데스크톱의 시스템 프록시 설정을 따르지 않는 경우가 많습니다. 명령에 --proxy 옵션을 추가하거나 프록시 환경 변수를 지원하는 도구에 별도로 설정할 수 있습니다.

지연 시간 측정 결과는 클라이언트가 특정 테스트 주소까지 측정한 값일 뿐, 다운로드 속도를 나타내거나 모든 사이트에 접속할 수 있음을 보장하지 않습니다. 프록시 그룹에서 선택된 노드를 확인한 다음 ‘연결’ 화면이나 로그의 규칙 및 출구 기록을 살펴보고 요청이 실제로 어떤 경로를 거쳤는지 확인하세요.

6. 첫 설치 후 자주 발생하는 문제: 증상별 확인

포트 충돌: 같은 주소는 한 프로세스만 수신 가능

로그에 address already in use 또는 바인딩 실패가 표시되면 이전 프록시 클라이언트, 중복 실행된 코어, 같은 포트를 사용하는 디버깅 도구를 먼저 종료하세요. Windows에서는 netstat -ano | findstr :7890을 실행해 로컬 주소, 상태, PID를 확인하세요. 원격 주소에만 7890이 표시된 연결을 수신 프로세스로 오해하지 마세요. macOS에서는 lsof -nP -iTCP:7890 -sTCP:LISTEN, Linux에서는 ss -ltnp을 실행해 수신 상태를 확인하세요. 프로세스 상세 정보를 보려면 추가 권한이 필요할 수 있습니다.

프로세스가 무엇인지 확인한 뒤 종료하세요. 정체를 모르는 시스템 프로세스를 바로 끝내지 마세요. 포트를 7891로 바꾼다면 새 포트가 사용 중이 아닌지 확인하고 시스템 프록시, 브라우저 사용자 지정 프록시, 테스트 명령도 함께 수정해야 합니다. 클라이언트 포트만 바꾸면 다른 앱은 계속 이전 주소에 연결합니다.

화면은 열리지만 코어가 시작되지 않음

먼저 로그에서 실행 파일 누락, 아키텍처 불일치, 설정 파싱 실패, 권한 부족 중 어떤 문제인지 확인하세요. 보안 프로그램이 코어를 격리해도 클라이언트 화면은 열릴 수 있으므로 보호 기록과 클라이언트의 코어 경로를 함께 확인해야 합니다. 파일 출처, 보안 알림 내용, 제품 안내를 확인한 뒤 해당 파일만 처리하세요. 다운로드 폴더 전체를 계속 예외로 등록하지 마세요.

TUN을 켠 뒤 인터넷이 끊기거나 내부 네트워크에 접속할 수 없음

먼저 TUN을 끄고, 이전에 정상 작동을 확인한 시스템 프록시 경로로 되돌리세요. 그런 다음 다른 VPN이 실행 중인지, 보조 서비스가 정상인지, 회사 내부 네트워크 경로가 덮어써졌는지, DNS 설정이 현재 네트워크와 충돌하는지 확인하세요. TUN은 라우팅과 이름 해석에 영향을 주므로 tun: 설정 한 부분만 복사해도 모든 플랫폼과 네트워크에서 작동한다고 보장할 수 없습니다. 회사 기기에서는 관리 정책을 우선 따르고, 테스트를 위해 관리되는 라우팅 설정을 강제로 바꾸지 마세요.

클라이언트를 종료한 뒤에도 브라우저에서 인터넷에 연결할 수 없음

이 경우 브라우저를 다시 설치하기보다 남아 있는 시스템 프록시 설정을 확인하세요. Windows 11에서는 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’에서 수동 프록시를 확인할 수 있습니다. macOS에서는 ‘시스템 설정’ → ‘네트워크’ → 현재 네트워크 → ‘세부사항’ → ‘프록시’를 확인하세요. 중지된 로컬 포트를 가리키고 있다면 설치 전 설정으로 되돌리세요. 조직에서 관리하는 PAC 또는 프록시 주소는 임의로 삭제하지 마세요.

7. 설치 완료 점검 및 이후 관리

• 설치 파일의 아키텍처가 맞는지, 클라이언트와 코어가 모두 실행되는지, 로그에 같은 오류가 반복해서 나타나지 않는지 확인하세요.
• 현재 설정이 활성화되어 있고 프록시 그룹에서 선택할 노드가 있으며 구독 제공자 리소스가 로드됐는지 확인하세요.
• 실제 혼합 포트와 현재 트래픽 모드를 기록해 두세요. 이 글의 예시 포트가 기기마다 고정된 값은 아닙니다.
• 데스크톱에서는 명시적 프록시 요청과 브라우저 접속을 각각 한 번씩 테스트하세요. 모바일에서는 시스템 VPN 상태를 확인하고 대상 페이지를 직접 열어 보세요.
• 기기를 다시 시작한 뒤 클라이언트가 설정대로 시작되는지, 시스템 프록시 또는 VPN 상태가 클라이언트 실행 상태와 일치하는지 확인하세요.
• 설치 전 프록시 설정과 설정 파일의 사본을 보관하고 연결을 종료한 뒤 네트워크가 정상적으로 복구되는지 확인하세요.

처음 연결이 확인된 뒤에 시작 프로그램 등록, 구독 자동 업데이트, TUN 사용 여부를 결정하세요. 구독 업데이트 주기는 서비스 제공자의 안내를 따르세요. 연결 문제를 해결하려고 매분 새로 고칠 필요는 없습니다. 클라이언트를 업그레이드하기 전에 버전과 현재 설정을 기록하세요. 업그레이드 후에는 설정 로드, 포트 수신, 자주 사용하는 앱을 먼저 확인한 다음 복잡한 규칙이나 LAN 공유를 다시 설정하세요.

도움을 요청할 때는 운영체제 버전, 프로세서 아키텍처, 클라이언트 버전, 코어 버전, 작업 순서, 오류 발생 시각 전후의 로그를 제공하세요. ‘명시적 프록시는 성공하지만 브라우저는 실패한다’고 설명하면 단순히 ‘연결할 수 없다’고 하는 것보다 원인을 찾기 쉽습니다. 로그와 스크린샷을 공유하기 전에 구독 인증 정보를 삭제하세요. 특정 사이트에서만 발생하는 문제라면 규칙 모드에서만 나타나는지도 알려주세요.