1. 설치 전 확인: 클라이언트, 코어, 시스템 아키텍처

Clash 초기 설정은 네 단계로 나눠 확인할 수 있습니다. 클라이언트가 실행되는지, 설정을 불러오는지, 로컬 프록시 포트가 연결을 수신하는지, 앱 트래픽이 프록시로 전달되는지 차례대로 확인하세요. 설치 파일이 열렸다는 사실은 첫 단계만 통과했다는 뜻입니다. TUN이나 시작 프로그램 같은 추가 기능은 기본 동작을 확인한 뒤 켜면 문제 범위를 좁히기 쉽습니다.

GUI 클라이언트는 구독 관리, 프록시 그룹 선택, 시스템 설정을 담당하고, 코어는 설정을 해석하고 규칙을 적용해 외부 연결을 만듭니다. Clash, Clash.Meta, mihomo는 임의로 서로 바꿔 쓸 수 있는 버전 표기가 아닙니다. mihomo 전용 필드나 최신 프로토콜을 사용하는 구독은 이를 지원하는 코어가 필요하므로, 클라이언트 이름만 보고 호환 여부를 판단하지 마세요.

  • Windows: 「설정」→「시스템」→「정보」에서 ‘시스템 종류’를 확인하세요. x64와 ARM64 설치 파일은 기기 아키텍처에 맞춰 선택해야 합니다. ‘Windows 11’이라는 정보만으로 판단하지 마세요.
  • macOS: Apple 메뉴에서 「이 Mac에 관하여」를 엽니다. Apple 칩이 표시되면 ARM64, Intel 프로세서가 표시되면 x64를 선택하세요.
  • Android: 최신 기기는 대체로 ARM64를 사용하지만, 구형 기기나 일부 시스템은 다를 수 있습니다. 먼저 클라이언트 배포 안내에서 최소 Android 버전과 아키텍처를 확인하고, 확인하기 어려울 때는 제공되는 범용 패키지를 고려하세요.

2. 구독 가져오기: 다운로드 성공이 설정 적용을 뜻하지는 않습니다

구독 주소에는 보통 액세스 토큰이 포함되므로 비밀번호처럼 다뤄야 합니다. 신뢰할 수 있는 제공자에게서만 받고, 주소 전체를 공개 스크린샷이나 온라인 변환 사이트, 문의 게시물에 올리지 마세요. 구독 응답은 완성된 Clash YAML일 수도 있고 노드 목록만 포함할 수도 있어, 가져오는 메뉴가 서로 다를 수 있습니다.

처음 가져올 때 확인할 순서

  1. 클라이언트의 설정 또는 구독 화면에서 원격 설정을 추가하고 전체 주소를 붙여 넣으세요. 메뉴 이름은 클라이언트마다 다릅니다. 프록시 서버 주소 입력란에 URL을 넣지 마세요.
  2. 한 번 업데이트한 뒤 설정 구문 분석 오류가 있는지 확인하세요. 로그인 페이지로 돌아가거나 만료 안내가 표시되거나 일반 HTML이 내려온다면, 다운로드 요청에 성공했더라도 YAML 설정으로 사용할 수 없습니다.
  3. 가져온 설정을 목록에서 직접 선택해 현재 설정으로 지정하세요. 구독 카드가 목록에 나타나도 코어가 해당 설정으로 전환된 것은 아닙니다.
  4. 프록시 그룹 화면에서 사용 가능한 노드가 있는지 확인하고, 노드 또는 원하는 정책을 직접 선택하세요. 가져오기에 성공했더라도 DIRECT가 선택되어 있으면 트래픽이 직접 연결될 수 있습니다.
  5. 아웃바운드 모드를 규칙 모드로 설정한 다음, 규칙 목록이 비어 있지 않은지와 마지막에 예상한 기본 정책이 있는지 확인하세요.

‘지원하지 않는 프록시 유형’ 또는 ‘알 수 없는 필드’ 오류가 발생하면 먼저 설정에서 요구하는 코어를 확인하세요. HTTP 401 또는 403은 토큰과 접근 권한을, 404는 주소가 완전한지 또는 리소스가 이전되었는지 확인해야 합니다. 오류 원인을 분류하는 대신 클라이언트를 반복해서 재설치하지 마세요.

구독 업데이트와 로컬 수정은 따로 관리

원격 구독에서 생성된 파일을 직접 수정하면 다음 업데이트에서 변경 내용이 덮어써질 수 있습니다. 직결 도메인 추가, DNS 조정, 포트 변경이 필요하면 클라이언트의 오버라이드·병합·로컬 확장 기능을 우선 사용하고, 기능 적용 후 최종 설정도 확인하세요. 원본 구독과 로컬 변경 사항을 구분해 보관하면 되돌리기 쉽습니다.

3. 로컬 포트: 수신 주소와 포트 충돌 확인

시스템 프록시는 클라이언트가 실제로 연결을 수신하는 주소와 포트를 가리켜야 합니다. 흔히 127.0.0.1:7890을 사용하지만, 7890이 모든 클라이언트의 기본 포트인 것은 아닙니다. 현재 설정과 실행 로그를 기준으로 확인하세요. 컨트롤 포트는 코어 관리용이므로 브라우저의 HTTP 프록시 입력란에 넣으면 안 됩니다.

다음은 mihomo의 로컬 연결 설정 예시입니다. 필드 설명용이며 노드와 규칙을 포함한 완성된 설정은 아닙니다. mixed-port는 하나의 포트에서 HTTP와 SOCKS 프록시 요청을 모두 받습니다. 처음 설정할 때는 루프백 주소로 제한해 실수로 LAN에 프록시를 노출하지 않도록 하세요.

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

Windows: 포트를 수신 중인 프로세스 확인

netstat -ano | findstr :7890

로컬 주소가 해당 포트이고 상태가 LISTENING인 행을 확인하세요. 마지막 열에 PID가 표시됩니다. 작업 관리자의 「세부 정보」에서 프로세스 ID를 대조할 수 있습니다. 다른 프록시 클라이언트가 포트를 사용 중이라면 기존 클라이언트를 정상적으로 종료한 뒤 현재 클라이언트를 실행하세요. 정체를 모르는 시스템 프로세스를 강제 종료하지 마세요.

macOS: TCP 수신 상태 확인

lsof -nP -iTCP:7890 -sTCP:LISTEN

결과가 없으면 코어 실행에 실패했거나 실제 포트가 다를 수 있습니다. 사용 중이지 않은 다른 포트로 변경한 뒤에는 시스템 프록시나 앱 프록시 설정도 함께 업데이트해야 합니다. 설정만 바꾸고 연결 지점을 그대로 두면 브라우저에서 연결 거부가 발생합니다.

4. Windows와 macOS: 시스템 프록시부터 확인

시스템 프록시는 해당 설정을 따르는 앱의 요청을 로컬 클라이언트로 전달합니다. 기기의 모든 트래픽을 가로채는 기능은 아닙니다. 브라우저로 먼저 확인하는 것이 좋지만, 게임과 명령줄 도구, 일부 앱은 별도의 네트워크 설정을 사용할 수 있습니다.

확인 항목 Windows 11 macOS
시스템 설정 경로 설정 → 네트워크 및 인터넷 → 프록시 시스템 설정 → 네트워크 → 현재 연결 → 세부사항 → 프록시
처음 확인할 설정 수동 프록시 주소와 포트, 남아 있는 설정 스크립트가 있는지 웹 프록시, 보안 웹 프록시, SOCKS 프록시의 활성화 여부와 포트
로컬 주소 예시 127.0.0.1, 포트는 실제 수신 포트에 맞게 입력 127.0.0.1, 포트는 실제 수신 포트에 맞게 입력

먼저 클라이언트의 시스템 프록시 스위치로 설정을 적용한 뒤 시스템 설정 화면에서 확인하세요. HTTP 프록시 연결을 사용하는 경우 macOS의 웹 프록시와 보안 웹 프록시는 해당 HTTP 또는 혼합 포트를 사용해야 합니다. SOCKS 프록시는 SOCKS 또는 혼합 포트를 사용하세요. 프로토콜이 다른 연결 정보를 같은 포트 번호로 무조건 입력하지 마세요.

권한 요청은 기능에 맞게 처리

  • Windows 서비스 모드: 일부 클라이언트는 TUN처럼 권한이 필요한 작업을 백그라운드 서비스로 처리합니다. 해당 기능이 꼭 필요할 때만 서비스를 설치하고, 시스템 권한 요청에 표시된 프로그램 출처를 확인하세요.
  • macOS 보조 구성 요소: 시스템 프록시를 설정하거나 가상 네트워크 인터페이스를 만들 때 클라이언트가 권한을 요청할 수 있습니다. 권한 부여에 실패하면 구성 요소 상태를 확인하세요. 문제를 가리기 위해 앱 전체를 반복해서 관리자 권한으로 실행하지 마세요.
  • 시스템에서 실행 차단: 먼저 다운로드 출처와 시스템에 표시된 구체적인 차단 사유를 확인하세요. 설치 파일 하나를 실행하려고 시스템 보안 기능을 전역으로 끄지 마세요.

5. Android: VPN 권한과 백그라운드 실행

Android 클라이언트는 대체로 데스크톱의 시스템 프록시 스위치를 그대로 사용하는 대신 시스템 VPN 인터페이스로 트래픽을 처리합니다. 처음 연결을 누르면 시스템 VPN 권한 요청이 표시되며, 이를 허용해야 인터페이스를 만들 수 있습니다. 상태 표시줄에 VPN 아이콘이 나타나도 인터페이스가 생성됐다는 뜻일 뿐, 노드와 DNS, 규칙이 모두 정상이라는 보장은 없습니다.

  1. 다른 VPN이 연결되어 있지 않은지 확인하세요. 같은 사용자 계정이나 업무 프로필에서 실행되는 다른 VPN, 방화벽, 필터링 앱이 클라이언트와 VPN 인터페이스를 두고 충돌할 수 있습니다.
  2. 앱 적용 범위를 확인하세요. 앱별 프록시를 사용한다면 브라우저가 적용 대상에 포함되어 있는지, 현재 ‘선택한 앱만’과 ‘선택한 앱 제외’ 중 어느 모드인지 확인하세요.
  3. 백그라운드 제한을 확인하세요. 「설정」→「앱」→해당 클라이언트→배터리 관련 설정에서 필요한 백그라운드 활동을 허용하세요. 기기 제조사에 따라 메뉴 경로가 다를 수 있으며, 클라이언트에서 요구하는 경우 알림 권한도 설정해야 합니다.
  4. 화면을 잠근 뒤 연결이 유지되는지 확인하세요. 연결한 상태로 몇 분간 화면을 잠근 뒤 잠금 해제 후 페이지에 접속하고, 클라이언트 알림과 연결 상태, 로그가 계속 유지되는지 확인하세요. 앱을 화면에 띄운 동안에만 작동한다면 절전 정책부터 살펴보세요.

처음 설정할 때는 ‘항상 VPN 사용’과 ‘VPN 없이 연결 차단’을 동시에 켜지 마세요. 후자를 켜면 VPN 연결이 끊겼을 때 다른 네트워크 경로도 차단되어 구독 업데이트와 문제 해결이 어려워질 수 있습니다. 보통 「설정」→「네트워크 및 인터넷」→「VPN」→해당 연결 설정에서 찾을 수 있지만, 제조사에 따라 메뉴 이름이 다를 수 있습니다.

일반 연결은 정상인데 VPN 연결 후 도메인 확인에 실패한다면 Android 비공개 DNS와 클라이언트 DNS 설정을 확인하세요. 자동, 특정 제공업체 지정, 사용 안 함처럼 한 번에 하나의 설정만 바꿔 비교하고 결과를 기록하세요. 비공개 DNS를 끄는 것이 모든 기기에 필요한 것은 아닙니다.

6. 트래픽 확인: 포트부터 규칙까지 단계별 점검

노드 지연 시간 테스트가 성공해도 모든 앱이 프록시를 사용한다는 뜻은 아닙니다. 지연 시간 테스트와 실제 접속은 대상, 프로토콜, 방문 사이트가 서로 다를 수 있습니다. 로컬 연결 지점과 클라이언트 연결 기록, 대상 웹 페이지를 함께 확인하는 편이 정확합니다.

데스크톱에서 명시적 프록시 테스트

Windows에서는 아래 명령을 사용하면 PowerShell에 같은 이름의 별칭이 있을 때 이를 우회할 수 있습니다. macOS에서는 curl.exe를 curl로 바꾸세요. 포트는 현재 클라이언트가 실제로 수신하는 HTTP 또는 혼합 포트로 변경해야 합니다.

curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com

여기서 10초 연결 제한 시간과 20초 전체 제한 시간은 문제 해결을 위한 설정이지 속도 측정 결과가 아닙니다. HTTP 응답을 받았다면 이번 명시적 프록시 요청이 완료된 것입니다. 다만 규칙에 따라 직접 연결되었을 수도 있습니다. 선택한 노드를 거쳤는지 확인하려면 연결 세부 정보에서 규칙 적용 결과와 최종 아웃바운드를 확인하세요.

  • 연결이 거부됨: 로컬 포트와 수신 프로세스, 코어 실행 로그부터 확인하세요.
  • 연결 기록이 없음: 앱이 시스템 프록시를 사용하는지, 별도 프록시가 설정되어 있는지, 앱별 규칙에서 제외되었는지 확인하세요.
  • DIRECT 규칙 적용: 현재 모드와 도메인 규칙, 규칙 순서를 확인하세요. 노드가 작동하지 않는다고 바로 판단하지 마세요.
  • 프록시 핸드셰이크 또는 인증 실패: 구독 상태와 노드 인증 정보, 프로토콜 지원 여부, 기기 시간을 확인하세요.
  • 도메인 확인 실패: DNS 로그와 업스트림 연결 상태, 현재 네트워크를 확인하세요. TCP 포트 연결 실패와는 별도로 다뤄야 합니다.

기본 연결을 확인한 뒤 TUN 설정

브라우저가 시스템 프록시를 통해 정상적으로 작동하지만 특정 앱이 프록시 설정을 따르지 않을 때 TUN을 고려하세요. TUN은 가상 네트워크 어댑터와 라우팅을 통해 조건에 맞는 트래픽을 처리하며, DNS 처리와 권한 설정도 필요할 수 있습니다. 라우팅과 제외 항목, 플랫폼 제한에 따라 적용 범위가 달라지므로 ‘켜면 모든 트래픽이 반드시 노드를 통과한다’고 단순하게 생각해서는 안 됩니다.

TUN을 켠 뒤 LAN 기기에 접근할 수 없거나 다른 VPN 연결이 끊기거나 네트워크 루프가 발생하면, 먼저 TUN을 끄고 기존 상태를 복구한 뒤 라우팅과 제외 설정을 확인하세요. 같은 단계에서 노드 변경, DNS 수정, 코어 전환, TUN 네트워크 스택 조정을 한꺼번에 하지 마세요. 어떤 변경이 문제를 해결했는지 알 수 없습니다.

7. 시작 프로그램 설정과 재부팅 후 확인

기본 연결이 안정된 뒤 시작 프로그램을 설정하세요. 클라이언트 창이 자동으로 열리는 것, 코어가 백그라운드에서 실행되는 것, 시스템 프록시가 복구되는 것, VPN이 자동으로 연결되는 것은 서로 다른 상태입니다. 시작 프로그램 옵션 하나를 켜도 네 가지가 모두 설정되는 것은 아닙니다. Android에서도 앱 자동 시작과 VPN 자동 연결을 서로 다른 기능이 제어할 수 있습니다.

Windows에서는 「설정」→「앱」→「시작 프로그램」에서 시작 항목을 확인할 수 있습니다. macOS에서는 「시스템 설정」→「일반」→「로그인 항목」에서 허용된 로그인 항목과 백그라운드 항목을 확인하세요. 클라이언트에 시작 프로그램 관리 기능이 있다면 항목을 수동으로 중복 추가하지 마세요. 두 인스턴스가 같은 포트를 사용하려고 할 수 있습니다.

  1. 현재 설정 저장: 사용 중인 설정 이름과 노드 정책, 프록시 포트, TUN 활성화 여부를 기록하세요.
  2. 기기 재부팅: 클라이언트와 코어가 실제로 실행되는지 확인하고 포트 충돌, 권한, 설정 구문 분석 오류가 있는지 살펴보세요.
  3. 트래픽 처리 상태 확인: 데스크톱에서는 시스템 프록시를, Android에서는 VPN 연결과 앱별 적용 범위를 확인하세요.
  4. 접속하며 동작 확인: 직접 연결해야 하는 대상과 프록시를 사용해야 하는 대상에 각각 접속하고, 규칙 적용 결과와 최종 아웃바운드를 확인하세요. 웹 페이지 하나만 점검하지 마세요.
  5. 종료 후 복구 확인: 프록시 기능을 정상적으로 끈 뒤 기본 네트워크가 작동하는지 확인하세요. 예기치 않게 종료됐을 때 복구할 수 있도록 시스템 프록시와 VPN 설정 경로를 알아 두세요.