용어 한눈에 보기 / 자주 쓰는 용어 25개
먼저 구독, 노드, 설정의 차이를 확인한 뒤 규칙과 DNS를 살펴보세요. 제목 옆 링크로 각 용어를 바로 공유할 수 있습니다. 실제 설정 방법은 가이드와 설정 참고 자료에서 확인하세요.
가져오는 것은 설정, 연결에 사용하는 것은 노드이며, 트래픽을 어디까지 처리할지는 시스템 설정에 따라 달라집니다.
기본 개념
구독은 URL을 통해 프록시 노드나 설정을 가져오고 업데이트하는 방식이며, 프록시 연결 자체를 뜻하지는 않습니다. 반환되는 내용은 전체 YAML일 수도 있고 노드 목록만일 수도 있으므로 가져오기 전에 클라이언트가 지원하는 형식인지 확인하세요. 업데이트한 뒤에는 설정을 활성화하고 정책을 선택해야 합니다. 구독 URL에는 접근 자격 증명이 포함되는 경우가 많으므로 공개하거나 스크린샷에 노출하지 마세요.
구독 가져오기 가이드 보기 →기본 개념
노드는 원격 프록시 서버에 연결하는 데 필요한 매개변수 모음으로, 일반적으로 서버 주소, 포트, 프로토콜, 인증 정보가 포함됩니다. 화면에 표시되는 이름은 식별용일 뿐이므로 이름만으로 실제 연결 위치나 사용 가능 여부를 판단할 수 없습니다. 노드를 선택한 뒤에도 트래픽이 코어로 전달되고 규칙이나 정책이 해당 노드를 지정해야 이 경로로 연결됩니다.
기본 개념
지연 시간은 지정한 테스트를 수행하는 데 걸리는 시간입니다. 연결 설정, TLS 핸드셰이크, 요청 및 응답 시간이 포함될 수 있으며 시스템 ping 결과와 일치하지 않을 수 있습니다. 테스트 주소, 캐시, 당시 네트워크 상태도 수치에 영향을 줍니다. 같은 조건에서 연결 상태를 비교하는 참고 자료로 활용하되 다운로드 속도로 환산해서는 안 됩니다. 시간 초과가 발생하면 로그도 함께 확인하세요.
기본 개념
시스템 프록시는 운영체제가 앱에 제공하는 프록시 주소 설정으로, 보통 로컬 클라이언트의 수신 포트를 가리킵니다. 브라우저 같은 앱은 이 설정을 따르지만 일부 게임, 명령줄 프로그램, 자체 네트워크 스택을 사용하는 앱은 무시할 수 있습니다. 스위치가 켜져 있다는 것은 관련 설정이 변경되었다는 뜻일 뿐입니다. 실제로 트래픽이 프록시를 통과하는지는 해당 연결과 로그를 확인해야 합니다.
기본 개념
혼합 포트는 하나의 로컬 수신 포트에서 HTTP와 SOCKS5 프록시 연결을 모두 받습니다. 예를 들면 mixed-port: 7890처럼 설정합니다. 숫자는 변경할 수 있는 로컬 포트 번호이며 원격 노드의 포트나 속도 등급을 뜻하지 않습니다. 앱에 입력한 포트와 실제 수신 포트가 일치해야 합니다. 시작에 실패하면 먼저 다른 프로세스가 포트를 사용 중인지 확인하세요.
프로토콜에 따라 연결 방식이 달라지며, 인증, 전송 방식, TLS 매개변수도 각각 맞춰야 합니다.
프록시 프로토콜
HTTP 프록시는 앱에서 받은 프록시 요청을 처리합니다. HTTPS 사이트에 접속할 때 앱은 보통 CONNECT로 터널을 만든 뒤 사이트와 TLS 통신을 합니다. 프록시 유형이 HTTP라고 해서 HTTP 사이트만 접속할 수 있는 것은 아니며, 앱과 프록시 사이의 연결이 암호화된다는 뜻도 아닙니다. 프록시를 수동으로 설정할 때는 프록시 프로토콜과 대상 사이트의 프로토콜을 구분하세요.
프록시 프로토콜
SOCKS5는 TCP를 전달하고, 양쪽 구현이 지원하면 해당 메커니즘을 통해 UDP도 전달할 수 있는 범용 프록시 프로토콜입니다. 도메인을 로컬에서 해석할지 프록시에서 해석할지는 앱의 구현과 설정에 따라 달라지므로 SOCKS5라는 이름만으로 판단할 수 없습니다. SOCKS5 자체는 암호화를 제공하지 않으며, 앱이 TCP 프록시를 지원하더라도 UDP 프록시까지 지원한다고 볼 수는 없습니다.
프록시 프로토콜
Shadowsocks는 클라이언트와 서버에서 동일한 암호화 방식과 그에 맞는 인증 정보를 사용해야 하는 프록시 프로토콜입니다. 노드를 가져온 뒤 연결되지 않으면 노드 이름만 바꾸지 말고 주소, 포트, 암호화 방식, 인증 정보를 확인하세요. 프로토콜 확장이나 플러그인마다 추가 요구 사항이 있을 수 있으므로 모든 클라이언트에 같은 Shadowsocks 설정을 그대로 적용할 수는 없습니다.
프록시 프로토콜
Trojan은 일반적으로 TLS를 통해 프록시 통신을 전달하며, 주소, 포트, 인증 정보 외에도 올바른 TLS 설정이 필요합니다. 서버 이름은 인증서 검증과 핸드셰이크에 사용될 수 있으며, 연결 주소와 인증에 사용하는 이름이 다를 수도 있습니다. 인증서 오류가 발생하면 시스템 시간, 이름, 서버 설정을 확인하세요. 인증서 검증을 건너뛰는 것은 일반적인 해결 방법이 아닙니다.
프록시 프로토콜
VLESS는 프록시 프로토콜의 하나로, 실제로는 TLS, REALITY 또는 여러 전송 방식과 함께 구성되는 경우가 많습니다. 프로토콜 이름만 알아서는 노드를 재현할 수 없으며 인증 식별자, 전송 유형, 관련 보안 매개변수도 필요합니다. 클라이언트에 가져오기 결과가 표시되더라도 내장 코어가 모든 조합을 지원한다는 뜻은 아닙니다. 서버 요구 사항과 실제 코어 기능을 기준으로 확인하세요.
먼저 연결에 어떤 규칙이 적용됐는지 확인한 다음, 그 규칙이 어떤 정책을 지정하는지 살펴보세요.
규칙 및 라우팅
규칙 기반 라우팅은 도메인, IP 또는 기타 조건에 따라 연결 경로를 정합니다. 보통 규칙 목록의 위쪽부터 확인해 조건에 맞으면 해당 정책으로 연결을 처리합니다. 예를 들어 DOMAIN-SUFFIX,example.com,DIRECT는 일치하는 도메인을 직접 연결합니다. 앞쪽 규칙의 우선순위가 더 높은 경우가 많으므로 새 규칙이 올바르더라도 앞의 포괄적인 규칙에 먼저 걸릴 수 있습니다.
규칙 및 라우팅
프록시 그룹은 노드나 다른 정책을 묶어 관리합니다. 자주 쓰이는 유형으로는 직접 선택하는 select, 테스트 결과에 따라 선택하는 url-test, 장애 발생 시 전환하는 fallback이 있습니다. 규칙에서 그룹 이름을 지정하면 그룹 유형과 현재 상태에 따라 실제 연결 경로가 결정됩니다. 그룹 이름과 노드 이름을 정확히 입력해야 하며, 그룹 내 선택을 변경해도 기존 장기 연결은 즉시 전환되지 않을 수 있습니다.
규칙 및 라우팅
규칙 모드는 설정된 규칙에 따라 각 연결의 경로를 정하고, 전역 모드는 일반적으로 코어에 전달된 연결을 전역 정책으로 처리합니다. 전역 모드는 트래픽 분기 방식을 바꾸는 기능이지, 모든 앱이 자동으로 시스템 프록시를 따르게 하거나 TUN을 활성화하는 기능은 아닙니다. 평소에는 규칙 모드를 사용해도 충분합니다. 일시적으로 전역 모드로 바꾸면 규칙 문제와 노드 문제를 구분하는 데 도움이 되지만, 전체 점검을 대신할 수는 없습니다.
규칙 및 라우팅
GeoIP는 데이터베이스에 저장된 IP 지역 정보를 규칙 매칭에 사용합니다. 예를 들어 대상 주소의 지역에 따라 정책을 선택할 수 있습니다. GeoIP는 도메인 분류표가 아니며 지역 판정이 항상 정확한 것도 아닙니다. 클라우드 서비스나 네트워크 이전으로 오차가 생길 수 있습니다. 특정 사이트에 잘못된 정책이 적용되면 실제로 어떤 규칙이 일치했는지 먼저 확인한 뒤 도메인 규칙을 조정할지 관련 데이터를 업데이트할지 결정하세요.
규칙 및 라우팅
규칙 세트는 여러 매칭 조건을 별도 콘텐츠로 관리합니다. rule-providers로 불러온 뒤 RULE-SET으로 적용할 정책을 지정합니다. 재사용과 업데이트가 편리하지만 콘텐츠 형식이 behavior 등의 설정과 일치해야 합니다. 규칙 세트를 다운로드한 뒤에는 규칙 목록에서 참조되는지, 적절한 매칭 순서에 배치됐는지도 확인하세요.
DNS 해석 경로, 연결 경로, 트래픽 처리 범위는 서로 연관되어 있지만 별개의 문제입니다.
DNS 및 네트워크
DNS는 도메인을 IP 등의 레코드로 변환합니다. 웹사이트에 접속할 때는 일반적으로 DNS 해석 후 연결을 시작합니다. 해석에 성공해도 대상에 접속할 수 있거나 연결이 프록시를 통과한다는 뜻은 아닙니다. 반대로 연결 실패가 반드시 DNS 문제인 것도 아닙니다. 브라우저가 자체 암호화 DNS를 사용할 수 있으므로 시스템 DNS 설정을 바꾼 뒤에는 앱이 실제로 해당 경로를 사용하는지도 확인하세요.
DNS 설정 보기 →DNS 및 네트워크
Fake-IP 모드는 도메인 조회에 가상 주소를 반환하고, 코어에서 도메인과 주소의 대응 관계를 관리해 이후 연결을 원래 도메인과 연결합니다. 가상 주소는 사이트의 실제 IP가 아니므로 서버 위치를 판단하는 데 사용할 수 없습니다. 실제 주소나 특수한 검색 방식을 사용하는 앱은 필터 설정으로 호환성을 조정해야 할 수 있습니다. 이 모드를 켜도 모든 DNS 요청이 자동으로 처리되는 것은 아닙니다.
DNS 및 네트워크
DNS 누수는 도메인 조회가 의도한 경로를 따르지 않고 다른 DNS 서버에서 처리되는 현상입니다. 검사 페이지에 표시된 DNS 서버의 지역만으로 누수를 단정할 수는 없습니다. 의도한 설정, 브라우저의 암호화 DNS, IPv6, 시스템 라우팅을 함께 확인해야 합니다. 먼저 어떤 서버가 도메인을 해석해야 하는지와 요청이 어떤 경로를 거쳐야 하는지 정한 뒤 실제 동작을 점검하세요. 지역 표기만 보고 결론 내리는 일을 피할 수 있습니다.
DNS 및 네트워크
TUN 모드는 가상 네트워크 인터페이스와 라우팅 설정을 통해 IP 패킷을 코어로 전달합니다. 시스템 프록시를 따르지 않는 앱까지 처리해야 할 때 유용합니다. 실제 적용 범위는 권한, 자동 라우팅, 제외 항목, 시스템 네트워크 상태에 따라 달라집니다. 처음 활성화하기 전에 기존 네트워크 설정을 백업하세요. 충돌이 생기면 다른 VPN이나 유사한 트래픽 처리 도구를 먼저 끈 뒤 항목별로 확인하세요.
DNS 및 네트워크
allow-lan은 같은 LAN에 있는 다른 기기가 이 기기의 프록시 서비스에 접속하도록 허용할지 설정합니다. 휴대폰이나 다른 컴퓨터의 프록시를 자동으로 구성하지는 않습니다. 실제로 사용하려면 적절한 수신 주소와 방화벽 규칙이 필요하며, 다른 기기에도 이 기기의 LAN 주소와 포트를 올바르게 입력해야 합니다. 신뢰할 수 있는 네트워크에서 필요한 경우에만 켜고, 프록시 포트를 인터넷에 직접 노출하지 마세요.
화면은 조작 기능을 제공하고, 실제 네트워크 동작은 코어와 최종 설정에 따라 결정됩니다.
클라이언트 및 코어
클라이언트는 보통 구독 관리, 정책 선택, 시스템 연동을 담당하고 코어는 프로토콜 연결, 규칙 매칭, DNS 등 네트워크 처리를 담당합니다. 화면이 비슷한 클라이언트라도 내장 코어나 설정 생성 방식이 다를 수 있습니다. 문제를 문의할 때는 클라이언트와 코어 정보를 함께 알려주세요. UI 프로그램만 업데이트해도 실행 중인 코어가 함께 업데이트된다는 보장은 없습니다.
플랫폼별 클라이언트 보기 →클라이언트 및 코어
mihomo는 Clash 생태계의 오픈 소스 코어로, 이전 이름은 Clash.Meta입니다. 프록시 연결, 규칙 기반 라우팅, DNS 등의 기능을 담당합니다. 그래픽 클라이언트에 통합하거나 서버와 라우터에서 독립적으로 실행할 수 있습니다. 설정 항목을 확인할 때는 실제로 실행 중인 코어와 버전을 기준으로 살펴보세요. 다른 코어에서 사용할 수 있는 설정을 현재 환경에 그대로 적용할 수 있는 것은 아닙니다.
클라이언트 및 코어
YAML은 Clash 설정에 자주 쓰이는 데이터 표현 형식으로, 들여쓰기로 계층을 나타내고 하이픈으로 목록 항목을 표시합니다. 탭이 아닌 공백으로 들여쓰고, 설정 조각을 복사할 때는 원본 파일의 계층 구조를 유지하세요. 문법 검사를 통과했다는 것은 파일을 읽을 수 있다는 뜻일 뿐입니다. 항목 이름과 값의 유형이 올바른지, 코어가 지원하는지는 설정을 불러온 뒤 안내 메시지와 함께 확인해야 합니다.
YAML 구조 보기 →클라이언트 및 코어
설정 덮어쓰기는 구독 원본 등에 설정 조각을 병합하거나 스크립트를 적용해 최종 설정을 조정하는 방식입니다. 로컬 DNS, 규칙, 수신 설정 등을 유지할 때 자주 사용합니다. 병합 순서와 목록을 추가하거나 교체하는 방식은 클라이언트마다 다를 수 있습니다. 변경 후에는 원본 구독 파일만 보지 말고 실제 적용된 설정을 확인하세요. 업데이트 때 덮어써지는 파일을 직접 수정하면 변경 사항이 오래 유지되지 않을 수 있습니다.
클라이언트 및 코어
외부 제어 인터페이스는 클라이언트 UI나 대시보드에서 상태를 확인하고 정책을 전환할 때 사용합니다. 로컬 수신 주소는 보통 127.0.0.1:9090 형식입니다. 관리용 인터페이스이며 브라우저의 인터넷 연결에 사용하는 혼합 프록시 포트가 아니므로 용도를 혼동하면 연결에 실패할 수 있습니다. 일반적으로 로컬에서만 접근하도록 설정하세요. 원격 관리가 꼭 필요하다면 인증을 설정하고 접근 가능한 출처를 제한해야 합니다.