FlClash 자주 묻는 질문

Clash는 일반적으로 프록시 코어와 설정 생태계를 가리키며, 이러한 클라이언트를 통칭하는 말로도 쓰입니다. mihomo는 Clash Meta에서 발전한 코어 프로젝트로, 프로토콜 연결과 규칙 매칭, DNS 처리를 담당합니다. FlClash는 설정 관리, 프록시 정책 선택, 네트워크 트래픽 처리 방식 조정을 위한 그래픽 인터페이스를 제공합니다. 인터페이스에서 지원하는 기능은 실제 코어 버전에 따라 달라질 수 있습니다. 특정 필드를 사용할 수 없다면 소프트웨어 이름만 비교하지 말고 클라이언트 안내와 코어의 지원 범위를 함께 확인하세요.

구독 링크는 이용 중인 서비스의 계정 페이지, 조직의 네트워크 관리자 또는 직접 구축한 서비스의 관리 페이지에서 받으세요. 이 사이트는 클라이언트 다운로드와 설정 안내를 제공하며, Clash 무료 노드나 구독 계정은 제공하지 않습니다. 구독 주소에는 계정 인증 정보가 포함되는 경우가 많아, 링크를 가진 사람이 설정을 열람하거나 계정 리소스를 사용할 수 있습니다. 스크린샷을 공개하거나 단체 채팅방에 전달하지 말고, 공개 변환 사이트에도 입력하지 마세요. 출처가 불분명한 무료 설정에는 추가 규칙, DNS, 원격 리소스 주소가 포함될 수 있으므로 가져오기 전에 출처와 용도를 확인하세요.

FlClash는 주로 Windows, macOS, Android, Linux용으로 배포됩니다. iPhone에서는 iOS 지원이 명확히 안내된 클라이언트를 선택하세요. 이 사이트의 다운로드 페이지에서 안내하는 iOS 클라이언트는 Clash Plus이며, App Store 링크와 공식 웹사이트 clashplus.io를 제공합니다. 기존 구독을 계속 사용할 수 있는지는 클라이언트가 지원하는 구독 형식과 프로토콜에 따라 달라집니다. 클라이언트를 바꾸기 전에 서비스 제공자가 호환되는 형식을 제공하는지 확인한 뒤 가져오고, 정책 그룹을 점검하세요. 데스크톱의 시스템 프록시와 TUN 설정 방법을 iOS에 그대로 적용할 수는 없습니다.

서비스 제공자가 노드 URI 목록만 제공하고 클라이언트에서 완전한 Clash 설정 파일을 요구할 때 형식 변환이 필요할 수 있습니다. 정책 그룹과 규칙이 이미 구성된 경우가 많으므로, 우선 서비스 제공자의 Clash 또는 mihomo 전용 구독을 사용하세요. 변환은 지원되는 필드를 정리할 뿐, 코어가 원래 지원하지 않는 프로토콜을 사용할 수 있게 해 주지는 않습니다. 구독을 제3자 변환 서비스에 제출하면 해당 서비스가 링크 내용을 읽을 수 있습니다. 꼭 변환해야 한다면 신뢰할 수 있는 자체 호스팅 도구를 사용하고, 결과물의 DNS, 규칙, 원격 리소스를 확인하세요.

먼저 구독 주소 전체를 복사한 다음 FlClash의 설정 페이지에서 설정 추가 또는 가져오기를 선택하고, URL에서 가져와 저장하세요. 다운로드가 완료되면 새로 만든 설정을 선택하고 프록시 페이지에서 정책 그룹이 표시되는지 확인합니다. 주소를 목록에 저장하는 것만으로는 해당 설정이 적용되지 않습니다. 이어서 규칙 모드와 사용할 아웃바운드 정책을 선택하고, 운영체제에 맞춰 시스템 프록시 또는 TUN을 활성화한 뒤 실제 접속을 테스트하세요. 버전에 따라 버튼 이름은 조금씩 다를 수 있지만, 가져오기, 설정 선택, 정책 선택, 트래픽 처리 활성화 순서는 같습니다.

Windows에서는 설정의 시스템 정보에서 시스템 종류를 확인하세요. 일반적인 Intel 또는 AMD PC에는 x64를 선택하고, ARM 기기는 배포 패키지가 해당 기기를 지원하는지 먼저 확인해야 합니다. macOS에서는 이 Mac에 관하여에서 칩을 확인한 뒤 Apple Silicon 또는 Intel용 패키지를 선택하세요. Android는 기기의 프로세서와 운영체제가 지원하는 ABI에 맞춰 선택합니다. 최신 휴대전화는 대체로 arm64를 사용하지만, 구형 기기나 특수 운영체제는 별도로 확인해야 합니다. 설치 중 패키지를 파싱할 수 없다는 오류가 나더라도 다운로드가 불완전하거나 운영체제 버전이 요구 사항을 충족하지 못했을 수 있으므로 아키텍처만 계속 바꾸지 마세요.

TUN은 가상 네트워크 인터페이스를 만들고 라우팅을 조정하므로 일반적으로 시스템 프록시보다 높은 권한이 필요합니다. Windows에서는 클라이언트 안내에 따라 필요한 서비스를 설치하거나 시작하고, 필요하면 관리자 권한으로 실행하세요. macOS와 Linux에서는 각 운영체제에 맞는 권한 승인이나 서비스 설정을 완료해야 하며, 다른 운영체제의 명령을 그대로 사용하지 마세요. Android에서 처음 활성화할 때는 시스템 VPN 연결 요청을 승인해야 합니다. 다른 VPN이 실행 중이면 충돌할 수 있습니다. 권한을 부여한 뒤 관련 서비스나 클라이언트를 다시 시작하고 로그에서 구체적인 오류를 확인하세요. 문제를 해결한다며 모든 보안 기능을 끄지는 마세요.

먼저 설치 패키지가 신뢰할 수 있는 배포 경로에서 제공되었고, 칩 아키텍처와 운영체제 버전에 맞는지 확인하세요. 앱을 응용 프로그램 폴더로 옮긴 뒤 실행해 보세요. 개발자 확인 메시지가 명확히 표시되면 현재 macOS 버전에 따라 시스템 설정의 개인정보 보호 및 보안에서 열기 허용 옵션을 제공하는지 확인하세요. 앱 손상, 아키텍처 불일치, 보안 확인은 서로 다른 문제이므로 전체 오류 메시지를 바탕으로 각각 처리해야 합니다. 출처가 불분명한 터미널 명령을 복사하거나 시스템 보안 기능을 장기간 끄지 마세요. 그래도 해결되지 않으면 운영체제 버전과 오류 메시지 원문을 기록해 추가로 점검하세요.

규칙 모드는 설정에 정의된 매칭 순서에 따라 요청에 정책을 적용하므로 일상적인 사용의 기본으로 적합합니다. 전역 모드는 코어가 처리하는 요청을 전역 정책으로 보내며, 잠시 비교 테스트할 때 유용하지만 모든 앱의 트래픽을 자동으로 코어에 보내지는 않습니다. 직접 연결 모드는 처리 대상 요청을 직접 연결하도록 하며, 프록시 아웃바운드가 문제의 원인인지 확인할 때 사용할 수 있습니다. 모드를 바꾼 뒤에는 해당 정책 그룹에서 어떤 노드를 선택했는지도 확인하세요. 기존 연결 일부는 이전 경로를 계속 사용할 수 있으므로 테스트할 때 대상 앱의 연결을 끊고 다시 시도해 이전 연결을 새 모드의 결과로 오해하지 않도록 하세요.

시스템 프록시는 운영체제의 프록시 설정을 따르는 앱에 주로 적용되며, 기기 전체의 트래픽을 처리하는 기능은 아닙니다. 먼저 브라우저 확장 프로그램, 앱 내부의 프록시 설정, 다른 클라이언트가 시스템 설정을 덮어쓰고 있지 않은지 확인하세요. FlClash가 실행 중인지, 수신 대기 포트가 설정과 일치하는지도 점검해야 합니다. 명령줄 도구, 일부 게임, 자체 네트워크 스택을 사용하는 소프트웨어는 시스템 프록시를 무시할 수 있으므로 필요에 따라 앱별 프록시를 설정하거나 TUN을 사용하세요. 클라이언트 연결 기록에서 대상 프로세스와 도메인을 확인해 처리 여부를 판단하고, 웹페이지가 열리는지만으로 판단하지 마세요. 회사 기기는 관리 정책의 제한을 받을 수도 있습니다.

AppContainer에서 실행되는 일부 Windows 앱은 로컬 루프백 제한 때문에 클라이언트가 수신 대기 중인 로컬 프록시 포트에 접속하지 못할 수 있습니다. 일반 브라우저에서는 정상인데 특정 스토어 앱만 실패한다면, 먼저 해당 앱이 실제로 로컬 프록시를 사용하는지 확인한 뒤 루프백 예외를 검토하세요. 클라이언트에 UWP 루프백 도구가 있다면 권한을 확인한 후 대상 앱에만 예외를 설정하세요. 사용 중인 버전에 해당 기능이 없다면 Microsoft 문서를 참고해 앱 패키지 식별자와 절차를 확인하세요. 루프백 예외는 구독이나 노드 오류를 해결하지 않으며, 모든 앱에 일괄 적용하는 것은 권장하지 않습니다.

먼저 도메인 이름 확인 실패와 연결 시간 초과를 구분하세요. 로그에 이름 확인 오류가 있는지 확인하고, 같은 노드에서 다른 도메인은 접속되는지도 비교하세요. 설정된 DNS 모드와 리졸버 주소, DNS 요청의 아웃바운드 경로를 확인해야 합니다. 특히 리졸버가 프록시를 필요로 하면서 아직 연결되지 않은 프록시에 의존하는 상황은 피하세요. fake-ip를 사용할 때는 일부 앱에 맞춤 필터 규칙이 필요할 수 있습니다. 원래 설정을 보존하고 대상 연결을 새로 만들면서 한 번에 하나씩만 바꾸세요. DNS를 전부 교체하고 IPv6를 끄고 라우팅까지 동시에 바꾸면 실제 원인을 찾기 어렵습니다.

먼저 로컬 네트워크가 정상인지 확인한 다음, 구독 제공자의 계정 페이지에서 링크가 재설정되었는지, 서비스 이용 기간이 만료되었는지, 전용 구독 주소를 사용해야 하는지 확인하세요. 401은 일반적으로 인증과 관련이 있고, 403은 접근 제한이나 서버 정책과 관련될 수 있으나 구체적인 원인은 서비스 제공자의 안내를 따르세요. HTML 로그인 페이지가 반환되었다고 해서 유효한 설정을 받은 것은 아닙니다. 자동 업데이트 간격은 요청 시점에만 영향을 주며, 만료된 링크를 고쳐 주지 않습니다. 주소를 수정한 뒤 수동으로 한 번 업데이트하고, 상태 코드와 시간을 기록해 서비스 제공자에게 문의하세요. 로그를 공유하기 전에는 전체 구독 주소와 인증 정보를 삭제해야 합니다.

먼저 클라이언트의 트래픽 처리를 잠시 중지하고, 로컬 네트워크에서 일반적인 사이트에 접속할 수 있는지 확인하세요. 그런 다음 구독이 유효한지, 현재 설정이 선택되어 있는지 점검합니다. 트래픽 처리를 다시 활성화한 뒤 정책 그룹 선택, 시스템 프록시 또는 TUN 상태를 확인하고 같은 테스트 주소로 여러 노드를 비교하세요. 노드 테스트 시간 초과는 테스트 주소에 접속할 수 없어서 발생할 수도 있으므로 모든 실제 연결이 실패했다는 뜻은 아닙니다. 실제 요청과 로그를 함께 확인하세요. 모든 노드에 문제가 있으면 로컬 DNS, 라우팅, 다른 VPN과의 충돌을 먼저 점검하고, 한 노드만 실패하면 여러 설정을 동시에 바꾸지 말고 서비스 제공자에게 노드 상태를 문의하세요.

먼저 브라우저에 표시된 오류 유형, 대상 도메인, 인증서 발급자를 기록하고 시스템 날짜와 시간, 시간대가 올바른지 확인하세요. 그런 다음 직접 연결과 프록시 연결을 비교해 로그인이 필요한 공용 네트워크, 비정상적인 DNS 응답, 보안 소프트웨어의 HTTPS 검사, 노드 출구 문제를 점검합니다. 일반적인 프록시 전달에는 브라우저가 추가 루트 인증서를 신뢰해야 하는 경우가 거의 없습니다. 페이지를 열기 위해 낯선 인증서를 설치하거나 인증서 검증을 건너뛰지 마세요. 특정 사이트에서만 오류가 난다면 사이트 인증서가 만료되었을 수도 있습니다. 신뢰할 수 있는 다른 네트워크에서 다시 확인하고 구체적인 오류에 따라 원인을 찾으세요.

현재 사용 중인 설정이 실제로 GEOIP, GEOSITE 또는 관련 규칙 세트를 참조하는지 확인하고, 이름이 비슷한 다른 파일이 아니라 해당 규칙에 필요한 데이터 소스를 업데이트했는지 점검하세요. 규칙은 위에서 아래로 매칭됩니다. 앞선 규칙이 이미 적용되면 뒤의 규칙은 판단에 사용되지 않으며, 데이터베이스를 업데이트해도 순서는 바뀌지 않습니다. GEOIP는 대상 IP를 기준으로 하고 GEOSITE는 도메인 분류를 기준으로 하므로 역할이 다릅니다. 업데이트 후 클라이언트 안내에 따라 설정을 다시 불러오고 새 연결에서 매칭 기록을 확인하세요. 분류가 예상과 다르면 반복해서 업데이트하기보다 규칙 내용과 데이터베이스 출처를 점검하세요.