Clash Nyanpasu 자주 묻는 질문

Clash Nyanpasu는 설정과 프록시 옵션을 관리하는 그래픽 클라이언트이고, mihomo는 프로토콜 연결, DNS 조회, 규칙 실행을 담당하는 코어입니다. 구독 서비스는 서버 정보와 설정을 제공합니다. 클라이언트를 설치한다고 바로 사용할 수 있는 노드가 생기는 것은 아닙니다. 신뢰할 수 있고 유효 기간이 남은 구독이나 직접 구성한 서버 설정이 필요합니다. 연결에 문제가 생기면 화면의 설정이 적용되지 않은 것인지, 코어가 실행되지 않은 것인지, 구독에 포함된 서버를 사용할 수 없는 것인지 먼저 구분한 뒤 해당 부분을 확인하세요.

규칙 모드는 현재 설정의 규칙 순서에 따라 연결마다 직접 연결할지 프록시 그룹을 사용할지 결정합니다. 일상적인 사용을 시작하기에 적합한 모드입니다. 전역 모드는 코어에 들어온 연결을 전역 정책에서 선택한 출구로 보내지만, 컴퓨터의 모든 프로그램이 프록시를 거친다는 뜻은 아닙니다. 직접 연결 모드에서는 일반적으로 코어에 들어온 연결이 대상에 바로 접속합니다. 모드를 바꿔도 시스템 프록시나 TUN 설정이 대신 적용되지는 않습니다. 앱의 트래픽이 코어에 들어오지 않는다면 세 모드 중 무엇을 선택해도 연결 경로는 달라지지 않습니다.

아니요. 설치 파일은 운영체제와 프로세서 아키텍처에 맞아야 합니다. Windows 실행 파일을 macOS, Linux 또는 모바일에서 바로 사용할 수 없습니다. 다운로드 센터에 플랫폼별 클라이언트가 정리되어 있어도 모든 클라이언트가 모든 플랫폼을 지원하는 것은 아닙니다. 먼저 기기의 시스템 정보를 확인한 뒤 해당하는 다운로드 항목을 선택하세요. 모바일에서는 클라이언트가 구독에 사용된 프로토콜과 설정 항목을 지원하는지도 확인해야 합니다. 데스크톱 설정을 옮길 때는 참고할 수 있지만 로컬 경로, 수신 주소, 권한, TUN 옵션은 다시 조정해야 하는 경우가 많습니다.

구독 링크는 설정 내용을 가져오는 주소이고, YAML은 흔히 사용하는 설정 파일 형식입니다. 둘은 같은 것이 아닙니다. 일부 링크는 프록시, 프록시 그룹, 규칙, DNS가 포함된 전체 설정을 반환합니다. 다른 링크는 노드 정보만 반환하므로 클라이언트나 구독 서비스가 해당 형식의 변환을 지원해야 합니다. 가져오기 전에 서비스 안내에서 호환 형식을 확인하세요. 링크 모양만으로는 내용을 판단할 수 없습니다. 구독 주소에 접근 인증 정보가 포함될 수 있으니 문제를 확인할 때 전체 링크를 공개하거나 잘 모르는 온라인 변환 사이트에 입력하지 마세요.

일반적으로는 클라이언트에서 제공하며 현재 설정과 호환되는 안정 버전을 사용하세요. Alpha는 주로 새 기능이나 수정 사항을 시험하는 용도이며 동작이 계속 바뀔 수 있습니다. 이름이 더 최신이라는 이유만으로 전환할 필요는 없습니다. 새 설정 항목이나 프로토콜 기능이 꼭 필요하다면 먼저 코어 릴리스 정보를 확인하고 설정을 백업한 뒤 테스트하세요. 전환 후 시작에 실패하면 로그의 첫 설정 오류를 확인하고 기존 코어로 되돌리세요. 코어마다 지원하는 설정 항목이 다르므로 코어를 바꿔도 설정이 자동 변환되지는 않습니다.

가져오기에 성공했다는 것은 내용이 저장되었다는 뜻이지 설정이 활성화되었다는 뜻은 아닙니다. 설정 목록에서 방금 가져온 항목을 선택하고 코어가 정상적으로 시작되는지 확인하세요. 그런 다음 프록시 화면에서 실제로 사용할 프록시 그룹의 출구를 선택합니다. 우선 규칙 모드를 사용하고 시스템 프록시를 켜 보세요. 시스템 프록시를 따르지 않는 앱에는 필요한 경우 TUN을 고려할 수 있습니다. 마지막으로 접속할 수 있는 사이트를 열어 연결 기록을 확인하세요. 기록이 비어 있다면 구독이나 노드를 계속 바꾸기보다 먼저 트래픽을 어떻게 프록시에 연결할지 점검하세요.

먼저 구독이 만료되었거나 초기화되었는지, 링크를 빠짐없이 복사했는지 확인하세요. 그다음 로그에서 요청 실패와 파싱 실패를 구분합니다. 요청 실패라면 기기의 네트워크, 인증서, 서버 응답을 확인하세요. 파싱 실패라면 반환된 내용이 로그인 페이지나 오류 페이지인지, 클라이언트가 지원하지 않는 형식인지 확인해야 합니다. 서비스 제공자가 특정 User-Agent를 요구한다면 안내에 따라 설정하세요. YAML을 직접 수정했다면 들여쓰기와 필드 형식도 확인합니다. 문제를 해결하는 동안에는 기존 설정을 보관해 아직 사용할 수 있는 노드를 잃지 않도록 하세요.

먼저 TUN을 끄고 일반 프록시 방식이 작동하는지 확인하세요. 그런 다음 현재 클라이언트 버전의 안내에 따라 서비스 모드를 설치하거나 활성화하고, 시스템에서 권한을 요청하면 필요한 권한을 허용합니다. Windows에서는 서비스가 실행 중인지, 보안 프로그램이 네트워크 어댑터 구성 요소를 차단하는지 확인하세요. 다른 운영체제에서는 보조 서비스와 네트워크 확장 권한을 확인해야 합니다. 가상 네트워크 어댑터를 두고 여러 프록시 클라이언트를 동시에 실행하지 마세요. 계속 실패하면 로그의 첫 오류를 저장하고 충돌하는 프로그램을 종료한 뒤 다시 시도하세요. 정체를 모르는 네트워크 어댑터를 삭제하거나 시스템 라우팅을 바로 수정하지 마세요.

꼭 그렇지는 않습니다. 시스템 프록시는 운영체제의 프록시 설정을 따르는 앱을 로컬 프록시 포트에 연결하므로 브라우저 접속을 먼저 확인하기에 적합합니다. TUN은 가상 네트워크 인터페이스를 통해 라우팅 조건에 맞는 트래픽을 처리합니다. 시스템 프록시 설정을 읽지 않는 프로그램에 주로 사용하며, 추가 권한과 올바른 DNS 설정이 필요합니다. 일부 설정에서는 두 방식을 함께 사용할 수 있지만 문제를 확인할 때는 우선 한 가지 방식만 켜는 것이 좋습니다. 각각 정상 작동하는지 확인한 뒤 필요에 따라 조합하면 라우팅, 포트, DNS 문제를 구분하기 쉽습니다.

구독 출처, 직접 관리하는 설정, 오버라이드나 병합 규칙, 사용자 지정 DNS와 포트, 코어 선택 항목을 우선 백업하세요. 클라이언트의 내보내기 또는 백업 기능을 사용하고 복원 방법도 확인합니다. 설정 디렉터리를 복사해야 한다면 파일 쓰기가 끝나도록 클라이언트를 먼저 종료하세요. 구독이 자동 업데이트되면 직접 수정한 내용이 덮어써질 수 있으므로 장기간 유지할 변경 사항은 지원되는 오버라이드 기능에 넣는 것이 좋습니다. 백업 파일에 구독 인증 정보나 서버 비밀번호가 포함될 수 있으니 안전한 곳에 보관하고 공개된 문의에 첨부하지 마세요.

현재 설정에서 지원하는 오버라이드나 규칙 편집 기능을 사용해 대상 도메인의 직접 연결 규칙을, 해당 도메인과 일치할 수 있는 넓은 범위의 규칙보다 앞에 배치하세요. 모드는 규칙 모드로 유지합니다. 도메인 접미사 규칙은 하위 도메인에도 적용되므로 범위가 의도한 대로인지 확인하세요. 설정을 저장하고 다시 불러온 뒤 기존 연결을 끊거나 해당 앱을 재시작합니다. 연결 기록에서 일치한 규칙과 실제 출구를 확인하세요. 브라우저에서 페이지가 열리는지만으로 판단하지 마세요. 캐시, 연결 재사용, 앱 자체의 프록시 설정이 결과에 영향을 줄 수 있습니다.

먼저 해당 연결에 방금 변경한 프록시 그룹이 실제로 적용되는지 확인하세요. 설정에 중첩된 프록시 그룹이 있을 수 있습니다. 바깥 그룹에서 자동 테스트 그룹을 선택해도 실제 노드는 안쪽 그룹에서 결정될 수 있습니다. 이미 연결된 세션은 선택을 바꿔도 바로 다른 노드로 이동하지 않는 경우가 많으므로 기존 연결을 끊거나 앱을 재시작한 뒤 다시 테스트하세요. 프록시 그룹이 자동 선택 유형이라면 테스트 주소, 주기, 시간 제한을 확인합니다. 테스트 결과는 해당 조건에서 연결 가능한지를 보여줄 뿐, 모든 서비스가 같은 노드에서 동일하게 작동한다는 보장은 아닙니다.

지연 시간 테스트는 보통 지정된 테스트 주소에 응답을 받는 데 걸리는 시간을 측정합니다. 사용 가능한 대역폭과는 다르며 동영상 사이트나 다운로드 서버의 속도를 직접 나타내지도 않습니다. 회선 혼잡, 서버 측 속도 제한, 대상 사이트의 위치, 패킷 손실, 프로토콜 오버헤드가 실제 사용 경험에 영향을 줍니다. 비슷한 시간대와 같은 네트워크, 같은 작업 조건에서 노드를 비교하고 연결 기록에서 예상한 출구를 사용했는지 확인하세요. 한 번 측정한 최저 지연 시간만으로 결론 내리지 마세요. 여러 번의 테스트 수치보다 지속적인 전송 안정성이 더 유용한 기준일 때가 많습니다.

구독에서 내려받은 파일을 직접 수정하면 다음 업데이트에서 새 내용으로 교체될 수 있습니다. 규칙을 계속 유지하려면 현재 클라이언트 버전에서 지원하는 오버라이드, 병합 또는 스크립트 처리 기능을 사용하고 적용 순서를 먼저 확인하세요. 수정한 뒤에는 수동으로 다시 불러오는 경우와 구독을 업데이트하는 경우를 각각 테스트해 최종 설정에 해당 규칙이 남아 있는지 확인합니다. 구독에서 프록시 그룹 이름이 바뀌면 기존 참조가 더 이상 유효하지 않을 수 있습니다. 프록시 그룹을 찾을 수 없다는 오류가 나오면 이전 파일만 복원하지 말고 규칙의 참조도 함께 확인하세요.

Fake-IP는 도메인과 연결할 가상 주소를 앱에 반환하고, 코어는 매핑 정보를 이용해 연결을 처리합니다. 트래픽을 프록시로 넘길 때 도메인 정보를 유지하는 데 도움이 됩니다. 하지만 DNS 문제를 모두 해결하는 단독 기능은 아닙니다. 올바른 DNS 수신 설정, 트래픽 처리 방식, 상위 DNS 서버 설정도 필요합니다. 일부 LAN 서비스나 실제 주소에 의존하는 앱에는 예외 설정이 필요할 수 있습니다. 설정을 바꾼 뒤 관련 캐시를 지우고 연결을 새로 만든 다음 로그와 실제 DNS 조회 경로를 확인하세요. 검사 페이지에 특정 지역이 표시된다는 이유만으로 설정이 올바르거나 DNS가 유출됐다고 단정하지 마세요.

먼저 프록시를 끄고 기본 네트워크가 작동하는지 확인한 다음 시스템 시간이 정확한지 살펴보세요. 설정이 활성화되어 있는지, 구독이 유효한지, 코어 로그에 오류가 있는지도 확인합니다. 모든 노드에서 동시에 시간 초과가 발생하면 DNS, 테스트 주소 연결 불가, 네트워크 제한, 코어 미실행 등 공통 요소를 먼저 살펴보세요. 일부 노드에서만 실패한다면 해당 서버를 우선 확인합니다. 신뢰할 수 있는 다른 네트워크에서 비교하고 속도 테스트 버튼에만 의존하지 말고 실제 사이트에 접속해 보세요. 문제를 문의할 때는 발생 시간과 민감 정보를 제거한 로그를 제공하고 전체 구독 주소는 공개하지 마세요.

먼저 클라이언트의 연결 기록에 해당 프로그램의 요청이 표시되는지 확인하세요. 기록이 없다면 시스템 프록시 주소와 포트가 코어의 실제 수신 설정과 일치하는지, 브라우저 확장 프로그램이나 앱 자체 프록시, 다른 VPN이 설정을 덮어쓰는지 살펴보세요. 일부 프로그램은 시스템 프록시를 사용하지 않으므로 앱에서 프록시를 따로 설정하거나, 필요한 경우 TUN을 사용할 수 있습니다. 연결이 코어에 들어왔는데 직접 연결된다면 일치한 규칙과 프록시 그룹을 확인하세요. 시스템 프록시가 켜져 있다고 해서 모든 앱이 프록시를 사용하는 것은 아닙니다.

AppContainer 격리를 사용하는 일부 UWP 앱은 루프백 연결 제한 때문에 로컬 프록시 포트에 접속하지 못할 수 있습니다. 먼저 데스크톱 브라우저가 정상적으로 작동하는지 확인한 뒤 문제가 생긴 앱이 해당 사례에 해당하는지 살펴보세요. 클라이언트에서 UWP 루프백 제한 해제 도구를 제공한다면 필요한 앱에만 예외를 설정하고 안내에 따라 관리자 권한을 허용하세요. Windows의 CheckNetIsolation 도구로 예외를 관리할 수도 있습니다. 모든 앱에 일괄적으로 권한을 열어 주지 마세요. 그래도 문제가 계속되면 앱이 시스템 프록시를 따르는지 확인하거나 TUN으로 트래픽을 처리하는 방법을 검토하세요.

먼저 시스템이 더 이상 수신하지 않는 로컬 프록시 주소를 계속 사용 중인지 확인하고 남아 있는 수동 프록시 설정을 끄세요. 그런 다음 TUN, 서비스 모드 또는 다른 VPN이 실행 중인지 확인하고 정상적으로 종료한 뒤 네트워크에 다시 연결합니다. DNS를 직접 변경한 적이 있다면 현재 네트워크에 맞는 설정으로 복원하고 캐시를 비우세요. 처음부터 모든 네트워크 어댑터를 초기화하거나 라우팅을 삭제하지 마세요. 회사 네트워크나 다른 소프트웨어에 영향을 줄 수 있습니다. 기본 네트워크를 복구한 다음 클라이언트를 다시 시작하고 기능을 하나씩 켜면서 남은 설정이 무엇인지 확인하세요.

먼저 TUN을 끄고 비교해 트래픽 처리 방식이 문제의 원인인지 확인하세요. 그런 다음 현재 설정에서 LAN 주소, 사설 네트워크 대역, 내부 도메인의 라우팅과 DNS 처리를 어떻게 하는지 살펴봅니다. 직접 연결해야 하는 대상은 올바른 규칙과 일치해야 하고, 내부 도메인은 해당 도메인을 조회할 수 있는 DNS 서버를 사용해야 합니다. 프록시 규칙만 바꿔서는 잘못된 DNS 조회가 해결되지 않을 수 있습니다. 회사 VPN과 TUN을 함께 실행하면 라우팅이 충돌할 수도 있습니다. 실제 네트워크 범위에 맞춰 예외를 설정하고 지나치게 넓은 주소 대역을 모두 제외해 다른 연결의 경로까지 바꾸지 않도록 주의하세요.