Clash 클라이언트 최초 설치 및 초기 설정: macOS·Windows·Android 공통 설정과 문제 해결 체크리스트

1. 설치 순서: 코어를 실행한 다음 트래픽 연결

데스크톱에서는 ‘설치 파일 선택 → 클라이언트 실행 → 설정 가져오기 → 로컬 포트 확인 → 시스템 프록시 켜기 → 연결 확인’ 순서로 처음 설정합니다. 먼저 브라우저가 시스템 프록시를 통해 정상적으로 접속되는지 확인한 뒤 TUN 사용 여부를 결정하세요. Android는 보통 시스템 VPN 인터페이스로 트래픽을 처리하므로 데스크톱의 시스템 프록시 설정을 그대로 적용할 수 없습니다.

Clash는 설정 및 프록시 생태계에서 널리 쓰이는 이름이며, 클라이언트 인터페이스와 실제 연결을 처리하는 코어는 서로 다른 구성 요소입니다. mihomo는 Clash Meta에서 이어져 발전한 코어입니다. 클라이언트마다 지원하는 설정 필드와 서비스 모드, 권한이 다를 수 있습니다. 설정 가져오기에 실패하면 ‘Clash를 설치했다’고만 하지 말고 클라이언트 이름과 버전, 코어 버전을 함께 기록하세요.

기존 네트워크 설정을 기록하세요. 사용 중인 VPN, 시스템 프록시, 수동 DNS를 적어 두면 변경 후 원래 상태로 되돌리기 쉽습니다.
프록시 클라이언트는 하나만 실행하세요. 기존 클라이언트를 종료하고, 최초 테스트 중에는 다른 TUN이나 VPN을 함께 켜지 마세요.
사용 가능한 설정을 준비하세요. 클라이언트 설치 파일에는 보통 사용할 수 있는 프록시 노드가 포함되어 있지 않으므로 구독 정보를 별도로 준비해야 합니다.
한 번에 하나씩 변경하세요. 설정을 바꿀 때마다 로그와 연결 기록을 확인하세요. 포트, DNS, 규칙을 한꺼번에 변경하면 문제 원인을 찾기 어렵습니다.

2. 설치 파일 선택: 운영체제, 프로세서, 코어 지원 확인

플랫폼	먼저 확인할 위치	선택 기준
macOS	Apple 메뉴 → 이 Mac에 관하여	Apple 칩은 arm64, Intel 프로세서는 x64를 선택하세요. 범용 패키지는 배포 안내를 확인해 사용하면 됩니다.
Windows	설정 → 시스템 → 시스템 정보 → 시스템 종류	장치 아키텍처에 맞춰 x64 또는 ARM64를 선택하고, 클라이언트의 최소 시스템 요구 사항도 확인하세요.
Android	설정 → 휴대전화 정보에서 확인하세요. 아키텍처는 기기 사양을 기준으로 판단합니다.	일반적인 기기는 arm64-v8a를 사용합니다. 구형 기기는 armeabi-v7a가 필요할 수 있으니 확실하지 않다면 범용 패키지 안내를 확인하세요.

macOS의 Apple 칩 기기는 Rosetta를 통해 Intel 앱을 실행할 수 있는 경우도 있지만, 처음 설치할 때는 추가 호환성 문제를 줄이도록 기본 아키텍처용 패키지를 우선 선택하세요. Windows ARM 기기도 파일 이름에 ‘64’가 들어 있는지만 보지 말고, 프로젝트에서 네이티브 설치 파일을 제공하는지 먼저 확인해야 합니다.

클라이언트 다운로드 페이지에서 해당 플랫폼을 선택한 뒤 프로젝트 배포 안내의 시스템 요구 사항을 확인하세요. 구형 Clash 클라이언트와 최신 mihomo 클라이언트는 새 프로토콜과 설정 필드 지원이 다를 수 있습니다. 파일을 가져올 수 있다는 사실만으로 호환된다고 판단해서는 안 됩니다. 설치 전에 클라이언트별 차이를 비교하려면 클라이언트 선택 가이드를 확인하세요.

3. macOS: 앱 권한, 시스템 프록시, 보조 서비스

먼저 ‘응용 프로그램’ 폴더로 옮긴 뒤 실행하세요

다운로드한 디스크 이미지를 열고 앱을 ‘응용 프로그램’ 폴더로 드래그하세요. 그다음 해당 폴더에서 앱을 실행하면 설치 이미지에서 계속 실행하는 일을 피할 수 있습니다.
개발자를 확인할 수 없다는 안내가 표시되면 먼저 파일 출처와 배포 안내를 확인한 뒤 ‘시스템 설정 → 개인정보 보호 및 보안’에서 ‘그래도 열기’ 옵션이 있는지 살펴보세요. 이 옵션은 시스템 버전과 차단 사유에 따라 나타나지 않을 수 있습니다.
설정을 가져오고 코어가 실행 중인지 확인한 뒤 클라이언트의 ‘시스템 프록시’ 기능을 켜세요.
‘시스템 설정 → 네트워크 → 현재 네트워크 연결 → 세부사항 → 프록시’에서 HTTP, HTTPS 또는 SOCKS 항목을 확인하세요. 주소는 보통 127.0.0.1이며 포트는 클라이언트 설정과 일치해야 합니다.

‘앱이 손상되었습니다’라는 안내가 표시되면 먼저 시스템에 맞는 설치 파일을 다시 받고 프로젝트 안내를 확인하세요. 출처를 알 수 없는 터미널 명령을 그대로 복사하거나, 앱 하나를 실행하려고 시스템 보안 기능 전체를 끄지 마세요. 회사에서 관리하는 Mac은 기기 정책으로 앱 실행이나 네트워크 확장이 제한될 수 있으므로 관리자에게 문의해야 합니다.

TUN 권한은 일반 시스템 프록시 권한과 별개입니다

시스템 프록시 설정에는 일반적으로 TUN 생성과 같은 수준의 권한이 필요하지 않습니다. TUN을 켜면 클라이언트 구현에 따라 보조 서비스를 설치하거나 관리자 암호를 입력하고 네트워크 구성 요소를 승인해야 할 수 있습니다. 승인 창에 표시된 앱이 맞는지 확인한 뒤 프로젝트 문서를 따라 진행하세요. 서비스 설치가 끝나도 코어 로그를 확인해야 합니다. 암호 입력 창이 닫혔다는 이유만으로 TUN이 트래픽을 처리한다고 단정할 수 없습니다.

4. Windows와 Android: 프록시 설정 및 VPN 권한

Windows: 루프백 주소를 확인하고 방화벽 전체를 완화하지 마세요

설치 후 설정을 가져오고 클라이언트의 시스템 프록시를 켜세요. 그런 다음 Windows 11의 ‘설정 → 네트워크 및 인터넷 → 프록시’에서 수동 프록시가 현재 수신 포트를 가리키는지 확인합니다. Windows 10에서는 보통 ‘설정 → 네트워크 및 인터넷 → 프록시’에서 확인할 수 있습니다. 일부 클라이언트는 자동 구성 스크립트를 사용하므로 실제 트래픽 처리 방식에 맞춰 점검하고, 억지로 수동 프록시로 바꾸지 마세요.

루프백 프록시 주소는 127.0.0.1입니다. 0.0.0.0은 모든 IPv4 인터페이스에 바인딩한다는 뜻이므로 브라우저의 연결 대상 주소로 입력하면 안 됩니다.
방화벽 알림이 표시되면 용도에 맞는 네트워크 범위를 선택하세요. 이 컴퓨터에서만 사용할 경우 로컬 네트워크에 프록시를 개방할 필요가 없습니다.
TUN이나 서비스 모드가 필요하면 클라이언트 안내에 따라 서비스를 설치하거나 권한을 높이세요. 일반 시스템 프록시를 사용한다고 해서 항상 관리자 권한으로 실행해야 하는 것은 아닙니다.

Android: VPN 연결을 승인하고 백그라운드 동작도 확인하세요

프록시를 처음 실행하면 Android에서 시스템 VPN 연결 요청이 표시되는 경우가 많습니다. 출처를 확인한 뒤 허용하면 상태 표시줄에 보통 VPN 아이콘이 나타납니다. 이 아이콘은 VPN 인터페이스가 연결되었다는 뜻일 뿐, 구독 노드의 사용 가능 여부나 규칙의 정확성, 대상 서비스 연결까지 보장하지는 않습니다.

다른 VPN이나 로컬 VPN을 사용하는 방화벽·필터링 도구가 실행 중이면 먼저 종료한 뒤 테스트하세요. 일반적으로 동일한 사용자 환경에서는 활성 VPN 서비스를 하나만 사용할 수 있습니다. 화면을 잠근 뒤 연결이 끊긴다면 ‘설정 → 앱 → 해당 클라이언트 → 배터리’에서 백그라운드 제한을 확인하세요. 메뉴 위치는 휴대전화 시스템에 따라 다를 수 있습니다. 필요에 따라 백그라운드 실행을 허용하고, 앱별 분할 설정 때문에 대상 브라우저가 프록시 범위에서 제외되지 않았는지도 확인하세요.

5. 설정 가져오기와 포트: 코어가 실제로 실행 중인지 확인

클라이언트의 ‘설정’ 또는 ‘구독’ 화면에서 원격 설정 추가를 선택하고 서비스 제공업체가 발급한 Clash/mihomo 구독 URL을 붙여 넣은 뒤 다운로드하세요. 다운로드한 설정을 선택해 활성화합니다. 목록에 설정 이름이 표시되는 것만으로는 충분하지 않습니다. 현재 사용 중인지 확인하고, 로그에서 설정 파싱 실패, 프로토콜 미지원, 포트 바인딩 실패가 있는지 살펴보세요.

구독 URL에는 접속 정보가 포함되는 경우가 많으므로 공개 스크린샷이나 문의 내용, 명령 기록에 남기지 마세요. 로컬 YAML을 가져올 때는 클라이언트의 파일 가져오기 기능을 우선 사용하고 앱 설치 폴더를 직접 수정하지 마세요. 구독을 업데이트하면 원격 설정이 덮어써질 수 있으므로 로컬 변경 사항은 클라이언트가 지원하는 재정의 또는 병합 설정에 넣어야 합니다.

기본 공통 설정 예시 알아보기

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

아래는 필드 설명을 위한 일부 설정일 뿐, 노드·정책 그룹·규칙이 없으므로 완전한 구독 설정으로 사용할 수 없습니다. mixed-port는 하나의 포트에서 HTTP와 SOCKS 프록시 요청을 모두 받습니다. allow-lan: false는 로컬 네트워크의 접근을 제한하고, mode: rule은 규칙에 따라 나가는 경로를 선택한다는 뜻입니다. 클라이언트가 이 필드를 덮어쓸 수도 있으므로 최종적으로는 실행 중인 설정과 수신 상태를 확인하세요.

포트가 사용 중이면 먼저 프로세스를 확인하세요

로그에 address already in use 또는 바인딩 실패가 표시되면 먼저 다른 프록시 도구를 종료하세요. macOS에서는 터미널에서 아래의 읽기 전용 명령을 실행할 수 있습니다:

lsof -nP -iTCP:7890 -sTCP:LISTEN

Windows에서는 명령 프롬프트에서 수신 대기 정보를 확인한 다음, 출력에 표시된 PID로 작업 관리자에서 프로세스를 찾으세요. 아래 필터에는 관련된 다른 연결도 표시될 수 있으므로 로컬 주소와 수신 대기 상태를 추가로 확인해야 합니다:

netstat -ano | findstr ":7890"

포트를 사용 중인 프로세스를 확인한 뒤 해당 앱을 정상적으로 종료하거나, 새 클라이언트의 혼합 포트를 7891처럼 비어 있는 값으로 바꾸세요. 변경 후에는 시스템 프록시를 다시 활성화해 운영체제가 새 포트를 사용하도록 하세요. PID가 보인다는 이유만으로 정체를 모르는 시스템 프로세스를 강제 종료하지 마세요.

6. 시스템 프록시와 TUN: 먼저 한 가지 방식으로 연결을 확인하세요

시스템 프록시는 이를 따르는 앱에 프록시 주소를 알려 주므로 브라우저에서 쉽게 테스트할 수 있습니다. 일부 명령줄 도구와 게임, 자체 네트워크 스택을 사용하는 소프트웨어는 시스템 프록시를 따르지 않을 수 있습니다. TUN은 가상 네트워크 인터페이스로 더 많은 IP 트래픽을 처리하며 라우팅, DNS, 권한에도 영향을 주므로 문제를 진단할 범위가 넓어집니다.

데스크톱 첫 테스트: TUN은 끈 상태로 시스템 프록시를 켜고 브라우저에서 특정 연결 하나를 확인하세요.
두 번째 테스트: 시스템 프록시를 따르지 않는 앱이 실제로 있을 때 TUN을 켜고 라우팅 설정과 DNS 로그를 살펴보세요.
Android: VPN이 실행 중인지, 대상 앱이 프록시 범위에 포함되는지, 선택한 정책 그룹이 올바른지 먼저 확인하세요.

시스템 프록시와 TUN을 반드시 함께 사용할 수 없는 것은 아닙니다. 많은 클라이언트가 두 기능의 동시 사용을 처리합니다. 다만 처음 설정할 때는 문제 범위를 줄이기 위해 주요 트래픽 처리 방식을 하나만 켜는 편이 좋습니다. TUN을 켰다고 모든 트래픽이 프록시를 거치는 것도 아닙니다. 규칙 모드에서는 규칙에 따라 직접 연결, 프록시 또는 차단이 선택됩니다.

7. 연결 확인: 트래픽 처리·규칙·노드 문제 구분하기

클라이언트의 ‘연결’ 화면을 열고 확인할 사이트에 다시 접속해 도메인, 적용된 규칙, 최종 연결 경로를 살펴보세요. 페이지가 열리는지만 보면 브라우저 캐시나 원래 직접 연결할 수 있던 요청을 프록시 연결 성공으로 오해할 수 있습니다. 노드 지연 시간 테스트에 성공해도 해당 테스트 요청만 확인된 것이므로 실제 사용할 서비스에 접속해 검증해야 합니다.

증상	먼저 확인할 항목	다음 단계
연결 목록에 대상 요청이 표시되지 않음	시스템 프록시, 앱별 프록시 설정, Android 앱 분할	요청이 현재 클라이언트에 실제로 들어오는지 확인하세요.
연결은 표시되지만 DIRECT로 나감	현재 모드와 적용된 규칙	해당 도메인이 직접 연결 대상인지 확인한 뒤 규칙이나 정책을 조정하세요.
프록시 규칙이 적용된 뒤 연결 시간 초과	정책 그룹의 현재 선택, 노드 상태, 네트워크 연결	사용 가능한 노드로 바꾸고 오류 로그를 확인하세요.
도메인 이름 확인 오류	현재 적용된 DNS 설정과 상위 DNS 서버 연결	로그를 보관하고 DNS 설정을 여러 가지 한꺼번에 바꾸지 마세요.
클라이언트를 종료한 뒤 인터넷에 연결되지 않음	남아 있는 시스템 프록시, 다른 VPN, 라우팅 상태	작동하지 않는 프록시 설정을 끄고 네트워크가 복구되는지 확인하세요.

브라우저 설정 문제와 코어 문제를 구분하려면 로컬 HTTP 프록시를 명시해 테스트할 수 있습니다. 아래 명령의 주소와 포트는 실제 설정과 일치해야 합니다. 테스트 도메인은 예시이며 결과는 해당 요청 한 건의 상태만 보여 줍니다:

curl -I --proxy http://127.0.0.1:7890 https://example.com

Windows에서는 curl.exe를 사용하면 일부 PowerShell 환경에서 같은 이름의 별칭이 일으키는 혼동을 피할 수 있습니다. 프록시를 명시한 요청은 성공하지만 브라우저에서 실패한다면 브라우저 확장 프로그램, 별도 프록시 설정, 시스템 프록시 참조를 먼저 확인하세요. 연결 거부 오류가 표시되면 원격 노드를 바꾸기 전에 로컬 포트가 수신 중인지 확인하세요.

8. 첫 실행 후 점검 목록

정상 동작 상태를 기록하세요. 클라이언트와 코어 버전, 사용 중인 설정, 혼합 포트, 트래픽 처리 방식을 적어 두면 이후 업그레이드 문제를 비교하기 쉽습니다.
설정 업데이트를 확인하세요. 구독을 한 번 수동으로 업데이트해 정상적으로 파싱되는지 확인한 뒤 서비스 제공업체의 안내에 따라 자동 업데이트 주기를 설정하세요.
필요할 때 자동 실행을 켜세요. 데스크톱에서는 ‘앱을 부팅할 때 실행’과 ‘실행 후 자동으로 트래픽 처리’를 구분하세요. Android에서는 시스템의 백그라운드 실행 정책도 고려해야 합니다.
로컬 네트워크 접근은 꺼 두세요. 다른 기기에서 이 컴퓨터의 프록시를 사용할 때만 켜고, 인증과 수신 주소, 방화벽 범위를 함께 확인하세요.
정상 종료를 확인하세요. 앱을 종료하기 전에 시스템 프록시나 VPN을 끄고, 브라우저가 정상적으로 직접 연결되는지 확인하세요.
재현에 필요한 정보를 보관하세요. 도움을 요청할 때 플랫폼, 버전, 오류 발생 시각, 개인정보를 가린 로그를 제공하세요. 구독 정보와 노드 암호, 개인 접속 기록은 가려야 합니다.

최초 설치를 마쳤다고 판단하려면 설정이 활성화되어 있고, 코어가 포트를 수신하며, 대상 앱의 요청이 연결 목록에 나타나고, 규칙과 연결 경로가 예상과 일치해야 합니다. 종료 후 네트워크가 복구되는지도 확인하세요. 이 조건을 충족한 다음 사용자 지정 규칙, TUN, 복잡한 DNS 정책을 추가하면 문제 원인을 더 쉽게 찾을 수 있습니다. 설정 위치는 설치 및 설정 튜토리얼에서도 확인할 수 있으며, 권한이나 네트워크 문제가 발생하면 도움말 센터를 참고하세요.