mihomo
프록시 커널프록시 프로토콜 처리, DNS, 규칙 매칭, 연결 전달을 담당하는 핵심 프로그램입니다. Clash Nyanpasu는 설정 관리와 그래픽 인터페이스를 제공합니다. 인터페이스에 특정 설정 항목이 보여도 현재 실행 중인 커널이 해당 필드를 지원한다는 뜻은 아니므로 커널 기능을 확인해야 합니다. 문제를 진단할 때는 클라이언트 버전, 커널 종류, 실제 적용 설정을 각각 기록하고 클라이언트 이름만으로 동작을 판단하지 마세요.
REFERENCE / CLASH TERMINOLOGY
인터페이스에서 쓰는 이름으로 관련 설정 개념을 찾아보세요. 커널, 필드, 규칙, 네트워크, 클라이언트의 다섯 범주에서 설정 출처, 실행 매개변수, 요청 처리 경로를 구분할 수 있습니다.
처음 설정한다면 빠른 시작 가이드를 먼저 읽어 보세요. 전체 필드와 YAML 예제가 필요하다면 YAML 가이드를 확인하세요. 이 페이지는 개념 간 차이를 설명하며, 특정 스위치의 상태를 실제 연결 결과와 동일시하지 않습니다.
TERMS / 01
클라이언트는 설정 관리와 인터페이스 조작을 담당하고, 커널은 네트워크 로직을 실행합니다. 앱이 로컬 프록시에 연결할 때 쓰는 프로토콜과 노드가 원격 서버에 연결할 때 쓰는 프로토콜은 서로 다를 수 있습니다.
프록시 프로토콜 처리, DNS, 규칙 매칭, 연결 전달을 담당하는 핵심 프로그램입니다. Clash Nyanpasu는 설정 관리와 그래픽 인터페이스를 제공합니다. 인터페이스에 특정 설정 항목이 보여도 현재 실행 중인 커널이 해당 필드를 지원한다는 뜻은 아니므로 커널 기능을 확인해야 합니다. 문제를 진단할 때는 클라이언트 버전, 커널 종류, 실제 적용 설정을 각각 기록하고 클라이언트 이름만으로 동작을 판단하지 마세요.
노드 설정 하나에는 원격 서버 주소, 포트, 프로토콜, 인증 매개변수가 포함되며, 보통 proxies 또는 프록시 모음에 정의됩니다. 노드는 구독과 다릅니다. 전자는 연결 정보를, 후자는 설정 배포 방식을 가리킵니다. 노드를 가져와도 요청은 모드, 규칙, 프록시 그룹을 거쳐 출구가 선택됩니다. 노드가 있다는 이유만으로 트래픽이 해당 출구를 통과한다고 볼 수 없습니다.
앱이 프록시 인터페이스에 직접 연결해 요청을 전달하거나 CONNECT로 터널을 만듭니다. 여기서 HTTP는 앱과 로컬 프록시의 상호작용 방식을 뜻하며, 원격 노드가 웹 트래픽만 처리한다거나 전체 연결이 평문으로 전송된다는 의미는 아닙니다. 앱을 설정할 때는 실제 로컬 수신 주소와 포트를 입력하세요. HTTPS 대상의 인증서는 보통 앱에서 검증합니다.
앱은 SOCKS5를 통해 프록시에 목적지 주소를 전달하고 연결을 설정합니다. 이 프로토콜은 TCP를 지원하며 UDP 전달 방식도 정의합니다. 실제 UDP 사용에는 앱, 프록시 인터페이스, 이후 연결 경로 모두의 지원이 필요합니다. 도메인 조회 위치는 앱이 도메인을 전달하는지 이미 조회된 IP를 전달하는지에 따라 달라지므로, 프록시 유형만 보고 DNS 경로를 단정할 수 없습니다.
TLS는 상대방 인증, 전송 암호화, 무결성 보호를 제공하며 웹 연결에 쓰거나 프록시 프로토콜의 전송 계층을 보호하는 데 사용할 수 있습니다. 핸드셰이크에 실패하면 인증서, 서버 이름, 시스템 시간, 연결 경로를 확인하세요. 인증서 검증을 건너뛰면 신원 확인이 약해집니다. 검증을 끄는 것을 상시 설정으로 삼기보다 인증서나 이름이 일치하지 않는 원인을 먼저 찾아야 합니다.
TERMS / 02
필드 이름, 계층, 데이터 유형에 따라 설정의 의미가 결정됩니다. 예제를 볼 때는 필드가 최상위, DNS 설정, 노드 정의, 프록시 그룹 중 어디에 있는지 먼저 확인하세요.
YAML은 들여쓰기로 맵과 목록을 표현하며, Clash 설정 파일은 보통 .yaml 또는 .yml 확장자로 저장합니다. 들여쓰기에는 공백을 사용하고 같은 계층의 필드를 정렬하며, 목록 항목은 하이픈으로 시작합니다. 문법 분석에 성공해도 구조를 읽을 수 있다는 뜻일 뿐입니다. 필드 인식 여부, 값의 유효성, 참조 대상의 존재 여부는 실제 실행 커널에서 확인해야 합니다.
이 필드를 사용하면 HTTP와 SOCKS 프록시 인터페이스가 하나의 로컬 수신 포트를 공유해 여러 앱에서 같은 서비스를 이용할 수 있습니다. 원격 노드의 port와는 의미가 다르며 모든 앱의 프록시 설정을 자동으로 바꾸지도 않습니다. 시작할 때 포트가 사용 중이라는 오류가 나면 먼저 해당 포트를 쓰는 프로세스를 확인하세요. 수신 포트를 변경했다면 그 포트를 사용하는 시스템이나 앱 설정도 함께 바꿔야 합니다.
공통 필드 mode는 요청을 규칙, 전역, 직접 연결 중 어떤 방식으로 처리할지 결정합니다. 규칙 모드는 rules에 따라 정책을 선택하고, 전역 모드는 전역 정책을 사용하며, 직접 연결 모드는 목적지에 바로 연결합니다. 모드는 커널에 들어온 뒤의 처리 로직을 정하고, 시스템 프록시와 TUN은 요청이 커널에 들어오는 방식을 정합니다. 따라서 전역 모드로 바꿔도 모든 앱의 트래픽이 자동으로 처리되는 것은 아닙니다.
이 DNS 모드에서는 커널이 앱에 합성 주소를 반환하고 해당 주소와 원래 도메인의 매핑을 관리해 이후 연결을 도메인 기준으로 처리합니다. 합성 주소는 대상 웹사이트의 실제 공인 IP가 아닙니다. 실제 DNS 응답에 의존하는 일부 앱에는 필터 설정이 필요할 수 있습니다. 설정을 바꾼 뒤에는 시스템, 브라우저, 앱 캐시도 고려해 이전 결과가 판단을 방해하지 않도록 하세요.
이 필드는 재사용할 프록시 모음의 출처를 정의하며, 프록시 그룹에서 use로 이름을 참조합니다. 프록시 모음과 전체 Profile은 용도가 다르므로 모음 파일에 DNS, 규칙, 공통 수신 필드까지 모두 들어 있다고 가정하면 안 됩니다. 업데이트에 실패하면 출처 형식, 가져오기 경로, 프록시 그룹의 참조를 각각 확인한 다음 모음의 내용이 최종 실행 설정에 반영됐는지 살펴보세요.
TERMS / 03
규칙은 사용할 정책을 정하고, 프록시 그룹은 출구 선택 방식을 정합니다. 요청 경로를 진단할 때는 일치한 규칙, 대상 정책, 최종 출구를 차례로 확인하세요.
규칙 기반 라우팅은 도메인, IP 또는 기타 요청 속성에 따라 직접 연결, 차단, 프록시 정책 중 하나를 선택합니다. 규칙은 보통 위에서 아래로 확인하며, 처음 일치한 규칙의 대상을 사용하고 같은 요청에 대해 뒤의 규칙을 다시 적용하지 않습니다. 구체적인 조건은 포괄적인 조건보다 앞에 두는 것이 일반적입니다. 규칙을 수정한 뒤에는 페이지가 열리는지만 보지 말고 새 연결의 규칙 매칭 기록으로 확인하세요.
프록시 그룹은 노드, 다른 프록시 그룹, 내장 정책을 묶어 규칙에서 참조할 수 있는 대상으로 만듭니다. select는 주로 수동 선택, url-test는 테스트 결과에 따른 자동 선택, fallback은 순서대로 가용성을 확인하고 전환하는 데 사용합니다. 이름이 같아도 동작은 다를 수 있으므로 그룹 유형, 구성원 출처, 중첩 참조가 순환하는지 확인해야 합니다.
GeoIP는 로컬 데이터베이스를 바탕으로 IP 주소의 지역을 표시하며 GEOIP 등의 규칙 매칭에 사용됩니다. 데이터베이스의 지역 정보는 접속자의 위치와 다를 수 있고 웹사이트 콘텐츠나 법적 관할 범위를 정확히 나타내지도 않습니다. 데이터베이스 업데이트, 콘텐츠 전송 네트워크, 공유 인프라에 따라 결과가 달라질 수 있습니다. 요청에 도메인만 있는 경우 일부 IP 규칙은 DNS 조회를 유발할 수도 있습니다.
RULE-SET은 규칙 시퀀스에서 rule-providers가 정의한 모음을 참조해 긴 규칙 목록을 별도로 관리할 수 있게 합니다. 모음의 동작 유형과 파일 형식은 provider 선언과 일치해야 합니다. 도메인 목록과 전체 규칙 목록을 그대로 섞어 쓸 수는 없습니다. 외부 파일로 분리해도 주 규칙에서의 위치는 우선순위에 영향을 주며, 처음 일치한 규칙이 적용되는 순서도 달라지지 않습니다.
MATCH는 조건 없이 일치하는 규칙으로, 보통 rules의 마지막에 두어 앞서 매칭되지 않은 요청에 기본 정책을 지정합니다. 앞에 두면 뒤의 규칙은 요청을 처리할 기회가 없습니다. 대상은 프록시 그룹이나 내장 정책일 수 있지만 유효한 참조인지 확인해야 합니다. 기본 정책을 직접 연결로 할지 프록시로 할지는 설정 목적에 맞게 정하세요.
TERMS / 04
트래픽 처리, 도메인 조회, 출구 선택은 서로 다른 단계입니다. 스위치가 켜져 있어도 설정 상태만 확인된 것이므로 실제 경로는 연결 기록과 시스템 네트워크 설정을 함께 살펴봐야 합니다.
시스템 프록시는 운영체제 설정에 로컬 프록시 주소를 등록해 해당 설정을 따르는 앱의 요청을 클라이언트로 전달합니다. 자체 네트워크 스택을 사용하는 프로그램, 일부 명령줄 도구, 별도 프록시를 설정한 앱은 이 경로를 따르지 않을 수 있습니다. 클라이언트를 종료한 뒤에도 인터넷에 연결되지 않는다면 시스템에 작동하지 않는 프록시 주소가 남아 있는지 확인하고, 프록시 설정 문제와 네트워크 자체 문제를 구분하세요.
TUN은 가상 네트워크 인터페이스와 라우팅 설정을 사용해 조건에 맞는 네트워크 트래픽을 커널로 전달합니다. 시스템 프록시를 따르지 않는 앱에 주로 사용됩니다. 추가 시스템 권한이 필요한 경우가 많고, 실제 처리 범위는 라우팅 제외 항목, 프로토콜 지원, 네트워크 환경에 따라 달라집니다. TUN을 켠 뒤에도 DNS와 규칙을 확인해야 하며, 모든 네트워크 문제를 자동으로 해결하는 기능은 아닙니다.
DNS 누수는 조회가 예상한 경로를 통하지 않고 다른 리졸버에 전달되는 현상입니다. 문제가 되는지는 미리 정한 개인정보 보호 및 트래픽 분기 목표에 따라 달라집니다. 브라우저의 보안 DNS, 앱 내장 조회, 시스템 DNS는 각각 별도의 경로를 사용할 수 있습니다. 암호화 DNS는 조회 전송이 보호된다는 뜻일 뿐, 예상한 프록시 출구를 통과한다는 보장은 아닙니다. DNS 정책과 라우팅을 함께 확인해야 합니다.
allow-lan은 LAN 기기가 프록시 수신 서비스에 접근하도록 허용할지 제어하지만, 실제 접근 가능 여부는 바인딩 주소, 방화벽, 무선 네트워크 격리에도 달려 있습니다. 다른 기기에서는 클라이언트를 실행 중인 기기의 LAN 주소를 입력해야 하며, 해당 기기 자신의 루프백 주소를 입력하면 안 됩니다. 접근을 허용하기 전에 범위를 정하고 적절한 인증이나 접근 제어를 설정해 프록시 인터페이스가 불필요하게 노출되지 않도록 하세요.
인터페이스에 표시되는 연결 지연 시간은 보통 특정 테스트 주소에 요청을 보내 측정하며, DNS, 핸드셰이크, 대상 서버 응답, 현재 네트워크 상태에 영향을 받습니다. 파일 다운로드 속도와는 다르고 모든 웹사이트의 접속 상태를 나타내지도 않습니다. 비교할 때는 같은 대상과 테스트 방식을 사용하세요. 한 번의 테스트가 실패하면 로그를 확인해 테스트 사이트 연결 불가, 인증 실패, 연결 경로 문제를 구분해야 합니다.
TERMS / 05
인터페이스에 표시되는 설정 기록이 디스크의 최종 실행 파일과 항상 일치하는 것은 아닙니다. 구독 업데이트 후 설정이 초기화되거나 설정을 전환해도 반영되지 않는다면 먼저 설정 출처와 생성 과정을 확인하세요.
Profile은 클라이언트가 관리하는 로컬 설정 또는 원격 설정 기록으로, 보통 이름, 출처, 업데이트 설정 등을 포함합니다. Profile을 전환하면 설정 출처가 바뀌지만 최종 내용에는 클라이언트의 덮어쓰기 및 병합 설정이 반영될 수 있습니다. 백업할 때는 원본 파일, 원격 출처 기록, 덮어쓰기 내용을 구분하세요. 생성된 실행 파일 하나만 복사해서는 기존 관리 방식을 복원하지 못할 수도 있습니다.
구독은 URL을 통해 설정이나 노드 모음을 배포하고 업데이트합니다. 응답은 Clash YAML일 수도 있고 다른 클라이언트 형식일 수도 있습니다. 링크에 접속할 수 있다고 해서 현재 클라이언트가 내용을 바로 해석할 수 있는 것은 아니므로 가져오기 전에 형식과 용도를 확인하세요. 구독 주소에는 접근 자격 정보가 포함되는 경우가 많으므로 민감 정보로 취급해야 합니다. 문제를 진단하거나 화면을 공유할 때는 전체 URL을 가려 출처 정보가 공개되지 않도록 하세요.
덮어쓰기는 원본 설정의 필드를 조정하는 작업이고, 병합은 여러 설정 계층을 합쳐 최종 실행 설정을 만드는 과정입니다. 로컬 DNS, 수신 포트, 규칙 설정을 유지할 때 주로 사용합니다. 스칼라 값 덮어쓰기, 맵 병합, 목록 교체 방식은 클라이언트 구현에 따라 다르므로 모든 목록이 추가된다고 가정하면 안 됩니다. 수정한 뒤에는 최종 설정을 확인하세요. 임시 생성 파일을 직접 편집하면 다음 업데이트나 전환 때 다시 생성될 수 있습니다.
연결 보기에서는 요청 대상, 일치한 규칙, 출구 경로를 확인해 앱의 요청이 커널에 들어왔는지, 규칙이 예상대로 실행됐는지 파악할 수 있습니다. 정책 전환은 보통 새 연결부터 적용되며 기존 장시간 연결은 이전 경로를 계속 사용할 수 있습니다. 변경 사항을 확인할 때는 요청을 새로 보내거나 영향 여부를 확인한 후 관련 연결을 종료하고, 도메인 및 규칙 기록을 함께 살펴보세요. 접속 결과만으로 추측할 필요는 없습니다.
log-level은 출력 상세도를 조절하며 일반적인 값은 info, warning, error, debug입니다. 시작 메시지가 곧 오류를 뜻하는 것은 아니며, 한 번의 연결 오류만으로 전체 설정이 잘못됐다고 볼 수도 없습니다. 발생 시점과 대상 요청을 함께 확인하세요. 진단 중 상세도를 일시적으로 높였다면 로그에 접속 도메인이나 경로가 포함될 수 있으니 공유 전에 민감한 정보를 삭제하고, 진단이 끝나면 평소 수준으로 되돌리세요.