Clash 첫 설치 및 초기 설정: 전 플랫폼 공통 순서와 흔한 문제

다섯 플랫폼에서 공통으로 적용되는 첫 설치 순서를 정리합니다. 설치 파일 선택, 실행 권한, 구독 가져오기, 모드 확인까지 다루고, 권한·포트·시스템 프록시처럼 초기 설정에서 가장 자주 발목을 잡는 세 가지 함정도 함께 짚습니다.

설치 전에 클라이언트와 코어부터 구분하기

Clash의 그래픽 클라이언트와 코어는 서로 다른 계층입니다. 클라이언트는 인터페이스, 구독 관리, 시스템 프록시 스위치를 담당하고, 코어는 설정을 파싱하고 규칙을 매칭해 트래픽을 전달합니다. 원본 Clash 코어는 유지보수가 종료되었고, 현재 주요 클라이언트는 mihomo 코어(Clash Meta)를 기본 내장합니다. 프로토콜 지원, 규칙 유형, TUN 구현 모두 mihomo를 기준으로 봅니다.

설치 파일을 고를 때 먼저 확인할 것은 두 가지입니다. 클라이언트에 코어가 내장되어 있는지(내장이라면 코어 파일을 따로 받을 필요가 없습니다), 그리고 코어 버전이 사용하려는 인바운드 방식을 지원하는지입니다. 같은 PC에서 프록시 클라이언트 두 개를 동시에 실행하면 7890 포트와 시스템 프록시 설정을 서로 차지하려 하므로, '스위치는 켜져 있는데 트래픽이 프록시를 타지 않는' 증상이 나타납니다.

플랫폼일반적인 설치 파일 형태첫 실행 시 처리할 권한
Windows.exe 설치 파일 / 포터블 zip방화벽 경고, TUN은 관리자 권한 필요 — 보통 서비스 모드를 한 번 설치하면 해결됩니다
macOS.dmg(칩 아키텍처에 따라 Apple Silicon / Intel)Gatekeeper 허용, TUN은 권한 도우미를 한 번 설치하고 시스템 설정에서 허용해야 합니다
Android.apk(대부분의 기기는 arm64)'알 수 없는 앱 설치' 허용, 시스템 VPN 권한 대화상자, 배터리 최적화 해제
iOSApp StoreVPN 구성 추가 시 시스템 확인
Linux.deb / .rpm / AppImage패키지 설치에 root 필요, TUN은 CAP_NET_ADMIN 또는 root 실행 필요

공통 설치 순서: 설치 → 권한 허용 → 구독 가져오기 → 모드 확인

플랫폼마다 화면은 다르지만 순서는 같습니다. 아래 다섯 단계를 따라가되, 중간에 기대한 결과가 나오지 않으면 다음 단계로 넘어가지 말고 먼저 해결하세요.

설치 파일 선택

Windows는 .exe, macOS는 칩 아키텍처를 확인한 뒤 맞는 dmg, Android는 arm64 apk, Linux는 배포판에 맞춰 deb 또는 rpm을 받습니다. 다운로드 페이지의 각 플랫폼 카드에는 지원하는 OS 버전과 아키텍처가 표시되어 있습니다.

설치 후 첫 실행 권한 요청 처리

Windows의 방화벽 경고와 권한 상승, macOS의 '그래도 열기'와 권한 도우미, Android의 VPN 권한, iOS의 VPN 구성 확인이 모두 이 단계에서 끝납니다. 한 번 거부한 권한은 자동으로 다시 뜨지 않으므로 시스템 설정에서 직접 허용해야 합니다.

구독 가져오기

'구독' 또는 '프로필' 페이지를 열고 새로 만들기를 눌러 구독 링크를 붙여넣은 뒤 업데이트를 누르고 설정 다운로드가 끝날 때까지 기다립니다.

노드 선택 및 모드 확인

'프록시' 페이지에서 정책 그룹을 펼쳐 노드를 하나 선택하고, '설정' 페이지에서 모드를 '규칙'으로 확인합니다. 첫 설정에서는 '전역'을 쓰지 마세요.

시스템 프록시 또는 TUN 켜기

둘 중 하나만 먼저 켭니다. 데스크톱에서는 시스템 프록시로 먼저 검증하고, 인터넷이 되는 것을 확인한 뒤 TUN으로 전환하세요. 동시에 켜면 문제가 어느 계층에서 생겼는지 구분하기 어려워집니다.

Windows: 서비스 모드가 TUN 무권한 실행을 결정

시스템 프록시 변경은 현재 사용자 레지스트리만 수정하면 되므로 일반 권한으로 충분하지만, TUN 모드는 가상 네트워크 어댑터를 만들어야 하므로 관리자 권한이 필수입니다. 대부분의 클라이언트는 '서비스 모드' 스위치를 제공합니다. 시스템 서비스를 한 번 설치해 두면 이후에는 매번 권한을 올릴 필요가 없습니다. 이 단계를 건너뛰면 TUN 스위치가 켜지는 순간 되돌아가고, 코어 로그에 권한 관련 오류 줄이 남습니다.

macOS: Gatekeeper 통과 후 권한 도우미 허용

dmg에서 '응용 프로그램'으로 끌어다 놓고 처음 열 때 '개발자를 확인할 수 없어 열 수 없습니다'라는 메시지가 뜨면 '시스템 설정' → '개인정보 보호 및 보안'으로 가서 페이지 아래쪽의 차단된 항목에서 '그래도 열기'를 누릅니다. TUN을 켜면 클라이언트가 권한 도우미를 한 번 설치하라고 요청하며(일부 버전은 시스템 네트워크 확장 사용), 비밀번호를 입력해 확인한 뒤 '시스템 설정' → '일반' → '로그인 항목 및 확장 프로그램'에서 해당 항목을 켜야 합니다. 그렇지 않으면 스위치는 켜진 것처럼 보여도 트래픽은 계속 직접 연결로 나갑니다.

Android와 iOS: VPN 권한은 한 번만, 백그라운드 유지는 별도 설정

Android에서 apk를 사이드로드하기 전에 '설정' → '앱' → '특수 앱 접근 권한' → '알 수 없는 앱 설치'에서 설치 출처를 허용합니다. 처음 연결을 누르면 시스템 VPN 권한 대화상자가 뜨는데, 신뢰함을 체크하고 확인을 누릅니다. 그다음 배터리 설정에서 클라이언트를 '제한 없음'으로 지정하지 않으면 화면이 꺼진 뒤 프로세스가 회수되어 몇 분마다 연결이 끊기는 증상이 나타납니다.

iOS는 App Store에서 설치한 뒤 처음 연결할 때 'VPN 구성 추가' 시스템 확인 창이 뜨고, 잠금 화면 암호나 생체 인증으로 통과합니다. 이 단계를 거부하면 설정에 VPN 항목이 생성되지 않고 스위치가 즉시 되돌아가므로, '설정' → '일반' → 'VPN 및 기기 관리'에서 잔여 항목이 있는지 확인해야 합니다.

Linux: 패키지 설치는 root, TUN은 capability

deb는 sudo dpkg -i, rpm은 sudo rpm -ivh를 사용하고, AppImage는 먼저 chmod +x한 뒤 실행합니다. TUN 모드는 가상 네트워크 어댑터를 만들어야 하는데, 매번 root로 실행하는 것보다 바이너리에 네트워크 관리 권한을 부여하는 편이 간편합니다:

sudo setcap cap_net_admin+ep /usr/local/bin/mihomo

바이너리를 재설치하거나 업그레이드하면 capability가 사라지므로 다시 한 번 실행해야 합니다. systemd로 상시 실행한다면 unit에서 root 실행을 직접 지정하는 방법도 있습니다.

구독 가져오기와 모드 확인

가져오기 자체는 세 단계면 끝납니다. 구독 링크 복사 → 클라이언트의 '구독'/'프로필' 페이지 열기 → 새로 만들고 링크 붙여넣기 → 업데이트 누르기. 설정 다운로드가 성공하면 '프록시' 페이지의 정책 그룹에 노드가 나타납니다.

이 단계에서 막히는 경우는 보통 다음 세 가지입니다:

  • 링크가 잘린 경우. 구독 링크는 매우 길어서 메신저에서 복사할 때 글자가 빠지기 쉽습니다. 붙여넣은 뒤 끝부분을 확인하거나, 클라이언트의 '클립보드에서 가져오기'를 사용하세요.
  • 업데이트 시 TLS 또는 인증서 오류가 나는 경우. 먼저 시스템 시간이 정확한지 확인하세요. 시간 오차가 크면 인증서 검증에 실패합니다.
  • 업데이트는 성공했는데 노드가 없는 경우. 코어 로그에서 구체적인 오류를 확인하세요. 구독이 Clash 형식의 YAML이 아니라 base64로 인코딩된 노드 목록을 반환하는 것이 흔한 원인입니다.

모드 확인도 중요합니다. 클라이언트는 보통 '규칙', '전역', '직접 연결' 세 가지를 제공하는데, 첫 설정에서는 '규칙'을 유지해 코어가 rules 섹션을 위에서 아래로 매칭하도록 합니다. 노드 자체가 정상인지 확인해야 할 때만 잠시 '전역'으로 바꿔 테스트하고, 끝나면 '규칙'으로 되돌리세요.

아래는 클라이언트 그래픽 인터페이스에서 실제로 바뀌는 필드로, 적용된 값을 대조해 확인할 때 쓰면 됩니다:

mixed-port: 7890
mode: rule
log-level: info
external-controller: 127.0.0.1:9090
dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true

mixed-port는 HTTP와 SOCKS5 요청을 동시에 받으므로, 브라우저 프록시 확장에는 127.0.0.1:7890만 입력하면 됩니다. external-controller는 대시보드와 외부 제어의 수신 주소이므로 127.0.0.1 그대로 두고 바꾸지 마세요.

초기 설정에서 가장 자주 발목 잡히는 세 가지 함정

권한 문제: TUN 스위치가 켜졌다가 되돌아감

원인은 사실상 세 가지입니다. Windows에서 서비스 모드를 설치하지 않았거나, macOS에서 권한 도우미나 네트워크 확장을 시스템 설정에서 허용하지 않았거나, Linux에 CAP_NET_ADMIN이 없는 경우입니다. 확인 방법은 간단합니다. 코어 로그에 operation not permitted 또는 TUN 인터페이스 설정 실패 오류 줄이 있는지 보면 됩니다.

포트 문제: 7890이 점유되었거나 LAN에 노출됨

7890은 가장 쉽게 뺏기는 포트로, 브라우저 프록시 확장, 구버전 클라이언트, 패킷 캡처 도구가 모두 차지할 수 있습니다. 먼저 점유 프로세스를 확인하세요:

# Windows
netstat -ano | findstr :7890

# macOS / Linux
lsof -i :7890

PID를 확인해 프로세스를 종료하거나, mixed-port를 빈 포트(예: 7891)로 바꾸고 브라우저와 시스템 프록시에 입력된 포트도 함께 바꿔야 합니다. 그렇지 않으면 '포트는 바꿨는데 브라우저는 여전히 예전 포트로 접속하는' 상황이 생깁니다.

반대 방향의 문제는 노출입니다. external-controller0.0.0.0:9090으로 두고 secret을 설정하지 않으면 같은 LAN의 누구나 설정을 읽고 노드를 바꿀 수 있습니다.

외부 제어 주소는 127.0.0.1로 유지

원격에서 대시보드를 봐야 한다면 SSH 포트 포워딩으로 로컬에 연결하세요. 9090을 0.0.0.0에 직접 바인딩하지 말고, secret 없이 공용 인터넷에 노출하는 일은 더더욱 피해야 합니다.

시스템 프록시 문제: 클라이언트 종료 후 모든 웹페이지가 열리지 않음

시스템 프록시는 운영체제 설정에 기록되므로 클라이언트가 강제 종료되거나 충돌하면 되돌릴 시간이 없어, 브라우저는 아무도 수신하지 않는 7890 포트로 계속 요청을 보내고 모든 사이트가 연결되지 않습니다. 수동으로 되돌리는 위치는 다음과 같습니다:

  • Windows: '설정' → '네트워크 및 인터넷' → '프록시' → '프록시 서버 사용' 끄기.
  • macOS: '시스템 설정' → '네트워크' → 현재 네트워크 '세부사항' → '프록시' → HTTP, HTTPS, SOCKS 세 항목의 체크 해제.

또 하나의 숨은 충돌 원인이 있습니다. 브라우저에 프록시 관리 확장을 설치하고 자체 PAC 규칙을 켜 두면 시스템 프록시를 덮어써서 '클라이언트는 연결됨으로 표시되는데 브라우저는 프록시를 타지 않는' 상황이 생깁니다. 점검할 때는 이런 확장을 먼저 비활성화하고 다시 테스트하세요.

첫 연결 자가 점검: 순서대로 확인하기

  1. 코어 로그를 봅니다. DNS 리스닝, 규칙 로드 완료 기록이 보이면 정상 시작입니다. error 줄이 있으면 먼저 해결하세요.
  2. 노드 지연을 확인합니다. '프록시' 페이지에서 지연 테스트를 눌러 숫자가 나오면 구독과 네트워크 모두 정상입니다. 전부 시간 초과라면 구독 업데이트가 성공했는지 먼저 확인하세요.
  3. 모드가 '규칙'인지 확인하고, '연결' 페이지에서 실제 연결 하나가 어떤 규칙에 매칭되었는지 봅니다. 모든 트래픽이 MATCH 폴백으로 떨어지는 상황을 피해야 합니다.
  4. 브라우저를 거치지 않고 포트를 직접 테스트:
    curl -x http://127.0.0.1:7890 -I https://example.com
    200 상태 코드가 돌아오면 코어에서 노드까지의 경로는 정상이고, 문제는 시스템 프록시나 브라우저 쪽에 있습니다.
  5. DNS를 확인합니다. fake-ip를 켜면 기본 대역이 198.18.0.1/16인데, LAN이나 회사 VPN이 같은 대역을 쓰면 일부 도메인 해석이 이상해지므로 충돌하지 않는 대역으로 바꿔야 합니다.
  6. 마지막으로 비교 테스트를 합니다. 시스템 프록시를 끄고 TUN만 켠 상태로 같은 사이트에 접속해 보세요. 두 방식 모두 정상이라면 첫 설치와 초기 설정이 끝난 것입니다.
다음 단계: 클라이언트 설치 후 튜토리얼과 함께 점검하기

다운로드 페이지에서는 플랫폼별로 사용 가능한 클라이언트와 설치 파일 형식을 확인할 수 있고, 튜토리얼 페이지에서는 구독 가져오기, 모드 전환, TUN 스위치의 전체 순서와 이 글에서 다룬 권한 설정이 각 클라이언트 화면 어디에 있는지 확인할 수 있습니다.

Clash 다운로드