QUICKSTART / 10 MINUTES

Clash 사용 가이드: 구독 가져오기부터 연결 확인까지

정해진 순서대로 진행합니다. 클라이언트를 준비하고 설정을 가져온 뒤 규칙 모드를 선택하고 시스템 프록시를 켭니다. 마지막으로 연결 기록에서 트래픽이 Clash를 거쳤는지 확인합니다. 이 문서에서는 처음 사용할 때 필요한 작업만 다룹니다.

START READY
  1. 01 구독 가져오기 Profiles / Configs
  2. 02 모드 선택 Rule
  3. 03 연결 설정 System Proxy
  4. 04 결과 확인 Connections / Logs

PLATFORM ENTRY

먼저 운영체제에 맞는 클라이언트 선택

시작 전: 클라이언트, 구독 주소 및 시스템 권한

작업을 시작하기 전에 두 가지를 준비해야 합니다. 현재 운영체제에 맞는 Clash 그래픽 클라이언트와 서비스 제공업체가 발급한 Clash 구독 주소입니다. 클라이언트는 설정을 읽고 로컬 프록시 포트를 열어 규칙을 실행하며, 구독 주소는 노드·프록시 그룹·규칙을 제공합니다. 둘은 서로 다른 항목이므로 클라이언트만 설치하고 사용할 설정이 없으면 프록시 화면에 선택 가능한 노드가 나타나지 않는 경우가 많습니다.

먼저 다운로드 센터로 이동해 Windows, macOS 또는 Linux에 맞는 설치 패키지를 선택합니다. Windows 사용자는 보통 현재 아키텍처에 맞는 설치 프로그램을 내려받아 안내에 따라 설치합니다. macOS 사용자는 Apple Silicon과 Intel 프로세서를 구분해야 하며, Linux 사용자는 배포판에 맞는 패키지 형식을 선택해야 합니다. 처음 실행할 때 네트워크, VPN 설정 또는 방화벽 권한을 요청할 수 있습니다. 이러한 권한은 로컬 프록시나 가상 네트워크 인터페이스를 설정하는 데 사용되므로 사용하는 클라이언트의 기능에 맞춰 허용합니다.

구독 주소는 일반적으로 서비스 제공업체의 관리 콘솔에서 생성되며, https://로 시작하는 긴 링크 형태입니다. 계정 식별에 사용되는 매개변수가 포함될 수 있으므로 전체 주소를 공개 채팅, 스크린샷 또는 로그 게시물에 붙여 넣지 마세요. 이 문서에서는 노드나 구독 서비스를 제공하지 않으며 “무료 노드”를 안정적인 설정 출처로 권장하지도 않습니다. 공개된 주소는 자주 만료되고 설정 내용이 변경되지 않았는지 확인하기 어렵습니다.

설치가 끝나면 먼저 클라이언트를 실행하되 시스템 프록시는 바로 켜지 않아도 됩니다. 첫 실행의 목표는 프로그램이 정상적으로 메인 화면에 진입하고 “설정”, “구독” 또는 “Profiles” 메뉴를 찾을 수 있는지 확인하는 것입니다. 먼저 설정을 가져오고 정책을 선택한 다음 마지막에 시스템 프록시를 켭니다. 이 순서를 따르면 클라이언트가 규칙을 아직 불러오지 않은 상태에서 시스템 트래픽이 준비되지 않은 로컬 포트로 향하는 일을 막을 수 있습니다.

구독 가져오기: 클라이언트에 설정 파일 불러오기

사이드바에서 “설정”, “구독”, “Profiles” 또는 “Configs” 페이지로 이동합니다. 대부분의 데스크톱 클라이언트는 페이지 상단에 URL 입력란과 함께 “가져오기”, “다운로드”, “추가” 또는 더하기 버튼을 제공합니다. 전체 구독 주소를 입력란에 붙여 넣고 가져오기를 실행합니다. 클라이언트가 원격 설정을 요청한 뒤 받은 YAML 설정을 로컬 설정 디렉터리에 저장합니다.

가져오기가 완료되면 페이지에 새 설정 기록이 표시됩니다. 일반적으로 설정 이름, 업데이트 시간 및 업데이트 버튼이 함께 나타납니다. 기록이 보였다고 바로 페이지를 떠나지 말고 해당 기록을 클릭하거나 오른쪽 메뉴에서 현재 설정으로 지정하세요. 일부 클라이언트에서는 이 작업을 “활성화”, “선택” 또는 “활성 설정으로 지정”이라고 표시합니다. 기록 옆에 선택 표시, 색상 테두리 또는 Active 상태가 있다면 설정이 이미 적용된 것입니다.

“프록시” 페이지로 전환해 결과를 확인합니다. 정상이라면 “노드 선택”, “자동 선택”, “장애 조치” 또는 서비스 제공업체가 정한 이름의 프록시 그룹이 여러 개 표시됩니다. 각 그룹에는 최소한 DIRECT, 자동 정책 또는 특정 노드를 선택할 수 있어야 합니다. 그룹 이름에는 통일된 형식이 없습니다. 화면이 더 이상 비어 있지 않고 정책과 노드 계층이 보이면 코어가 설정을 읽은 것입니다.

가져오기를 클릭한 뒤 형식 오류가 표시되면 먼저 해당 링크가 Clash YAML 구독인지, 다른 클라이언트용 범용 구독인지 구분하세요. 브라우저에서 링크가 열린다고 형식이 호환되는 것은 아닙니다. 응답이 proxies, proxy-groups, rules 등의 필드가 포함된 YAML이 아니라 인코딩된 텍스트 한 덩어리라면 현재 클라이언트가 직접 읽지 못할 수 있습니다. 형식 식별, 설정 파일 구조 및 구독 변환은 더 많은 예외 상황을 포함하므로 이런 문제가 발생하면 사용 설명서의 설정 장을 확인하세요.

구독을 가져온 뒤에는 “업데이트”와 “편집”의 차이도 알아야 합니다. 업데이트는 원격 주소에서 설정을 다시 다운로드하는 작업으로, 서비스 제공업체가 노드를 추가하거나 규칙을 수정한 뒤 실행합니다. 로컬 파일을 직접 편집하면 현재 복사본만 바뀌며 다음 업데이트 때 원격 내용으로 덮어써질 수 있습니다. 처음 사용할 때는 사용자 지정 규칙을 서둘러 추가하지 말고 원본 설정으로 먼저 연결을 한 번 완료하세요. 기본 연결이 정상임을 확인한 뒤 규칙 덮어쓰기, 스크립트 확장 또는 설정 병합을 처리하는 것이 좋습니다.

프록시 모드 선택: 처음에는 규칙 모드 사용

설정을 불러온 뒤 “프록시” 페이지나 메인 화면의 모드 선택 영역으로 이동합니다. 일반적인 옵션은 규칙 모드, 전역 모드 및 직접 연결 모드이며 화면에는 각각 Rule, Global, Direct로 표시됩니다. 처음에는 규칙 모드를 권장합니다. 규칙 모드는 설정 파일의 규칙을 위에서부터 대조하고 결과에 따라 연결을 DIRECT, PROXY, REJECT 또는 특정 프록시 그룹으로 전달합니다.

규칙 모드의 장점은 트래픽을 종류별로 나누어 처리할 수 있다는 것입니다. 예를 들어 로컬 네트워크와 설정에서 직접 연결로 지정한 도메인은 DIRECT로 보낼 수 있고, 프록시가 필요한 도메인은 PROXY 그룹으로 보낼 수 있으며, 차단하도록 지정한 요청은 REJECT로 처리됩니다. 사용자는 보통 프록시 그룹에서 노드만 선택하면 되므로 웹사이트마다 연결 방식을 직접 정할 필요가 없습니다. 규칙 우선순위, 도메인 매칭, IP 매칭 및 최종 MATCH 대체 처리는 고급 내용이므로 사용 설명서의 규칙 분기 장에서 계속 확인하세요.

전역 모드는 대부분의 연결을 현재 선택한 프록시 노드로 전달하므로 특정 웹사이트가 규칙 분기 때문에 직접 연결되는지 잠시 확인할 때 유용합니다. 하지만 문제 해결의 유일한 방법으로 사용하기에는 적합하지 않습니다. 직접 연결 모드는 프록시를 우회하며, 원래 네트워크를 일시적으로 복구하거나 문제가 프록시 경로에서 발생했는지 확인할 때 사용합니다. 문제 해결이 끝나면 실제 필요에 따라 규칙 모드로 되돌리세요.

Rule을 선택한 뒤 프록시 그룹을 설정합니다. 최상위의 “노드 선택” 또는 유사한 그룹 이름을 클릭해 먼저 특정 노드를 선택하세요. 설정에 “자동 선택” 정책이 있다면 해당 정책을 선택해 코어가 설정에 정의된 테스트 방식으로 후보 노드를 고르게 할 수도 있습니다. 화면의 지연 시간 테스트는 클라이언트와 테스트 주소 사이의 응답만 보여줄 뿐 모든 웹사이트에 접속할 수 있음을 보장하지 않습니다. 여기서는 명백히 연결되지 않는 노드를 걸러내는 용도로만 사용하세요.

일부 설정에는 여러 단계의 프록시 그룹이 포함됩니다. 최상위 그룹이 “자동 선택”, “지역별 그룹” 또는 다른 하위 그룹을 가리키고 하위 그룹이 다시 특정 노드를 가리키는 구조입니다. 상위 정책을 변경한 뒤에는 참조된 하위 그룹으로 들어가 최종 노드를 확인해야 합니다. 상위에서 자동 정책을 선택했다면 하위 노드를 수동으로 바꿔도 현재 연결에 즉시 반영되지 않을 수 있습니다. 상위에서 특정 지역 그룹을 선택했다면 실제 출구는 해당 지역 그룹의 선택 항목입니다.

RULE ORDER config.yaml
01 DOMAIN-SUFFIX,example.net,PROXY
02 GEOIP,CN,DIRECT
03 MATCH,PROXY

연결 설정: 시스템 프록시를 켜고 클라이언트 실행 유지

클라이언트 홈 화면 또는 설정 화면으로 돌아가 “시스템 프록시” 또는 “System Proxy” 스위치를 찾아 켭니다. 이 작업은 운영체제의 HTTP 및 HTTPS 프록시 설정을 Clash가 수신 대기 중인 로컬 주소로 지정합니다. 일반적으로 127.0.0.1과 로컬 포트 조합으로 표시됩니다. 포트 번호는 클라이언트 설정에 따라 다르므로 다른 가이드에서 특정 고정 번호를 사용한다고 해서 현재 설정을 같은 값으로 직접 바꾸지 마세요.

시스템 프록시를 켜면 브라우저와 시스템 프록시 설정을 읽는 대부분의 데스크톱 앱이 요청을 Clash로 보냅니다. 클라이언트는 계속 실행 중이어야 합니다. 프로세스를 종료하면 로컬 수신 포트도 사라지며 시스템 프록시가 즉시 복구되지 않을 경우 앱에서 모든 웹페이지가 열리지 않을 수 있습니다. 클라이언트를 종료하기 전에 시스템 프록시를 끄거나 종료 시 시스템 설정을 자동으로 복구하는 클라이언트인지 확인하세요.

Windows에서 일반 데스크톱 브라우저는 연결되지만 Microsoft Store 앱 또는 일부 시스템 구성 요소에 연결 기록이 나타나지 않는다면 UWP 루프백 제한을 확인해야 할 수 있습니다. 클라이언트에 따라 설정이나 서비스 모드 영역에 루프백 지원 메뉴가 제공됩니다. 이 작업은 Windows 앱 컨테이너의 네트워크 권한과 관련되며 모든 PC에서 필요한 것은 아닙니다. 대상 앱이 현재 프록시를 실제로 읽지 않을 때만 처리하고, 자세한 원리는 사용 설명서의 시스템 프록시 및 TUN 장을 확인하세요.

macOS에서 처음 시스템 네트워크 프록시를 변경할 때 시스템 암호를 요구할 수 있으며, TUN을 활성화할 때는 네트워크 확장 허용을 요청할 수 있습니다. Linux 데스크톱 환경은 시스템 프록시 지원이 일관되지 않습니다. 브라우저는 데스크톱 설정을 읽을 수 있지만 터미널 프로그램은 보통 그렇지 않습니다. 따라서 이 단계에서는 먼저 브라우저로 시스템 프록시를 확인하고 터미널 프로그램은 다음 단계에서 별도로 점검합니다.

TUN 모드는 처음 연결할 때 반드시 필요한 옵션이 아닙니다. 가상 네트워크 인터페이스를 통해 시스템 프록시를 읽지 않는 트래픽까지 더 넓게 처리하지만 관리자 권한, 라우팅, DNS 및 다른 VPN 소프트웨어와의 연동이 필요합니다. 먼저 시스템 프록시만 켜서 구독, 노드 및 규칙이 작동하는지 확인하세요. 게임, 명령줄 도구 또는 특정 앱이 연결되지 않을 때만 TUN을 활성화하는 것이 좋습니다. 이렇게 하면 문제가 발생해도 점검 범위를 줄일 수 있습니다.

시스템 프록시를 켜자마자 자동으로 꺼지거나 클라이언트에서 포트가 사용 중이라고 표시되면 다른 프록시 프로그램을 종료하고 백그라운드에서 다른 Clash 인스턴스가 실행 중인지 확인하세요. 여러 프로그램이 같은 시스템 프록시 설정을 동시에 변경하게 하거나 두 프로그램이 같은 포트를 수신 대기하게 하지 마세요. 충돌을 정리한 뒤 클라이언트를 다시 시작하고 설정 활성화, Rule 모드, 노드 선택, 시스템 프록시 순서대로 다시 확인합니다.

적용 여부 확인: 브라우저와 연결 기록 함께 점검

브라우저를 열어 평소 안정적으로 로드되는 HTTPS 페이지에 접속합니다. “웹페이지가 열렸다”는 사실만으로 프록시가 적용되었다고 판단하지 마세요. 규칙에 따라 해당 페이지가 DIRECT로 연결되었을 수 있습니다. 그런 다음 Clash 클라이언트로 돌아가 “연결” 또는 “Connections” 페이지에서 방금 브라우저가 만든 새 세션이 나타나는지 확인합니다. 세션 기록에는 보통 대상 도메인, 프로토콜, 적용된 규칙 및 최종 정책이 표시됩니다.

해당 도메인을 찾은 뒤 두 가지를 중점적으로 확인합니다. 어떤 규칙이 적용되었는지와 최종적으로 어떤 정책을 사용했는지입니다. DIRECT로 표시되면 요청이 규칙 엔진을 거쳤지만 설정에 따라 직접 연결된 것입니다. PROXY 또는 특정 프록시 그룹과 노드로 표시되면 요청이 프록시 경로로 들어간 것입니다. REJECT로 표시되면 규칙이 요청을 차단한 것입니다. 이 확인 방법은 단순히 웹페이지를 새로 고치는 것보다 정확하며 “Clash에 들어오지 않음”과 “Clash에 들어왔지만 규칙에 따라 직접 연결됨”을 구분할 수 있습니다.

그다음 “로그” 또는 “Logs” 페이지를 엽니다. 정상적인 연결이라면 대상 주소, 규칙 매칭 및 정책 선택 기록을 볼 수 있습니다. 연결 시간 초과가 계속 나타나면 같은 프록시 그룹의 다른 노드로 바꿔 보세요. 도메인 확인 실패가 나타나면 DNS 설정과 TUN 상태, 다른 네트워크 도구가 DNS를 동시에 처리하고 있는지 확인합니다. 브라우저 요청이 로그에 전혀 나타나지 않는다면 시스템 프록시 스위치, 브라우저 프록시 확장 프로그램 또는 앱 자체의 프록시 설정이 원인일 가능성이 큽니다.

브라우저 확장 프로그램이 시스템 프록시를 덮어쓸 수 있습니다. 프록시 전환 확장 프로그램이 설치되어 있다면 먼저 일시 중지하거나 시스템 설정을 읽도록 변경한 뒤 새 페이지를 열어 다시 테스트하세요. 브라우저에 이미 열린 연결이 재사용될 수 있으므로 테스트할 때는 새 시크릿 창을 열거나 브라우저를 완전히 종료한 후 다시 실행하는 것이 좋습니다. 그러면 Connections 페이지에서 방금 생성된 세션을 더 쉽게 찾을 수 있습니다.

터미널 프로그램은 별도로 확인해야 합니다. 많은 명령줄 도구는 데스크톱 시스템 프록시를 읽지 않고 HTTP_PROXY, HTTPS_PROXY, ALL_PROXY 환경 변수나 명령 매개변수에 명시된 프록시 주소를 사용합니다. 먼저 클라이언트 설정 페이지에서 HTTP 또는 mixed 포트를 확인한 뒤 명시적 매개변수로 요청을 한 번 보내 보세요:

curl -x http://127.0.0.1:7890 https://example.com

위의 7890은 명령 구조를 보여 주는 예시일 뿐입니다. 실제로는 현재 클라이언트에 표시된 로컬 HTTP 또는 mixed 포트로 바꿔야 합니다. 명령을 실행한 뒤 Connections 페이지에서 해당 세션을 찾으세요. 명시적 프록시로는 연결되지만 -x 없이 실행한 명령에는 기록이 없다면 Clash 자체는 정상이며 터미널에 프록시 환경 변수가 설정되지 않은 것입니다.

마지막으로 복구 테스트를 진행합니다. 시스템 프록시를 끄고 페이지를 새로 고친 뒤 새 요청이 Connections에 더 이상 나타나지 않는지 확인합니다. 그런 다음 시스템 프록시를 다시 켜고 세션이 다시 생성되는지 확인하세요. 이 전후 비교를 통해 시스템 설정이 실제로 변경되었는지 검증할 수 있습니다. 완료 후에는 Rule 모드를 유지하고 실제 사용 환경에 따라 클라이언트의 시작 시 자동 실행 여부를 결정하세요. 종료 동작을 이해하기 전에는 여러 네트워크 도구의 자동 시작을 동시에 켜지 않는 것이 좋습니다.

10분이 지나도 연결되지 않을 때: 경로 순서대로 문제 해결

문제를 해결할 때 모든 스위치를 무작정 반복해서 바꾸지 마세요. Clash의 기본 연결 경로는 다섯 단계로 나눌 수 있습니다. 구독 주소 다운로드, 코어의 설정 읽기, 사용 가능한 정책이 있는 프록시 그룹, 수신 대기 중인 로컬 포트, 해당 포트로 트래픽을 보내는 대상 앱입니다. 이 순서대로 확인하면 문제가 어느 단계에서 멈췄는지 빠르게 판단할 수 있습니다.

  1. 설정 단계: 설정 페이지로 돌아가 한 번 업데이트하고 현재 설정이 명확하게 선택되어 있는지 확인합니다. 업데이트에 실패했다면 노드를 계속 바꾸기보다 먼저 구독 주소, 네트워크 연결 또는 설정 형식 문제를 해결하세요.
  2. 정책 단계: 프록시 페이지에서 모드가 Rule인지 확인하고 최상위 프록시 그룹이 사용할 수 없는 항목에 머물러 있지 않은지 확인합니다. 특정 노드를 바꾼 뒤 새 브라우저 연결을 생성하세요. 오래 열어 둔 페이지로 결과를 판단하지 마세요.
  3. 포트 단계: 클라이언트 로그에 포트 사용 중 또는 코어 시작 실패가 표시되는지 확인합니다. 포트가 충돌하면 다른 프록시 프로그램과 중복 실행된 클라이언트 인스턴스를 종료한 뒤 다시 시작하세요.
  4. 시스템 단계: System Proxy가 켜져 있는지 확인합니다. Windows에서는 시스템 프록시 설정을 확인하고, macOS에서는 현재 네트워크 서비스의 프록시 항목을 점검합니다. Linux에서는 데스크톱 환경과 대상 앱이 같은 설정을 읽는지 확인해야 합니다.
  5. 앱 단계: 브라우저에서는 프록시 확장 프로그램을, 터미널에서는 환경 변수를, 게임이나 특정 앱에서는 TUN 필요 여부를 확인합니다. 한 앱의 결과만으로 모든 앱이 같은 프록시 방식을 사용한다고 판단하지 마세요.

문제가 특정 웹사이트에서만 발생하고 다른 프록시 연결은 정상이라면 해당 사이트 세션의 규칙, 정책 및 오류 메시지를 확인하세요. 규칙 오류는 설정 단계, 노드에 접속할 수 없는 문제는 출구 단계, DNS 실패는 이름 확인 단계의 문제입니다. 모든 웹사이트에 연결 기록이 전혀 없다면 규칙 파일을 먼저 수정하지 말고 시스템 프록시와 앱 설정부터 확인하세요.

여전히 원인을 찾지 못했다면 실행 가능한 원본 설정을 보관하고 클라이언트 이름, 운영체제, 현재 모드, TUN 활성화 여부, 로그의 구체적인 오류 및 Connections에 세션이 나타나는지 기록하세요. 그런 다음 처음부터 익히는 사용 설명서에서 시스템 프록시, TUN, DNS, 규칙 분기 및 로그 장을 순서대로 확인합니다. 심화 설정은 설명서에 모아 두었으며 이 페이지에서는 첫 연결에 필요한 최소 작업만 다룹니다.

NEXT READING

규칙, DNS 또는 TUN을 수정해야 하나요?

체계적인 설명서를 계속 읽고 설정 파일 구조, 규칙 우선순위, 포트별 역할, 가상 네트워크 인터페이스 및 일상적인 관리 방법을 알아보세요.

사용 설명서 열기
클라이언트 다운로드