클라이언트부터 프로토콜, 규칙, DNS까지 설정에 등장하는 위치를 기준으로 용어를 찾아보세요. 각 항목은 역할과 적용 범위, 흔한 오해를 설명하며 설정 키는 원문 그대로 표기합니다.
UI는 설정을 관리하고 커널은 연결을 처리합니다. 포트, 시스템 프록시, 컨트롤러 인터페이스는 각각 다른 역할을 합니다.
mihomo는 원래 Clash Meta로 불렸던 프록시 커널로, 설정을 읽고 연결을 수립하며 DNS를 처리하고 트래픽 라우팅 규칙을 적용합니다. 지원되는 프로토콜과 설정 필드는 실행 중인 커널 버전을 기준으로 확인해야 하며, 클라이언트 이름만으로 판단할 수 없습니다. 그래픽 클라이언트는 보통 mihomo를 백그라운드 구성 요소로 사용하지만, 서버에서 단독 실행할 수도 있습니다.
커널 관련 문제 해결 →클라이언트는 구독을 가져오고 정책 그룹을 선택하며 로그를 확인하는 UI이고, 커널은 실제 연결을 받아 전달하는 프로그램입니다. 두 구성 요소는 각각 업데이트될 수 있어 클라이언트를 업데이트해도 커널은 그대로일 수 있습니다. 지원되지 않는 필드가 있다면 클라이언트와 커널 버전을 모두 확인한 뒤 UI 제한인지 파싱 기능 문제인지 판단하세요.
플랫폼별 클라이언트 보기 →시스템 프록시는 운영체제의 프록시 설정을 로컬 리슨 주소로 지정해 해당 설정을 따르는 앱의 요청을 커널로 전달합니다. 일부 게임, 명령줄 프로그램, 자체적으로 네트워크 연결을 관리하는 앱은 이 설정을 따르지 않으므로 프록시를 별도로 설정하거나 TUN을 사용해야 합니다. 클라이언트를 종료한 뒤 설정이 복원되지 않으면 앱이 더 이상 리슨하지 않는 포트에 계속 접속할 수 있습니다.
혼합 포트는 하나의 리슨 포트에서 HTTP 프록시와 SOCKS5 요청을 모두 받아 앱에서 공통으로 사용할 수 있는 접점을 제공합니다. 흔히 쓰는 설정 예시는 mixed-port: 7890이지만, 실제 포트는 현재 설정을 확인하세요. 프록시 주소를 입력할 때는 리슨 주소와 접근 범위도 확인해야 합니다. 다른 프로세스가 포트를 사용 중이면 시작이나 연결에 실패할 수 있습니다.
외부 컨트롤러는 대시보드에서 연결 상태를 조회하거나 프록시 그룹을 전환하는 등 관리 기능을 제공합니다. 앱 트래픽을 전달하는 프록시 접점은 아닙니다. 컨트롤러 포트를 브라우저의 프록시 설정에 입력해도 혼합 포트를 대신할 수 없습니다. 다른 기기에서 접속해야 한다면 인증을 설정하고 접근 가능한 출처를 제한해 관리 기능이 인터넷에 그대로 노출되지 않도록 하세요.
프로토콜은 클라이언트와 프록시 서버가 통신하는 방식을 정의합니다. 프로토콜 이름만 같다고 충분한 것은 아니며 인증, 전송 방식, 인증서 매개변수도 일치해야 합니다.
Shadowsocks는 암호화 프록시 프로토콜로, 노드 설정에는 보통 서버 주소, 포트, 비밀번호, 암호화 방식이 포함됩니다. 클라이언트와 서버의 암호화 방식이 호환되어야 하며 비밀번호나 포트가 잘못되면 시간 초과가 발생할 수 있습니다. 노드에서 플러그인을 사용한다면 플러그인 매개변수도 맞춰야 합니다. UDP 지원 여부는 양측 구현과 네트워크 환경에 따라 달라집니다.
VMess와 VLESS는 서로 다른 프록시 프로토콜이며, 하나의 노드에서 서로 바꿔 쓸 수 있는 두 가지 표기가 아닙니다. 인증 정보 외에도 WebSocket, gRPC, TLS 등의 전송 및 보안 설정이 필요할 수 있으므로 서버 설정과 하나씩 맞춰야 합니다. type만 다른 프로토콜로 바꿔서는 변환되지 않으며, 구형 커널은 새 필드를 인식하지 못할 수도 있습니다.
Trojan은 일반적으로 TLS로 연결을 보호하고 비밀번호로 인증합니다. 연결에 실패하면 서버 주소와 비밀번호뿐 아니라 서버 이름, 인증서 유효성, 기기의 시스템 시간도 확인하세요. 지원하는 전송 방식은 구현에 따라 다르므로 프로토콜 이름만 보고 현재 커널이 모든 추가 매개변수를 지원한다고 판단해서는 안 됩니다.
Hysteria2는 QUIC 기반 프록시 프로토콜로, 네트워크에서 UDP 통신이 허용되어야 합니다. 사용 가능 여부는 커널 지원뿐 아니라 인증, 인증서, 네트워크의 UDP 정책에도 영향을 받습니다. 다른 프로토콜로 바꿔 비교 테스트할 수는 있지만, 특정 프로토콜이 모든 네트워크에서 더 빠르다고 단정할 수는 없습니다. 지속적인 처리량은 실제 사용 환경에서 확인하세요.
TLS는 연결을 보호하고 상대의 신원을 확인하며, SNI는 핸드셰이크 중 서버에 요청 대상 이름을 알립니다. 설정의 서버 주소와 인증서 이름은 서로 다를 수 있으므로 노드 제공업체가 안내한 값에 따라 관련 필드를 입력하세요. 인증서 오류가 발생하면 이름, 시스템 시간, 인증서 상태를 먼저 확인하고, 인증서 검증을 건너뛰는 방법은 장기적인 해결책으로 사용하지 않는 것이 좋습니다.
규칙은 연결을 어디로 보낼지 결정하고, 프록시 그룹은 어떤 구성원을 사용할지 정합니다. 규칙 목록의 순서에 따라 결과가 달라집니다.
규칙 모드는 rules 목록을 위에서 아래로 확인하고, 일치하는 항목에 지정된 정책을 적용합니다. 도메인 규칙, IP 규칙, 룰셋을 함께 사용할 수 있지만 일반적으로 구체적인 규칙을 포괄적인 규칙보다 앞에 배치해야 합니다. 마지막의 MATCH,PROXY는 앞선 규칙에 일치하지 않는 트래픽을 처리합니다. 단, 설정에 PROXY라는 이름의 정책 그룹이 정의되어 있어야 합니다.
DIRECT는 기본 제공 직접 연결 정책이고, REJECT는 기본 제공 거부 정책입니다. PROXY는 보통 설정 작성자가 프록시 그룹에 붙인 이름일 뿐, 기본 제공 그룹이라고 보장되지 않습니다. 규칙 끝에는 DOMAIN-SUFFIX,example.com,PROXY처럼 실제 그룹 이름을 지정할 수 있습니다. 직접 연결은 프록시 노드를 거치지 않는다는 뜻이지, 로컬 커널의 모든 처리 과정을 우회한다는 뜻은 아닙니다.
프록시 그룹은 노드나 다른 정책 그룹을 묶어 규칙에서 대상으로 지정할 수 있게 합니다. select는 수동 선택, url-test는 테스트 결과에 따른 구성원 선택, fallback은 구성원 순서대로 연결 가능한 항목을 찾을 때 사용합니다. 자동 정책은 지정된 테스트 대상에서의 결과를 기준으로 하므로 모든 사이트에서 똑같이 작동한다고 보장할 수 없으며, 테스트 결과를 다운로드 속도 순위로 간주해서도 안 됩니다.
GEOIP는 IP 데이터베이스를 기준으로 분류하고, GEOSITE는 도메인 목록을 기준으로 분류하므로 매칭 대상이 다릅니다. GEOIP,CN,DIRECT를 사용하려면 IP 데이터가 있어야 하며, 분류 결과는 데이터베이스 업데이트 상태에도 영향을 받습니다. IP의 지역 정보만으로 웹사이트의 용도나 접속 목적을 모두 판단할 수는 없습니다. 중요한 서비스에는 지역 분류에만 의존하지 말고 명시적인 도메인 규칙을 함께 사용하세요.
룰셋은 여러 규칙을 별도로 관리할 수 있는 데이터 소스로 분리해 rule-providers로 선언한 다음, RULE-SET으로 규칙 목록에 가져옵니다. 데이터 형식은 behavior와 일치해야 합니다. 예를 들어 도메인 목록을 완전한 규칙 행으로 임의 해석할 수 없습니다. 룰셋 업데이트는 기본 구독 업데이트와 별도로 진행되며, 참조 위치도 전체 규칙 순서에 영향을 줍니다. 업데이트에 실패하면 로컬 캐시와 로그도 확인하세요.
도메인 조회, 연결 가로채기, 네트워크 라우팅은 서로 다른 계층에서 작동합니다. 한 가지 옵션을 켰다고 나머지 계층까지 설정된 것은 아닙니다.
DNS는 도메인 이름을 네트워크 주소로 변환하며, 커널은 설정에 따라 요청을 받아 상위 리졸버를 선택할 수 있습니다. 시스템 DNS, 브라우저의 암호화 DNS, 커널 DNS가 동시에 사용될 수 있으므로 한 곳을 변경해도 다른 경로에는 영향을 주지 않을 수 있습니다. 문제를 확인할 때는 먼저 실제 요청을 누가 보내고 어디서 처리하는지 파악한 다음 상위 리졸버에 연결할 수 있는지 확인하세요. DNS 오류를 노드 문제로 오인하지 않도록 주의해야 합니다.
Fake-IP는 도메인에 매핑 주소를 할당해 커널이 이후 연결에서도 도메인 정보를 유지하도록 하며, 이를 통해 도메인 기반 라우팅을 적용하기 쉬워집니다. 이 주소는 웹사이트의 실제 IP가 아니므로 서버 위치를 판단하는 데 사용할 수 없습니다. 로컬 네트워크 서비스나 실제 DNS 응답에 의존하는 앱에서는 필요에 따라 fake-ip-filter를 설정하세요. 변경 후에는 앱과 시스템에 남아 있는 이전 DNS 캐시도 정리해야 합니다.
TUN은 가상 네트워크 인터페이스를 통해 IP 트래픽을 커널로 전달하므로 시스템 프록시 설정을 따르지 않는 앱을 처리할 때 유용합니다. 실제 적용 범위는 라우팅, 제외 항목, 권한, 클라이언트 구현에 따라 달라지며, 활성화해도 모든 트래픽이 프록시 노드를 거치는 것은 아닙니다. 연결의 출구는 현재 모드와 규칙에 따라 결정됩니다. 다른 VPN과 함께 실행한다면 라우팅이나 DNS 가로채기가 충돌하지 않는지 확인하세요.
DNS 누수는 요청이 예상과 다른 출구나 리졸버를 통해 전송되는 현상입니다. 판단하기 전에 어떤 DNS 경로를 기대하는지 먼저 확인해야 합니다. 주요 점검 항목은 시스템 DNS, 앱 내장 암호화 DNS, IPv6 라우팅, 커널의 DNS 가로채기 설정입니다. 테스트 페이지에 표시된 리졸버 이름은 단서일 뿐 전체 트래픽 경로를 단독으로 판단할 근거는 아닙니다. 로그와 네트워크 설정을 함께 살펴보고 반복 테스트로 확인하세요.
DNS 문제 해결 보기 →IPv6는 IPv4와 함께 사용되는 네트워크 프로토콜이며, DNS의 AAAA 레코드는 IPv6 주소를 반환합니다. 시스템에 IPv6 경로가 있다고 해서 프록시 노드나 커널이 같은 경로를 지원한다는 뜻은 아닙니다. 일부 사이트가 직접 연결되거나 시간 초과되는 경우 DNS 응답, 시스템 라우팅, 프록시 처리 기능을 각각 확인하세요. IPv6를 잠시 끄고 비교해볼 수는 있지만 실제 원인을 찾는 절차를 대신할 수는 없습니다.
구독은 설정을 가져오는 출처이고, 노드는 연결 매개변수이며, 설정 파일은 전체 동작을 결정합니다. 로컬에서 수정할 때는 업데이트로 덮어써지는지와 병합 순서도 고려해야 합니다.
구독은 노드 목록이나 전체 설정을 가져오는 원격 소스이며 클라이언트나 프록시 커널과는 다릅니다. 제공되는 내용은 노드만 포함할 수도 있고 규칙과 프록시 그룹까지 포함할 수도 있으므로, 가져온 뒤 현재 클라이언트의 형식에 맞는지 확인하세요. 링크에 계정 정보가 포함될 수 있으니 공유할 때는 로그와 스크린샷에서 가려야 합니다. 로컬 변경 사항은 다음 구독 업데이트에서 덮어써질 수 있습니다.
구독 가져오기 단계 보기 →노드는 프록시 연결에 필요한 서버, 프로토콜, 포트, 인증 매개변수를 나타내며 보통 구독 제공업체가 관리합니다. 노드 이름은 단순한 라벨이므로 지역 표시나 회선 이름만으로 실제 출구, 프로토콜 기능, 안정성을 확인할 수 없습니다. 노드를 선택할 때는 목록의 이름만 보지 말고 대상 서비스 접속 가능 여부, 지속적인 전송 성능, 계정 요금 정책을 함께 고려하세요.
클라이언트에 표시되는 지연 시간은 일반적으로 지정된 테스트 요청을 완료하는 데 걸리는 시간이며, 측정에 포함되는 단계는 구현과 테스트 방식에 따라 다릅니다. 수치가 낮다고 다운로드 대역폭이 높은 것은 아니며, 시간 초과가 발생해도 테스트 대상에 접속할 수 없는 경우일 수 있습니다. 테스트 주소, 네트워크 환경, 시간 조건이 비슷할 때만 비교하고, 실제 사이트 접속과 지속적인 데이터 전송으로 노드 품질을 확인하세요.
YAML은 널리 쓰이는 설정 형식이고 config.yaml은 일반적인 파일 이름이지 별도의 설정 프로토콜이 아닙니다. 계층은 공백 들여쓰기로 표현하고 목록 항목은 보통 하이픈으로 시작합니다. 탭 문자나 잘못된 들여쓰기는 파싱 오류를 일으킬 수 있습니다. 문법이 올바르더라도 현재 커널이 해당 필드를 지원한다는 뜻은 아닙니다. 수정 전에 정상 작동하는 사본을 저장하고 클라이언트 로그에서 로드 결과를 확인하세요.
설정 오버라이드는 구독 설정에 로컬 설정을 추가하거나 수정하는 방식으로, 사용자 지정 규칙, DNS, 포트를 저장할 때 사용할 수 있습니다. 목록 추가, 필드 교체, 적용 순서는 클라이언트마다 다르므로 한 클라이언트의 오버라이드 파일을 범용 표준처럼 사용할 수 없습니다. 수정 후 실제 적용된 설정을 확인해 규칙 위치와 그룹 참조가 올바른지 살펴보고 원본 구독과 오버라이드 내용을 백업하세요.