Mihomo 자주 묻는 질문

Mihomo는 프록시 연결, DNS, 규칙 매칭을 처리하는 코어이고, GUI 클라이언트는 설정 가져오기, 프록시 그룹 선택, 시스템 프록시 설정 등의 기능을 제공합니다. 같은 코어를 사용하더라도 클라이언트마다 메뉴 이름, 권한 요청, 설정 병합 방식이 다를 수 있습니다. 안내를 참고하기 전에 클라이언트 이름을 확인하고, 설정 화면이나 로그에서 코어 정보를 살펴보세요. 설정 항목을 인식하지 못한다면 실제 코어 버전에 맞는 문서를 확인해야 합니다. 창 모양만으로 기능 지원 여부를 판단할 수는 없습니다. 일반적인 데스크톱 사용자는 GUI 클라이언트를 주로 사용하며, 코어 패키지는 명령줄, 서버, 라우터 배포에 적합합니다.

클라이언트는 설정을 실행할 뿐, 사용할 수 있는 원격 프록시 서비스를 자동으로 제공하지는 않습니다. 구독 링크는 보통 서비스 제공업체가 발급하며 노드, 프록시 그룹, 규칙 등을 가져오는 데 사용됩니다. 이러한 설정은 로컬 YAML 파일에 담을 수도 있습니다. 가져오기 전에 설정이 Mihomo와 호환되는지 확인하세요. 서비스 업체의 웹사이트 주소나 로그인 페이지는 구독 주소가 아닙니다. 구독 링크에는 인증 정보가 포함될 수 있으므로 계정 정보처럼 안전하게 관리하고, 공개 스크린샷이나 단체 채팅, 코드 저장소에 올리지 마세요. 링크가 유출됐다면 제공업체 사이트에서 재발급한 뒤 각 기기에 저장된 주소도 업데이트하세요.

규칙 모드는 설정된 규칙 순서에 따라 요청을 직접 연결하거나 프록시 그룹 등 적절한 정책으로 보내므로 일상적인 트래픽 분산에 적합합니다. 전역 모드는 코어로 전달된 요청에 전역 정책을 적용하므로 규칙이 접속에 영향을 주는지 잠시 비교할 때 유용합니다. 직접 연결 모드에서는 해당 요청이 대상에 바로 연결됩니다. 모드는 코어가 요청을 받은 뒤 처리하는 방식을 정할 뿐, 모든 앱의 트래픽이 코어로 전달된다는 뜻은 아닙니다. 시스템 프록시와 TUN은 트래픽을 코어로 전달하는 방식을 결정합니다. 문제를 확인할 때는 잠시 전역 모드로 바꾸고 사용 가능한 노드를 선택해 테스트한 뒤, 테스트가 끝나면 규칙 모드로 되돌리세요.

UDP 전달 가능 여부는 전체 연결 경로에 달려 있습니다. 앱 트래픽이 코어로 들어오는지, 노드 설정에서 UDP가 활성화됐는지, 프록시 프로토콜과 서버가 UDP를 지원하는지, 네트워크에서 관련 패킷을 허용하는지 모두 확인해야 합니다. 클라이언트에 노드가 사용 가능하다고 표시되거나 웹페이지가 열린다고 해서 UDP 연결까지 확인된 것은 아닙니다. 게임과 통화는 DNS, 직접 연결 정책, NAT 환경의 영향도 받을 수 있습니다. 먼저 앱의 트래픽 전달 방식을 확인하고, 적용된 프록시 그룹과 노드를 살펴본 뒤 실제 앱에서 테스트하세요. UDP 옵션만 켜서는 서버가 지원하지 않는 기능을 보완할 수 없습니다.

먼저 업데이트 로그에서 HTTP 상태 코드와 오류 내용을 확인하세요. 401은 인증 정보가 없거나 만료된 경우가 많고, 403은 접근 제한, 요금제 상태 또는 서버 정책 때문일 수 있으므로 제공업체 안내도 확인해야 합니다. 제공업체 사이트에서 구독 주소 전체를 다시 복사하고, 쿼리 매개변수가 누락되거나 공백이 섞이지 않았는지, 웹페이지 주소를 복사한 것은 아닌지 확인하세요. 주소에 접속할 수 있는데 가져오기 중 YAML 오류가 발생한다면 응답 내용이 로그인 페이지나 오류 안내 페이지인지 살펴보세요. 다운로드 실패와 설정 파싱 오류를 구분해 처리하고, 현재 사용할 수 있는 설정을 반복해서 삭제하지 마세요. 기존 설정은 임시 복구용으로 남겨둘 수 있습니다.

TUN은 가상 네트워크 인터페이스를 만들고 라우팅을 변경하므로 일반적으로 시스템 프록시보다 높은 권한이 필요합니다. Windows에서는 클라이언트의 서비스 모드가 설치되어 실행 중인지 확인하고, 안내에 따라 관리자 권한을 부여하세요. 라우팅을 제어하는 프록시 도구를 여러 개 동시에 실행하지 마세요. macOS에서는 사용 중인 클라이언트의 안내에 따라 시스템 권한이나 보조 서비스를 확인해야 합니다. 모든 팝업을 같은 종류의 네트워크 확장 요청으로 보면 안 됩니다. 권한을 부여한 뒤 TUN을 다시 켜고, 로그에서 처음 실패한 항목을 확인하세요. 인터페이스를 만들지 못한다면 TUN을 끄고 시스템 프록시가 작동하는지 먼저 확인한 다음 권한, 드라이버, 라우팅 문제를 각각 점검하세요.

기기 연식으로 짐작하지 말고 운영체제에서 제공하는 하드웨어 정보를 확인하세요. Windows에서는 설정의 시스템 정보에서 시스템 종류를 확인할 수 있습니다. 일반적인 Intel 또는 AMD PC는 x64를 사용하며, ARM 기기는 클라이언트에서 호환 설치 파일을 제공하는지 확인해야 합니다. macOS에서는 이 Mac에 관하여에서 Apple 칩과 Intel 프로세서를 구분해 해당 아키텍처를 선택하세요. 아키텍처가 맞지 않으면 실행되지 않거나 운영체제의 변환 지원이 필요할 수 있습니다. 업데이트 전에 설정을 백업하고 실행 중인 이전 버전은 종료하세요. 설치 프로그램에서 운영체제 버전이 지원되지 않는다고 안내하면 같은 설치를 반복하지 말고 클라이언트의 릴리스 정보를 확인하세요.

Android 클라이언트는 보통 VpnService를 통해 기기 트래픽을 전달하며, 처음 연결할 때 시스템 VPN 권한을 승인해야 합니다. 이 권한은 로컬 VPN 인터페이스를 만들도록 허용하는 것으로, 서버 노드가 사용 가능하다는 뜻은 아닙니다. 일반적으로 한 사용자 환경에서는 활성 VPN 하나만 사용할 수 있으므로 다른 VPN 도구를 실행하면 현재 연결이 끊길 수 있습니다. 백그라운드에서 연결이 끊긴다면 시스템이 배터리 사용, 백그라운드 활동 또는 자동 실행을 제한하는지 확인하고, 기기 설정에서 클라이언트 실행을 허용하세요. 앱 프로세스가 종료된 경우와 노드 연결에 실패한 경우도 구분해야 합니다. 전자는 보통 알림이 사라지고, 후자는 로그와 구독 상태를 추가로 확인해야 합니다.

시스템 프록시는 시스템 설정을 따르는 앱에 프록시 주소를 제공할 뿐, 모든 네트워크 연결을 강제로 가로채지는 않습니다. 먼저 시스템 설정의 주소와 포트가 클라이언트의 실제 수신 주소와 일치하는지 확인한 뒤, 앱 자체 프록시나 브라우저 확장 프로그램, 환경 변수, 별도 네트워크 설정을 사용하는지 살펴보세요. 테스트할 때 클라이언트의 연결 목록을 열어 새 요청이 표시되는지 확인하세요. 기록이 없다면 분할 규칙을 바꾸기보다 먼저 트래픽 전달 문제를 해결해야 합니다. 시스템 프록시를 따르지 않는 앱에는 필요에 따라 앱 자체 프록시나 TUN을 설정할 수 있습니다. 전달 방식을 바꿀 때는 충돌하는 설정을 먼저 끄세요. 여러 프록시를 겹쳐 사용하면 연결 경로를 파악하기 어려워집니다.

AppContainer 네트워크 격리의 영향을 받는 일부 Windows 앱은 로컬 루프백 프록시에 직접 접근할 수 없습니다. 따라서 브라우저가 정상 작동해도 해당 앱의 연결까지 보장되는 것은 아닙니다. 먼저 앱이 실제로 이 제한의 영향을 받는지 확인한 뒤, 클라이언트에서 제공하는 루프백 예외 도구나 Windows의 CheckNetIsolation 도구로 해당 앱의 예외를 확인하고 관리하세요. 필요한 앱에만 권한을 부여하고 모든 앱을 일괄 허용하지 마세요. 설정을 변경한 뒤 대상 앱을 다시 시작하고 연결 기록을 확인하세요. 루프백 예외는 로컬 프록시 접근 제한만 해결합니다. 구독 오류, DNS 오류, 원격 노드 시간 초과는 해결하지 못하며, 모든 스토어 앱에 필요한 설정도 아닙니다.

일반적인 지연 시간 테스트는 지정된 테스트 주소에 접속하는 데 걸리는 시간을 측정하며, 지속적인 다운로드 대역폭을 나타내지는 않습니다. 테스트 대상, 시간 초과 기준, 캐시, 노드에서 대상 사이트까지의 경로가 결과에 영향을 줍니다. 노드를 선택할 때는 같은 테스트 주소와 비슷한 시간대에 비교한 뒤 실제 사용할 서비스에서 체감 속도를 확인하세요. 다운로드 속도는 서버의 속도 제한, 출구 회선 혼잡, 무선 네트워크 품질, 대상 사이트의 제한에도 영향을 받을 수 있습니다. 한 번 측정한 지연 시간만 보고 노드를 자주 바꾸지 마세요. 진행 중인 연결은 기존 노드를 계속 사용할 수 있고, 새 연결부터 바뀐 노드를 사용하므로 각각 확인해야 합니다.

Fake-IP 모드는 매핑된 IP 주소를 사용해 도메인과 이후 연결을 연결하고, 클라이언트는 도메인과 규칙에 따라 요청을 처리합니다. 이 주소는 대상 사이트의 실제 공인 IP가 아니므로 일반적인 직접 연결 주소처럼 접근 가능 여부를 판단할 수 없습니다. LAN 기기 검색, 특정 로그인 프로그램 또는 실제 DNS 응답에 의존하는 앱에서 문제가 생기면 먼저 DNS 요청이 Mihomo로 전달되는지 확인하세요. 그런 다음 해당 도메인에 대해 fake-ip-filter와 관련 DNS 정책을 점검하세요. 모든 도메인을 필터에 추가하지 마세요. 설정을 변경한 뒤에는 시스템과 앱의 DNS 캐시를 비우고 연결을 다시 설정해야 할 수 있습니다. 변경 전 설정을 보관해 비교할 수 있게 하세요.

먼저 프록시를 끄고 기본 네트워크가 정상인지 확인한 다음, 기기 시간이 맞는지, 구독 업데이트가 성공했는지, 요금제와 노드를 계속 사용할 수 있는지 살펴보세요. 특정 노드 하나만 시간 초과되면 같은 구독의 다른 노드와 비교하세요. 모든 노드에서 시간 초과가 발생하면 네트워크 출구, 설정 오류, 서비스 제공업체 상태를 우선 점검하세요. 로그에서는 도메인 확인 실패, 연결 거부, 인증 실패, 핸드셰이크 시간 초과를 구분해야 합니다. 각각 해결 방법이 다릅니다. 테스트 주소 자체에 접속할 수 없어 지연 시간 테스트가 실패할 수도 있으므로 실제 대상 서비스에서도 확인하세요. 처음부터 포트, DNS, 규칙을 한꺼번에 바꾸지 말고 한 번에 하나씩 변경해 결과를 기록하세요.

연결됨 표시는 코어 또는 로컬 VPN 인터페이스가 시작됐다는 뜻일 뿐, 대상 요청이 성공했다는 의미는 아닐 수 있습니다. 먼저 연결 목록에 브라우저 요청이 나타나는지 확인하세요. 기록이 없다면 시스템 프록시, 앱 프록시 또는 TUN을 통한 트래픽 전달을 점검하고, 기록이 있다면 적용된 규칙, 프록시 그룹, 노드를 확인하세요. 로그를 통해 DNS 실패와 원격 연결 실패를 구분한 뒤, 잠시 전역 모드로 바꾸고 다른 사용 가능한 노드와 비교하세요. 노드를 바꿔 문제가 해결되면 기존 노드를 집중적으로 확인하고, 특정 도메인에서만 문제가 발생하면 규칙과 DNS 확인 방식을 살펴보세요. 테스트할 때마다 새 연결을 시작해 브라우저가 기존 연결을 재사용하지 않도록 하세요.

먼저 규칙 모드를 사용 중인지 확인하고, 편집기에서 저장한 파일만 보지 말고 실제로 적용된 설정을 확인하세요. 일부 클라이언트는 구독, 오버라이드, 로컬 규칙을 병합하며 이후 업데이트로 최종 설정이 달라질 수도 있습니다. Mihomo는 규칙을 순서대로 매칭하므로 앞쪽의 포괄적인 규칙이나 MATCH가 뒤쪽 규칙의 적용을 막을 수 있습니다. 명확한 도메인으로 새 요청을 보내고 연결 세부 정보에서 적용된 규칙과 정책을 확인하세요. 이미 설정된 장시간 연결은 규칙을 수정해도 자동으로 이동하지 않는 경우가 많으므로 해당 연결을 닫고 다시 시도하세요. 사용자 지정 규칙을 유지하려면 클라이언트가 지원하는 오버라이드 또는 병합 기능에 추가하세요.

먼저 클라이언트를 다시 열어 시스템 프록시와 TUN을 끈 다음 정상적으로 종료하세요. 프로세스를 강제 종료하면 트래픽을 가로채는 설정이 남을 수 있습니다. 그런 다음 시스템 네트워크 설정이 여전히 로컬 프록시 포트를 가리키는지 확인하세요. 코어가 종료된 상태에서는 해당 주소가 응답하지 않습니다. DNS를 직접 설정한 적이 있다면 기존 값을 기록한 뒤 현재 네트워크에 맞게 복구하세요. 다른 프록시 도구나 VPN이 동시에 실행 중인지도 확인해야 합니다. 한 가지 설정을 변경할 때마다 테스트하고, 곧바로 네트워크 전체 초기화를 실행하지 마세요. 절전 모드에서 깨어난 뒤나 네트워크를 전환한 뒤에만 문제가 생긴다면 발생 시점, 인터페이스 상태, 로그를 기록하고 클라이언트 업데이트 안내를 확인하세요.