마이그레이션 예상 읽기 시간 18분

클라이언트 지원 종료 이후: 설정 내보내기, 코어 교체와 대체 클라이언트

Clash와 VPN은 모두 인터넷 연결을 바꾸는 데 쓰이지만 작동 방식과 설정 범위는 다릅니다. 이 글에서는 관련 용어를 쉽게 풀고, 어떤 상황에 무엇이 맞는지와 안전하게 시작하는 방법을 처음부터 설명합니다.

Clash와 VPN은 무엇이 다른가

Clash와 VPN은 모두 인터넷 연결 경로를 바꾸는 데 사용되지만, 같은 종류의 프로그램은 아닙니다. VPN은 일반적으로 기기와 VPN 서버 사이에 암호화된 터널을 만들고, 그 터널을 통해 대부분의 네트워크 트래픽을 전달하는 방식입니다. 사용자는 서버 위치를 선택하고 연결을 켜거나 끄는 정도만 조작하는 경우가 많습니다. 반면 Clash는 프록시 노드와 규칙을 조합해 어떤 요청을 어느 경로로 보낼지 세밀하게 결정하는 프록시 클라이언트입니다.

여기서 말하는 Clash는 단순한 VPN 서비스가 아니라, 설정 파일을 읽고 프록시 그룹과 분류 규칙을 실행하는 클라이언트 계층을 뜻합니다. 실제 연결을 처리하는 커널은 원본 Clash 계열이나 현재 널리 사용되는 mihomo 계열일 수 있습니다. 따라서 Clash를 설치했다고 해서 자동으로 VPN 서비스가 제공되는 것은 아닙니다. 사용할 노드, 구독 또는 로컬 설정, 규칙 파일이 별도로 필요합니다.

Clash와 일반적인 VPN의 핵심 차이
항목 Clash VPN
기본 역할 규칙에 따라 프록시 경로를 분기 기기 트래픽을 VPN 터널로 전달
경로 선택 도메인, IP, 국가, 프로세스 등에 따라 선택 가능 대체로 선택한 서버 하나를 전체 경로로 사용
필요한 것 클라이언트, 설정 파일, 노드 또는 구독 VPN 앱과 서비스 계정 또는 서버 정보
설정 난이도 규칙과 DNS, TUN을 이해할수록 선택 폭이 넓음 앱 설치 후 서버 선택만으로 시작하기 쉬움
대표 목적 선택적 우회, 분할 라우팅, 여러 노드 관리 공용 Wi-Fi 보호, 원격망 접속, 전체 트래픽 터널링

이름보다 연결 방식을 먼저 확인하기

일부 서비스는 마케팅 문구에서 프록시를 VPN이라고 부르고, 일부 Clash 클라이언트는 TUN 모드를 VPN 모드처럼 설명합니다. 정확한 비교를 하려면 이름이 아니라 암호화 터널을 누가 제공하는지, 어떤 트래픽이 실제로 가상 인터페이스를 통과하는지를 확인해야 합니다.

Clash는 요청을 어떻게 나누는가

Clash의 핵심은 proxies, proxy-groups, rules 세 영역입니다. proxies에는 실제 노드 정보가 들어가고, proxy-groups는 여러 노드를 선택할 수 있는 묶음입니다. rules는 특정 도메인이나 IP가 어떤 그룹을 사용할지 결정합니다. 예를 들어 업무 사이트는 DIRECT로 보내고, 특정 해외 도메인은 프록시 그룹으로 보내며, 나머지는 기본 그룹으로 처리할 수 있습니다.

일반적인 규칙은 위에서 아래로 평가됩니다. 먼저 일치한 규칙이 적용되므로 순서가 중요합니다. 넓은 규칙인 GEOIP,CN,DIRECT를 너무 앞에 배치하면 그 아래에 작성한 도메인 예외가 실행되지 않을 수 있습니다. 반대로 특정 도메인을 먼저 지정하고 마지막에 MATCH,Proxy와 같은 기본 규칙을 두면 예상하지 못한 요청도 처리할 수 있습니다.

mixed-port: 7890
mode: rule
allow-lan: false

proxy-groups:
  - name: Select
    type: select
    proxies:
      - Node-A
      - Node-B
      - DIRECT

rules:
  - DOMAIN-SUFFIX,internal.example,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,Select

데스크톱에서 시스템 프록시를 켜면 HTTP와 HTTPS 프록시를 인식하는 프로그램이 127.0.0.1:7890 같은 로컬 포트로 요청을 보냅니다. 그러나 모든 프로그램이 시스템 프록시 설정을 따르는 것은 아닙니다. 명령줄 도구, 일부 게임, 가상 머신, 자체 네트워크 라이브러리를 사용하는 앱은 프록시를 우회할 수 있습니다. 이때 사용할 수 있는 것이 TUN 모드입니다.

TUN은 운영체제에 가상 네트워크 인터페이스를 만들고 더 넓은 범위의 트래픽을 Clash 커널로 전달합니다. 다만 TUN을 켠다고 모든 앱의 모든 통신이 완벽히 처리되는 것은 아닙니다. 관리자 권한, 가상 어댑터 드라이버, 라우팅 충돌, DNS 설정이 함께 영향을 줍니다. 처음 설정할 때는 시스템 프록시부터 확인하고, 필요한 경우에만 TUN으로 범위를 넓히는 것이 안전합니다.

VPN이 더 적합한 상황과 한계

VPN은 네트워크 전체를 하나의 보호된 터널로 묶고 싶을 때 이해하기 쉽습니다. 카페나 호텔의 공용 Wi-Fi에서 기기와 VPN 서버 사이의 통신을 보호하거나, 회사와 집 사이의 사설 네트워크에 접속하거나, 운영체제 수준에서 여러 앱을 한 번에 연결해야 한다면 VPN의 구조가 자연스럽습니다. 서비스 사업자가 서버, 인증, 암호화, 장애 대응을 함께 제공하는 상품이라면 사용자는 노드 설정을 직접 관리하지 않아도 됩니다.

하지만 VPN 연결이 곧 익명성을 보장하는 것은 아닙니다. VPN 사업자는 사용자의 연결 메타데이터를 볼 수 있는 위치에 있고, 접속한 웹사이트는 VPN 서버의 IP 주소를 볼 수 있습니다. 웹사이트 계정에 로그인하면 해당 서비스는 여전히 계정 활동을 식별할 수 있습니다. 따라서 'VPN을 켜면 모든 추적이 사라진다'는 설명은 정확하지 않습니다. 사업자의 로그 정책, 관할 지역, 결제 정보, 앱의 권한과 개인정보 처리방침을 함께 검토해야 합니다.

  • 공용 네트워크에서 전체 기기를 간단히 보호하려면 VPN이 편리합니다.
  • 회사 내부망, NAS, 라우터 등 특정 사설 네트워크에 접속할 때는 VPN 서버 구성이 더 적합할 수 있습니다.
  • 국가별로 다른 경로를 동시에 사용하거나 국내 사이트만 직접 연결하려면 일반 VPN보다 Clash의 규칙 분기가 유리합니다.
  • VPN 제공업체의 서버 품질과 개인정보 처리방침을 확인하지 않고 무료 앱을 설치하는 것은 피해야 합니다.

무료 VPN과 무료 노드를 같은 기준으로 보지 않기

무료 VPN은 운영 비용을 광고, 데이터 분석, 제한된 속도 정책으로 충당할 수 있고, 무료 프록시 노드는 출처와 관리 주체가 불명확할 수 있습니다. 어느 쪽이든 로그인 정보나 결제 정보를 무조건 안전하게 보호한다고 가정해서는 안 됩니다. 서비스 약관과 개인정보 처리방침을 읽고, 민감한 작업에는 신뢰할 수 있는 연결을 사용하세요.

사용 목적에 따라 선택하는 기준

초보자는 기능 개수보다 어떤 트래픽을 얼마나 자주 직접 제어할지부터 정하는 편이 좋습니다. 단순히 연결 버튼 하나로 노트북 전체를 보호하고 싶고 규칙을 직접 관리할 필요가 없다면 평판이 확인된 VPN 앱이 시작하기 쉽습니다. 반대로 사이트 유형별로 연결을 나누거나, 여러 노드를 지연 시간에 따라 바꾸거나, 국내 서비스는 직접 연결하고 일부 도메인만 프록시로 보내고 싶다면 Clash가 더 잘 맞습니다.

목적별 권장 선택
상황 우선 고려할 선택 이유
설정 없이 전체 연결 사용 VPN 앱 설치와 서버 선택만으로 시작 가능
국내 사이트는 직접 연결하고 일부만 우회 Clash 규칙 기반 분할 라우팅 가능
여러 구독 노드와 그룹 관리 Clash 선택 그룹, 자동 선택, 규칙 그룹을 구성할 수 있음
회사 내부망에 원격 접속 기업 VPN 인증과 사설망 라우팅이 서버 측에서 관리됨
특정 앱이 시스템 프록시를 무시함 Clash TUN 또는 VPN 앱의 프록시 지원 여부에 덜 의존함

두 기술을 반드시 하나만 선택해야 하는 것도 아닙니다. 다만 동시에 실행하면 기본 라우트, DNS, MTU, 로컬 포트가 충돌할 수 있습니다. VPN이 먼저 모든 트래픽을 터널로 보내고 Clash가 그 위에서 다시 프록시를 사용하면 속도가 떨어지거나 연결이 반복되는 경우가 있습니다. 테스트할 때는 한 번에 하나의 TUN 또는 VPN 연결만 활성화하고, 문제가 생기면 연결 순서와 DNS 경로를 기록하세요.

처음 시작할 때 직접 확인하는 순서

아래 순서는 Windows와 macOS의 데스크톱 Clash 클라이언트에서 공통으로 적용할 수 있는 기본 점검 절차입니다. 메뉴 이름은 클라이언트마다 조금 다르지만, 시스템 프록시와 TUN을 동시에 처음부터 켜지 않는다는 원칙은 같습니다.

  1. 공식 배포 경로에서 유지보수 상태가 확인되는 Clash 클라이언트를 설치합니다. 현재 설정이 요구하는 프로토콜이 VLESS, Hysteria2, TUIC 또는 WireGuard라면 내장 커널이 mihomo 계열인지 확인합니다.
  2. 클라이언트의 '프로필' 또는 '구독' 메뉴에서 제공받은 구독 URL을 추가합니다. URL은 비밀번호와 같은 민감한 정보이므로 공개 채팅이나 화면 캡처에 포함하지 않습니다.
  3. 프로필을 업데이트한 뒤 노드 목록과 커널 로그를 확인합니다. 구독 다운로드 성공과 노드 파싱 성공은 별개이므로, 노드가 실제로 표시되는지 확인해야 합니다.
  4. 먼저 '모드'를 Rule로 선택하고, 시스템 프록시를 켭니다. 일반 브라우저에서 현재 IP 확인 사이트와 평소 접속하던 사이트를 각각 열어 직접 연결과 프록시 연결 결과를 비교합니다.
  5. 작동하지 않는 앱이 있으면 해당 앱이 시스템 프록시를 지원하는지 확인합니다. 지원하지 않는 경우에만 '설정' → 'TUN 모드'와 비슷한 메뉴에서 TUN을 활성화하고 관리자 권한 요청을 승인합니다.
  6. 문제가 생기면 TUN, 시스템 프록시, VPN을 모두 끈 뒤 하나씩 다시 켭니다. 이때 로컬 혼합 포트는 보통 7890 또는 7897이며, 실제 값은 클라이언트의 포트 설정에서 확인해야 합니다.
# Windows PowerShell에서 로컬 HTTP 프록시 응답 확인
curl.exe -I https://example.com --proxy http://127.0.0.1:7890

# macOS 또는 Linux에서 동일한 확인
curl -I https://example.com --proxy http://127.0.0.1:7890 --max-time 8

명령 결과가 나오면 로컬 프록시 포트가 열려 있다는 뜻이지만, 노드가 정상이고 원하는 경로를 사용한다는 의미까지 포함하지는 않습니다. 클라이언트 로그에서 선택된代理 그룹, DNS 오류, TLS 오류를 함께 확인해야 합니다. 포트가 닫혀 있으면 클라이언트 실행 여부와 포트 번호를 먼저 확인하고, 연결은 되지만 특정 사이트만 실패하면 해당 도메인의 규칙과 DNS 응답을 점검합니다.

안전하게 사용하기 위한 마지막 점검

Clash와 VPN 모두 암호화되지 않은 웹사이트를 자동으로 안전하게 만들어 주는 도구는 아닙니다. HTTPS를 사용하는 사이트라도 연결 경로의 DNS 질의, 접속 시각, 서버 IP, 앱의 로그가 별도로 남을 수 있습니다. 특히 출처가 불명확한 설정 파일은 임의의 DNS 서버, 외부 스크립트, 알 수 없는规则 provider를 포함할 수 있으므로 내용을 확인한 뒤 사용해야 합니다.

  • 구독 URL 보호: URL에 인증 토큰이 포함되어 있다면 비밀번호처럼 취급하고, 노출되면 제공자에게 재발급을 요청합니다.
  • allow-lan 확인: 다른 기기에서 프록시를 사용할 필요가 없다면 allow-lan: false를 유지하고, 외부 제어 포트도 127.0.0.1에 바인딩합니다.
  • 관리 포트 보호: 외부 제어 API를 인터넷에 공개하지 말고, 필요하다면 인증 secret을 설정합니다.
  • 규칙 출처 확인: 원격 rule-provider와 스크립트는 주소와 업데이트 주기를 확인하고, 불필요한 항목은 제거합니다.
  • 로그 점검: 연결이 느릴 때 무작정 노드를 바꾸지 말고 DNS 실패, TLS 시간 초과, 규칙 오매칭을 순서대로 확인합니다.

정리하면 VPN은 전체 연결을 단순하게 터널링하고 싶을 때, Clash는 여러 경로를 규칙으로 나누고 직접 제어하고 싶을 때 적합합니다. 초보자라면 먼저 '어떤 앱과 사이트를 어느 경로로 보낼 것인가'를 적어 보고, 전체 보호가 목적이면 VPN부터, 선택적 분기와 노드 관리가 목적이면 Clash부터 시작하세요. 두 경우 모두 신뢰할 수 있는 배포 경로와 설정 출처를 선택하고, 시스템 프록시와 TUN의 차이를 확인하는 것이 안전한 출발점입니다>

Clash 다운로드