FlClash 로컬 Provider 노드가 비어 있나요?

FlClash에 설정을 가져온 뒤 정책 그룹은 남아 있지만 로컬 Provider의 노드가 비어 있거나, 시작·새로고침 시 규칙 파일을 찾을 수 없다는 로그가 나온다면 해당 목록이 type: file을 사용하는지 먼저 확인하세요. 원격 type: http 다운로드 실패, 서비스 제공자가 반환한 빈 구독, YAML 파싱 오류를 같은 원인으로 단정해서는 안 됩니다.

공식 저장소의 issue #2448은 2026년 9월 23일에 등록된 Windows 10 / 11 사용자 제보입니다. 제보자는 v0.8.98을 사용하며 v0.8.97부터 문제가 재현된다고 설명했습니다. 제시된 재현 설정은 로컬 proxy-provider와 정책 그룹의 use를 함께 사용합니다. 제목에는 rule-providers도 언급되어 있지만, 규칙 목록만 따로 재현한 과정은 제공하지 않았습니다.

이번 확인 시점에도 issue 상태는 Open이며, 유지 관리자가 확인한 전체 영향 범위나 수정 버전은 없습니다. 따라서 이 글은 v0.8.97 이상을 사용하는 모든 설치 환경이나 macOS·Android에서 같은 문제가 반드시 발생한다고 주장하지 않습니다. 다른 플랫폼에서는 동일한 설정과 경로 문제가 확인될 때만 아래 진단 방법을 참고하세요.

이 글은 원본 파일이 존재하고 내용을 신뢰할 수 있지만, FlClash가 생성한 실행 설정이 다른 위치의 파일을 가리킬 수 있는 상황을 다룹니다. inline은 내용을 직접 확인할 수 있는 소규모 목록을 위한 임시 복구 방법입니다. 클라이언트가 수정되었다는 증거가 아니며, 필터 조건·노드 프로토콜·네트워크 문제까지 해결한다고 보장하지 않습니다.

FlClash v0.8.98의 lib/common/task.dart는 실행 설정을 생성할 때 confineProviders를 호출하여 proxy-providers와 rule-providers를 각각 처리합니다.

이 함수는 type: inline을 건너뛰고, 나머지 항목의 path를 다시 설정합니다. 경로는 Profile, 목록의 종류와 이름 등의 정보로 생성되며 원래 path를 그대로 전달하는 방식이 아닙니다.

이 코드는 비어 있지 않은 url이 있을 때만 기존 캐시를 옮기는 분기로 들어갑니다. url이 없는 로컬 file Provider에도 새 경로가 지정되지만, 해당 분기는 원래 path의 파일을 새 위치로 복사하지 않습니다. 소스 코드 분석은 원본 파일과 실제 실행 경로가 다를 수 있다는 판단을 뒷받침하며 제보자의 설명과도 일치합니다. 다만 이 사이트는 실제 Windows 설치 환경에서 별도로 재현하지 않았으므로, 이를 유지 관리자가 확인한 결론으로 취급하지 않습니다.

현재 기본 설정, 모든 외부 Provider 파일, 클라이언트 버전, 최초 오류 로그를 먼저 보관하세요. 앱 안의 Profile만 백업했다고 해서 외부 파일까지 백업에 포함되었다고 생각하면 안 됩니다. 각 파일의 별도 사본이 실제로 있는지 확인한 뒤 테스트용 설정 사본을 만드세요.

사본에서 원래 path가 가리키는 파일이 존재하는지, 현재 사용자가 읽을 수 있는지, 목록이 비어 있지 않고 형식이 올바른지 확인하세요. 클라이언트가 실제 실행 설정을 보여 줄 수 있다면 같은 이름의 Provider에 지정된 path를 비교하세요. 그렇지 않으면 로그에 나온 실제 파일 위치를 기준으로 판단하고, 실행 설정을 확인할 수 없다는 한계도 기록하세요. 캐시 디렉터리가 고정되어 있다고 추측하거나 MD5 파일 이름에 맞춰 임의로 파일을 넣지 마세요.

Mihomo 공식 문서에는 HomeDir와 안전 경로 제한에 관한 설명도 있습니다. 경로 접근이 거부된 것과 FlClash가 경로를 바꾼 것은 서로 다른 증거입니다. SAFE_PATHS를 넓히거나 디렉터리 전체의 권한을 바꾸거나 보안 제한을 끄는 식으로 해결을 시도하지 마세요. 원본 파일이 없다면 신뢰할 수 있는 파일부터 복원하고, 내용을 파싱하지 못한다면 형식부터 수정하세요.

출처를 신뢰할 수 있고 내용을 직접 이해할 수 있는 소수의 YAML 노드만 처리하세요. 로컬 프록시 목록 파일을 열어 최상위 proxies 목록의 각 노드 객체를 기본 설정의 같은 이름 Provider에 있는 payload로 옮기세요. type: inline으로 바꾸고, 해당 Provider의 path, url 및 파일 업데이트 interval을 제거하세요.

기존 health-check, 필터 또는 오버라이드 설정이 필요하다면 한꺼번에 삭제하지 말고 항목별로 확인하여 유지하세요.

Provider 이름과 정책 그룹의 use는 원래 값을 유지하세요. 노드 이름, 프로토콜, 서버, 포트, 비밀번호, TLS 필드도 빠짐없이 보존해야 합니다. 최상위 proxies가 포함된 파일 전체를 payload 안에 중첩하지 마세요. URI나 Base64 텍스트를 노드 객체처럼 그대로 붙여 넣어서도 안 됩니다. 내용을 정확히 읽거나 변환할 수 없다면 수정을 중단하고 정상 작동을 확인한 완전한 Profile을 사용하세요.

아래 예제는 구조만 보여 줍니다. my-local-nodes와 Local은 예시 이름이며, server와 password에는 실제 연결에 사용할 수 없는 자리표시자가 들어 있습니다. 실제로는 본인이 신뢰하는 노드 객체를 사용하고 원래 설정의 목록 이름과 정책 그룹 이름을 유지하세요. 이 조각은 설정 사본에 병합하는 용도이며, 전체 설정을 대체하는 용도가 아닙니다.

설정 사본을 저장한 뒤 클라이언트의 설정 검증부터 실행하고, 그 사본을 선택하여 시작하세요. 검증에 실패하면 즉시 중단하세요. 오류를 우회하려고 TUN을 켜지 말고, payload가 목록인지, 들여쓰기가 올바른지, 현재 코어가 노드 필드를 지원하는지, use가 실제로 존재하는 Provider를 가리키는지 확인하세요.

inline은 현재 내용을 기본 설정에 저장하는 정적 스냅샷입니다. 이후 원래 외부 파일만 수정해도 이 payload가 자동으로 바뀌지는 않습니다. 업데이트가 필요하면 내용을 다시 확인하고 사본에도 반영해야 합니다. 소규모 수동 목록에는 적합하지만, 대규모 구독을 기본 설정에 계속 복사해 넣는 장기 운영 방식으로는 적합하지 않습니다.

규칙 목록의 payload에는 노드 객체가 아니라 규칙 문자열이 들어갑니다. 원래 behavior가 domain, ipcidr, classical 중 무엇인지, 파일 형식이 yaml, text, mrs 중 무엇인지 먼저 확인하세요. 원래 behavior를 유지하세요. 설정 검증을 통과시키려는 목적으로 세 유형을 임의로 바꾸면 안 됩니다.

작은 YAML 파일은 payload의 규칙 항목을 같은 이름의 inline Provider로 옮길 수 있습니다. 읽을 수 있는 text 파일은 실제 규칙을 한 줄씩 확인한 뒤 YAML 문자열 목록으로 변환해야 합니다. MRS는 다른 형식이므로 파일 바이트나 Base64를 inline에 그대로 넣을 수 없습니다. 내용을 읽고 신뢰할 수 있는 원본이 없다면 원본 파일을 보관하고 검증된 방법을 사용하세요. 이 절차로 대규모 바이너리 규칙 목록을 변환하지 마세요.

아래는 classical 형식의 설정 조각입니다. 목록 안의 DOMAIN-SUFFIX,example.com에는 정책 대상을 붙이지 않습니다. 정책은 기본 rules의 RULE-SET,local-rules,Local에서 지정합니다. Local은 전체 설정에 이미 정의되어 있어야 합니다. 본인의 목록 이름, 대상, 기본 규칙 순서를 유지하고 마지막 MATCH 규칙을 추가하거나 교체하지 마세요.

domain 목록의 항목은 해당 유형이 지원하는 도메인 표현식이고, ipcidr 목록의 항목은 CIDR입니다. 예제의 DOMAIN-SUFFIX 줄을 이 두 유형의 목록에 넣지 마세요. classical 목록 안에 다시 RULE-SET이나 SUB-RULE을 쓰는 것도 지원하지 않습니다. 변환 후에는 먼저 검증하고 작은 목록 하나만 테스트하세요. 올바르게 작동하는 것을 확인한 다음에 다른 목록을 처리하세요.

이 절차는 Mihomo의 목록 형식과 inline을 건너뛰는 FlClash 소스 코드를 근거로 합니다. #2448에서 규칙 복구가 검증되었다는 뜻은 아닙니다. 규칙 유형, 변환할 원본, 참조 관계를 확인할 수 없다면 현재 상태를 보관하고 되돌리는 단계에서 멈추세요. inline으로 바꾸면 반드시 작동한다고 보장할 수는 없습니다.

현재 선택된 설정이 방금 검증한 사본인지 먼저 확인하세요. 여전히 이전 파일을 참조하는 Profile이면 안 됩니다. Provider와 정책 그룹에서 노드 수와 이름을 확인하고, filter, exclude-filter 또는 정책 그룹의 참조 때문에 모든 노드가 제외된 것은 아닌지 점검하세요.

정상 작동을 확인한 노드 하나를 선택해 평소 사용하는 시스템 프록시 또는 TUN 방식으로 실제 HTTPS 요청을 보내고, 연결 기록에서 사용된 아웃바운드를 확인하세요. 규칙 목록은 본인이 관리하거나 평소 사용하는 요청 중 실제로 그 목록에 해당하는 요청으로 테스트하여 적용된 규칙과 정책을 확인하세요. 목록이 나타나거나 지연 시간 테스트에 숫자가 표시되는 것만으로 검증이 끝난 것은 아닙니다.

마지막으로 클라이언트를 완전히 종료했다가 다시 시작하세요. 같은 Profile, 노드, 규칙이 계속 작동하고 해당 파일 누락 오류가 로그에 다시 나타나지 않는지 확인하세요. 노드는 나타나지만 요청이 실패한다면 프로토콜, 인증 정보, 네트워크를 확인하세요. 접속은 복구되었지만 규칙이 잘못 적용된다면 기본 rules의 순서와 behavior를 확인해야 합니다. 모든 문제를 계속 파일 경로 탓으로 돌리지 마세요.

사본 검증에 실패하거나 노드 프로토콜이 지원되지 않거나 규칙 적용이 나빠졌다면 해당 사본 사용을 중단하고, 작업 전에 보관한 기본 설정과 외부 파일을 복원하세요. 원래 설정도 경로 문제의 영향을 받고 있었다면 복원은 기존 상태를 보존하기 위한 것이며, 접속이 가능해졌다는 뜻은 아닙니다. 임시로는 정상 작동을 확인한 다른 완전한 Profile을 사용하세요.

설정이 여전히 작동하지 않으면 해당 클라이언트의 시스템 프록시 또는 TUN을 끄고 기기가 원래 네트워크 상태로 돌아왔는지 확인한 다음, 로그를 보관하여 프로젝트에 제보하세요. 앱 데이터 디렉터리 전체, 모든 Provider 캐시, 유일한 로컬 파일을 삭제하지 마세요. 비공개 노드를 온라인 변환 사이트에 업로드해서도 안 됩니다.

#2448에 제보할 때는 클라이언트의 전체 버전, 운영체제 버전, 원래 Provider 유형과 상대 경로, 로그에 나온 실제 경로, 설정 사본에서 inline을 시도했는지를 함께 적으세요. 공개하는 사본에서는 구독 token, 비밀번호, 서버, 개인 디렉터리 이름을 가리세요. 민감한 정보가 담긴 원본 증거는 로컬 기기에 보관하세요.

이후 수정 버전이 배포되었는지는 공식 issue, 커밋, Release만을 근거로 판단하세요. Open 상태의 issue에서 제보자가 언급한 버전, 소스 코드에서 찾은 우회 방법, 노드가 다시 나타난 현상을 확인된 클라이언트 수정으로 표현하면 안 됩니다. 업데이트 후에도 같은 설정과 확인 체크리스트로 다시 테스트하세요.