개념 점검 / 용어 색인
구독의 설정 항목부터 클라이언트의 토글까지, 먼저 각 용어가 어느 계층에 속하는지 구분한 다음 설정을 조정하세요. 자주 쓰는 개념을 다섯 가지 주제로 정리했으며, 각 용어 카드 제목 옆 링크를 눌러 바로 이동할 수 있습니다.
프로토콜과 전송
프로토콜 이름은 속도 순위가 아닙니다. 먼저 클라이언트가 지원하는지 확인하고 서버 설정을 대조하세요. 설계와 선택 기준은 프로토콜 및 코어 기술 참고서에서 더 자세히 확인할 수 있습니다.
Shadowsocks는 암호화 프록시 프로토콜 계열입니다. 설정에는 보통 서버 주소, 포트, 비밀번호, 암호화 방식이 포함됩니다. 기존 AEAD와 Shadowsocks 2022는 암호화 방식 이름과 키 요구 사항이 다르므로 이름만 바꿔 업그레이드할 수 없습니다. 가져온 뒤 암호화 방식을 지원하지 않는다는 메시지가 표시되면 포트를 반복해서 바꾸기보다 코어의 지원 범위를 먼저 확인하세요.
서로 다른 프로토콜이며 UUID를 사용자 식별자로 사용하는 경우가 많지만, UUID가 같다고 설정을 서로 바꿔 쓸 수 있는 것은 아닙니다. VMess는 프로토콜 수준의 암호화를 제공하지만 VLESS 자체는 페이로드를 암호화하지 않으므로, 실제 보안은 TLS 등 함께 설정한 옵션에 따라 달라집니다. 문제를 확인할 때는 프로토콜 유형만 보지 말고 전송 방식, 서버 이름, 경로도 대조해야 합니다.
Trojan은 일반적으로 TLS 연결을 통해 프록시 데이터를 전송하며, 비밀번호로 인증하는 경우가 많습니다. 주소, 포트, 비밀번호가 정확한지뿐 아니라 인증서 검증과 서버 이름도 일치하는지 확인해야 합니다. IP 주소로 연결할 때는 서버 이름 설정을 특히 주의하세요. 인증서 오류가 발생하면 검증을 끄기보다 시간, 이름, 인증서 체인을 먼저 확인하는 것이 좋습니다.
둘 다 QUIC 기반이지만 서로 다른 프록시 프로토콜이며, 하위 네트워크에서 UDP 연결이 가능해야 합니다. QUIC의 혼잡 제어와 다중화가 일부 네트워크에 유리할 수는 있지만, TCP 방식보다 항상 빠르거나 배터리를 덜 소모한다고 단정할 수는 없습니다. 현재 네트워크에서 UDP를 제한한다면 웹페이지에 직접 접속할 수 있어도 이 프로토콜의 연결을 보장하지 않습니다.
TCP와 UDP는 기본 전송 방식이고 WebSocket 등은 데이터를 실어 나르는 방식이며, TLS는 암호화와 인증을 제공합니다. 이 용어들은 같은 계층에 속하지 않습니다. SNI는 TLS 핸드셰이크에서 대상 서버 이름을 지정하며, 노드 표시 이름과는 다릅니다. 설정을 가져올 때는 프로토콜, 전송 방식, 경로, TLS 옵션을 한 묶음으로 확인하세요.
코어와 클라이언트
버튼이 켜져 있다는 것은 해당 설정이 활성화되었다는 뜻일 뿐, 앱 트래픽이 실제로 프록시에 들어오고 있다는 의미는 아닙니다. 사용 순서는 Clash 사용 가이드에서 확인할 수 있습니다.
코어는 프로토콜 연결, 규칙 매칭, DNS 처리를 담당하고 클라이언트는 그래픽 인터페이스, 구독 관리, 시스템 연동을 담당합니다. 화면 구성이 비슷해도 기능은 다를 수 있으며, 같은 클라이언트라도 업데이트 후 다른 버전의 코어를 사용할 수 있습니다. 특정 설정 항목을 지원하지 않는다면 Clash라는 이름만 알릴 것이 아니라 클라이언트 이름과 실제 실행 중인 코어 버전을 함께 확인해야 합니다.
mihomo는 Clash 설정 체계를 이어받은 프록시 코어로, Clash.Meta라는 이름과 역사적으로 관련이 있습니다. 특정 데스크톱이나 모바일 앱을 가리키는 것은 아닙니다. 지원 프로토콜과 설정 확장은 초기 Clash 원본과 다르므로, 오래된 가이드의 호환성 정보를 그대로 적용할 수 없습니다. 클라이언트를 선택할 때는 필요한 코어 기능이 인터페이스나 오버라이드 설정에서 제공되는지도 확인하세요.
시스템 프록시는 운영체제에 로컬 프록시 주소를 등록합니다. 예를 들어 클라이언트가 수신 대기 중인 HTTP 포트나 혼합 포트를 지정할 수 있습니다. 보통 이 설정을 따르는 앱만 해당 경로를 이용하며, 일부 게임, 명령줄 도구, 자체 네트워크 스택을 사용하는 앱은 우회할 수 있습니다. 클라이언트를 종료한 뒤 네트워크에 문제가 생기면 운영체제에 작동이 중지된 프록시 주소가 남아 있는지 확인하세요.
TUN은 가상 네트워크 인터페이스와 라우팅 설정으로 IP 트래픽을 받아 처리하며, 시스템 프록시를 따르지 않는 앱에 주로 사용됩니다. 활성화하려면 추가 권한이 필요할 수 있고 다른 VPN, 가상 네트워크 어댑터, 라우팅 설정과 충돌할 수도 있습니다. TUN은 트래픽이 들어오는 경로를 처리할 뿐이며, 코어에 들어온 연결은 이후에도 규칙에 따라 처리됩니다. 따라서 모든 대상이 프록시 노드를 이용하는 것은 아닙니다.
규칙과 라우팅
라우팅 문제를 확인할 때는 일치한 규칙과 최종 출구를 함께 살펴보세요. 규칙이 제대로 매칭되어도 해당 규칙이 참조하는 프록시 그룹에서 올바른 노드를 선택했다는 뜻은 아닙니다.
규칙 기반 라우팅은 도메인, IP, 프로세스 등의 조건에 따라 연결에 적용할 정책을 정합니다. 보통 위에서부터 확인하며 가장 먼저 일치한 규칙을 적용합니다. 범위가 좁은 예외 규칙은 더 넓은 규칙보다 앞에 두어야 뒤의 규칙에 가려지지 않습니다. 문제를 확인할 때는 노드부터 바꾸기보다 연결 기록에서 어떤 규칙이 일치했는지 확인한 다음 규칙 조건을 살펴보세요.
규칙 모드는 규칙 목록에 따라 정책을 선택하고, 전역 모드는 코어가 처리하는 연결에 전역 정책을 적용합니다. 직접 연결 모드는 기본적으로 트래픽을 직접 연결합니다. 전역 모드라고 해서 코어에 들어오지 않은 트래픽까지 자동으로 가져오지는 않으며, 전역 정책에서도 올바른 대상을 선택해야 합니다. 문제 범위를 좁히기 위해 모드를 임시로 바꿀 수 있지만, 점검을 마친 뒤에는 원래 라우팅 방식으로 되돌려야 합니다.
프록시 그룹은 노드나 다른 정책을 묶어 규칙에서 참조할 수 있는 출구로 만듭니다. select는 직접 선택할 때, url-test는 테스트 결과에 따라 선택할 때, fallback은 사용 가능 여부와 설정 순서에 따라 전환할 때 주로 사용합니다. 자동 선택 결과는 지정한 테스트 기준을 반영할 뿐이므로, 테스트 URL의 성능이 좋다고 모든 웹사이트에서도 원활한 것은 아닙니다.
DIRECT는 직접 연결, REJECT는 연결 거부 정책입니다. MATCH는 추가 조건 없이 매칭되는 규칙 유형이므로 세 가지를 같은 종류로 취급하면 안 됩니다. 예를 들어 MATCH,PROXY는 나머지 연결에 PROXY라는 정책을 적용한다는 뜻이며, 해당 이름의 정책이 실제로 있어야 합니다. MATCH는 보통 마지막에 두어야 뒤의 규칙이 먼저 적용되지 않습니다.
GeoIP는 IP 데이터베이스로, GeoSite는 도메인 목록으로 분류합니다. 두 방식은 서로 다른 문제를 다룹니다. 데이터 파일이 오래되었을 수 있고 웹사이트가 여러 지역의 CDN을 사용할 수도 있으므로, 분류 결과만으로 사이트의 실제 소속이나 노드 품질을 판단할 수는 없습니다. 예상과 다른 결과가 나오면 데이터베이스 출처와 업데이트 시점, 규칙 순서를 확인하세요. 업데이트 방법은 GeoIP 및 GeoSite 참고 문서에서 볼 수 있습니다.
DNS와 네트워크
도메인 해석 성공, 연결 성공, 원하는 다운로드 속도 달성은 각각 별개의 문제입니다. 먼저 어느 단계에서 실패했는지 확인한 뒤 DNS 모드를 바꿀지 결정하세요.
DNS는 도메인을 IP 주소 등의 레코드로 변환하며, 앱은 보통 이 결과를 바탕으로 연결을 설정합니다. 프록시 연결과 DNS 요청은 서로 다른 경로를 이용할 수 있으므로, 노드에 연결된다고 DNS 경로까지 정상인 것은 아닙니다. 문제를 확인할 때는 DNS 응답 시간 초과, 잘못된 주소 반환, 해석 후 연결 실패를 구분하세요. 각 상황에서 확인해야 할 설정은 다릅니다.
Fake-IP는 앱에 매핑된 주소를 반환하고 코어에서 해당 주소와 도메인의 관계를 관리합니다. 198.18.0.1/16은 자주 사용하는 설정용 주소 대역이지 대상 웹사이트의 실제 주소가 아닙니다. 실제 DNS 응답에 의존하는 일부 앱은 fake-ip-filter에 관련 도메인을 추가해야 할 수 있습니다. 예약 주소가 표시되어도 반드시 오류는 아니므로 앱이 정상 작동하는지, DNS 요청이 코어를 거치는지 함께 확인하세요.
redir-host는 일반적으로 실제 DNS 응답 주소를 앱에 반환하므로 Fake-IP와 주소를 매핑하는 방식이 다릅니다. 실제 IP에 의존하는 일부 앱과는 호환성이 더 나을 수 있지만, 해석 시간, 도메인 연결 관계, 공유 IP 등의 조건이 실제 처리에 영향을 줍니다. 모드를 바꾼 뒤에도 앱이나 시스템에 이전 캐시가 남을 수 있으므로, 관련 캐시를 지우거나 연결을 다시 만든 다음 결과를 비교하세요.
DNS 누수는 요청이 예상한 DNS 경로를 벗어나는 현상입니다. 예를 들어 지정한 리졸버가 처리해야 할 요청을 다른 리졸버가 보낼 수 있습니다. 브라우저 보안 DNS, 앱 내장 DNS, 시스템 설정, IPv6에 따라 경로가 달라질 수 있으므로 토글 하나만 보고 판단해서는 안 됩니다. 검사 페이지에 표시된 리졸버 주소는 포워딩 서버나 공용 DNS 서비스일 수도 있으므로 실제 요청 경로를 고려해 해석해야 합니다.
지연 시간은 특정 테스트에 걸린 시간이고 처리량은 단위 시간당 전송할 수 있는 데이터양입니다. 두 지표는 같은 의미가 아닙니다. 클라이언트의 HTTP 테스트에는 핸드셰이크와 응답 대기 시간이 포함될 수 있어 단순한 ICMP 왕복 시간과 다릅니다. 캐시, 테스트 주소, 네트워크 변동도 결과에 영향을 줍니다. 노드를 비교할 때는 테스트 조건을 동일하게 유지하고 실제 서비스 연결로도 확인하세요. 숫자 하나만으로 결정하지 않는 것이 좋습니다.
구독과 설정 파일
구독, 노드 목록, 전체 설정 파일은 서로 같은 형식의 데이터가 아닐 수 있습니다. 가져오기에 실패하면 먼저 형식을 확인하세요. 사용 방법은 구독 링크와 형식 안내에서 확인할 수 있습니다.
구독은 주소를 통해 설정이나 노드 정보를 받아 업데이트하는 방식이며, 프록시 프로토콜 자체는 아닙니다. 링크가 전체 YAML을 반환할 수도 있고 노드 목록만 반환할 수도 있으며, 바로 가져올 수 있는지는 클라이언트가 지원하는 형식에 따라 달라집니다. 주소에 계정 식별 정보가 포함되는 경우가 많으므로 민감한 정보로 취급하세요. 도움을 요청할 때는 스크린샷에서 전체 링크를 가리고, 낯선 온라인 변환 서비스에 함부로 제출하지 마세요.
노드는 일반적으로 프로토콜, 서버 주소, 포트, 인증 정보와 같은 연결 설정의 묶음이며 TLS와 전송 설정이 필요할 수도 있습니다. 표시 이름은 식별을 위한 라벨일 뿐 물리적 위치, 대역폭, 안정성을 증명하지 않습니다. 하나의 구독에 여러 노드가 포함될 수 있지만, 목록에 노드가 있다고 해서 현재 규칙이나 프록시 그룹에서 선택된 것은 아닙니다.
YAML은 들여쓰기로 계층을 표현하는 형식으로, Clash 생태계에서 설정 파일에 널리 사용됩니다. 설정 파일에는 일반적으로 수신 포트, DNS, 노드, 프록시 그룹, 규칙 등이 포함됩니다. 편집할 때는 공백으로 들여쓰고 같은 계층의 정렬을 맞추며, 특수 문자를 따옴표로 감싸야 하는지 확인하세요. 문법을 해석할 수 있어도 현재 코어가 해당 필드를 지원한다는 뜻은 아니므로, 가져오기 오류가 나면 형식과 필드 이름, 코어 호환성을 함께 점검하세요.
흔히 쓰이는 Base64 구독은 노드 URI 목록을 인코딩한 형식입니다. 디코딩하면 연결 정보가 줄마다 표시될 수 있으며, 전체 Clash 설정 파일이 아닐 수도 있습니다. Base64는 암호화가 아닌 인코딩이므로 계정이나 비밀번호를 보호하는 수단으로 사용할 수 없습니다. 바로 가져올 수 있는지는 클라이언트의 파싱 기능에 따라 달라집니다. 특정 노드 프로토콜을 지원한다고 모든 구독 포맷까지 지원하는 것은 아닙니다.
Provider를 사용하면 일부 리소스를 분리해 개별적으로 불러오고 업데이트할 수 있습니다. proxy-providers는 노드 목록을, rule-providers는 규칙 목록을 제공합니다. 리소스 다운로드에 성공하는 것만으로는 충분하지 않습니다. 노드 목록은 프록시 그룹에서 참조해야 하고, 규칙 목록도 해당 규칙을 통해 호출해야 합니다. 문제를 확인할 때는 리소스 상태뿐 아니라 참조 이름, 내용 형식, 최종 규칙 순서도 살펴보세요.
오버라이드를 사용하면 구독 업데이트와 별도로 로컬 설정을 유지할 수 있습니다. 예를 들어 다운로드한 파일을 직접 수정해 업데이트 때 덮어쓰이는 일을 방지하면서 DNS나 수신 포트를 조정하거나 사용자 지정 규칙을 추가할 수 있습니다. 클라이언트마다 설정 병합, 교체, 배열 추가 방식이 달라 같은 내용을 그대로 적용하지 못할 수도 있습니다. 변경 후에는 최종 적용 설정을 확인하고, 특히 규칙을 넣은 위치와 프록시 그룹 이름이 일치하는지 살펴보세요.