연결 문제 해결 · Clash 기술 블로그

Mihomo REALITY authentication failed 오류는 어떻게 해결하나요?

Xray 26.7.11+로 업그레이드한 뒤 Mihomo에 REALITY authentication failed가 표시된다면 minClientVer와 클라이언트 버전을 확인하고 위험을 평가한 다음 수정, 검증 및 롤백하세요.

본문 읽기블로그로 돌아가기
  • Mihomo
  • REALITY
  • Xray
  • minClientVer
  • VLESS
이 글의 목차
글 작성자
Clash 공식
게시일
업데이트 날짜
예상 읽기 시간
약 10분

서버 업데이트 전에는 되던 노드가 이후에도 구성은 로드되지만 연결되지 않으면 구독이나 인증서를 계속 바꾸기 쉽습니다. 여기서는 양쪽 버전과 서버의 최소 클라이언트 요구 사항을 확인해야 합니다. 구독 사용자는 증거를 제공업체에 전달하세요. 관리 권한이 있어도 요구 사항을 낮추면 트래픽이 더 쉽게 탐지될 위험을 평가해야 하며 호환 설정을 대가 없는 해결책으로 볼 수는 없습니다.

Xray 업데이트 후 Mihomo 인증이 실패하는 이유는 무엇인가요?

클라이언트와 서버 로그를 각각 확인하세요. 구성이 로드되고 포트도 수신 중이어도 REALITY authentication failed 또는 authentication failed or validation criteria not met가 나타나는지, 실제 트래픽이 계속 0인지 점검해야 합니다.

minClientVer는 서버가 허용하는 최소 클라이언트 버전을 정합니다. Xray-core v26.7.11부터는 값을 비워도 기본값 26.3.27을 사용합니다. 이 글에서 확인한 Mihomo 구현은 REALITY 인증 세션에서 1.8.2를 보냅니다. 이는 앱에 표시된 설치 코어 버전이 아니라 인증 시 전달되는 값이므로 서버가 여전히 연결을 거부할 수 있습니다.

이는 일반적인 인증서 검증 문제가 아니며 클라이언트 YAML에 공유 가능한 필드 하나가 빠진 문제도 아닙니다. minClientVer는 Xray REALITY 서버 인바운드 설정에 속하며 일반 사용자에게 Clash 또는 Mihomo 구독과 함께 전달되지 않습니다. 서버 제어 권한이 없다면 버전과 오류를 서비스 제공자에게 전달해야 하며 클라이언트에 이 필드를 임의로 추가할 수 없습니다.

설정을 저장하고 양쪽의 실제 버전 기록하기

해당 구성은 서버에 Xray-core v26.7.11 이상을 사용하고 VLESS 인바운드에서 REALITY를 켰으며 realitySettings에 minClientVer를 명시하지 않은 경우입니다. 클라이언트는 Clash Verge Rev, FlClash 등 Mihomo 코어를 사용하는 Mihomo 프런트엔드입니다.

x509, certificate, invalid short id, invalid public key, SNI 오류나 일반적인 노드 timeout은 해당 필드부터 확인하세요. 여기의 호환성 조정은 적용하지 않습니다.

서버 설정을 바꾸기 전에 현재 적용 중인 Xray 설정을 내보내거나 복사하고, 관리 패널 버전, Xray-core 버전, 클라이언트에 표시된 Mihomo 버전과 최초 실패 시각을 기록하세요. ‘모두 최신’이라고만 쓰지 마세요. 재현 가능한 비교에는 버전 번호가 필요합니다.

영향받는 인바운드의 protocol, network, security, flow, serverNames, shortIds와 minClientVer가 비어 있는지도 함께 기록하세요. 백업에는 UUID, privateKey, 구독 식별자와 서버 주소가 포함될 수 있으므로 통제된 위치에만 보관하고, 공개 issue나 스크린샷에서는 반드시 가리세요.

서버에서 Xray 버전 확인
xray version

프로토콜, 서버, 클라이언트의 해당 조건

확인 항목해당 상태일치하지 않을 때
프로토콜VLESS + REALITY실제 프로토콜, TLS 또는 전송 계층부터 점검
서버Xray-core v26.7.11+이 글의 버전 결론을 적용하지 마세요
서버 필드minClientVer가 비어 있거나 작성되지 않음명시된 값과 클라이언트 버전 확인
클라이언트Mihomo 코어이며 인증 실패가 발생함실제 코어와 첫 번째 오류부터 확인

노드를 고정하고 클라이언트 또는 서버 버전만 바꿔 비교하기

가장 유용한 대조는 동일한 인바운드, 동일한 노드와 동일한 네트워크를 유지하고 클라이언트 코어 또는 서버 버전만 비교하는 것입니다. Xray 클라이언트가 해당 인바운드를 통해 실제 HTTPS 요청을 완료하지만 Mihomo 클라이언트는 지속적으로 실패한다면 포트, 키와 대상 사이트가 모두 함께 고장 난 것은 아닙니다.

업그레이드 전에 공식 Xray v26.6.27을 보관했고 동일한 설정으로 해당 버전에 되돌렸을 때 즉시 복구된다면 버전 호환성 판단을 뒷받침합니다. 롤백은 짧은 확인에만 사용하고 백업과 공식 바이너리 출처 없이 운영 서버를 교체하지 마세요.

대조 결과 해석 방법

비교 결과다음 단계
Xray 클라이언트 성공, Mihomo 실패minClientVer와 Mihomo 세션 버전 확인
두 종류의 클라이언트 모두 실패포트, 인바운드와 REALITY 매개변수 점검으로 돌아가기
한 노드만 실패하고 서버를 업그레이드하지 않음해당 노드의 전체 REALITY 매개변수와 서비스 상태부터 확인하세요.
v26.6.27 성공, v26.7.11+ 실패차이가 버전과 관련됨을 확인한 뒤 최소 클라이언트 버전을 명시적으로 설정할지 검토하세요
네트워크를 바꿔야만 복구됨네트워크 경로나 차단을 확인하고 결과를 minClientVer 탓으로 단정하지 않기
클라이언트에 x509 또는 certificate 오류만 있음minClientVer를 낮추지 말고 인증서, 시간 및 SNI 점검으로 이동하세요.

minClientVer를 낮추면 왜 트래픽이 더 쉽게 식별될 수 있나요?

Xray 유지관리자는 공식 논의에서 오래되었거나 수정된 TLS 지문(핸드셰이크 때 나타나는 특징)이 실제 브라우저와 달라 DPI 같은 트래픽 검사로 더 쉽게 식별될 수 있다고 경고했습니다. minClientVer를 낮추는 것은 연결을 허용하는 클라이언트 범위를 넓힐 뿐, 클라이언트가 보내는 지문을 바로잡지는 않습니다. 호환성을 복구할 수 있어도 그에 따른 위험을 감수해야 합니다.

서버 기준을 충족하고 동일한 노드에서 검증한 호환 클라이언트로 업그레이드할 수 있다면 Xray 기본값을 유지하는 것이 우선입니다. 현재 Mihomo 클라이언트를 반드시 계속 써야 한다면 최소값을 해당 클라이언트가 보고하는 1.8.2에 명시적으로 맞출 수 있습니다. 편의를 위해 0, 0.0.0을 쓰거나 모든 제한을 끄지 마세요.

여러 사람이 함께 쓰는 서버라면 어떤 클라이언트에 이전 기준이 필요한지 먼저 확인하고 수정 이유, 시각과 복원 조건을 기록하세요. 영향을 받는 인바운드만 처리해야 하며 모든 REALITY 인바운드의 기준을 일괄 완화해서는 안 됩니다.

위험을 감수하기로 했다면 영향받는 인바운드의 minClientVer만 변경하기

3x-ui 등의 패널에서 영향을 받는 VLESS 인바운드를 편집하고 Security 또는 REALITY 설정을 열어 Min Client Ver를 빈 값에서 1.8.2로 변경하세요.

JSON 설정을 직접 사용한다면 해당 인바운드의 realitySettings에만 minClientVer를 추가하고 UUID, privateKey, serverNames 또는 shortIds는 바꾸지 마세요.

저장한 뒤 현재 Xray 바이너리로 실제 설정 파일을 먼저 테스트하세요. 공식 명령 문서에 따르면 run 하위 명령의 -test는 서비스를 시작하지 않고 설정만 검증합니다. 설정 경로, 바이너리 이름과 서비스 재시작 방법은 설치 방식에 따르며, 패널에서 관리하는 서비스는 패널의 자체 테스트 및 재시작 절차를 우선하세요.

추가해야 할 서버 필드만 표시
"streamSettings": {
  "security": "reality",
  "realitySettings": {
    "minClientVer": "1.8.2"
  }
}
실제 경로로 설정만 테스트하고 서비스를 시작하지 않기
xray run -test -config /path/to/config.json

최소 변경 순서

  1. 현재 적용 중인 설정 백업

    원래 빈 값 상태와 롤백용 파일을 보관하고 privateKey, UUID 또는 서버 주소를 공개하지 마세요.

  2. 인바운드 하나만 수정

    minClientVer를 1.8.2로 명시하고 다른 REALITY 매개변수는 그대로 유지하세요.

  3. 설정 테스트 실행

    테스트가 실패하면 즉시 백업을 복원하고 문법 오류가 있는 설정으로 재시작하지 마세요.

  4. 기존 관리 방식으로 재시작

    패널이나 기존 서비스 관리 도구를 사용하고 두 번째 Xray를 동시에 실행하지 마세요.

skip-cert-verify를 켜지 말고 SNI 또는 client-fingerprint를 무작정 바꾸지 말며 UUID, REALITY 키와 short-id를 다시 만들거나 구독을 반복 변환하지 마세요. 이 작업들은 서버가 비교하는 클라이언트 버전을 바꾸지 않습니다.

마찬가지로 모든 노드를 Global로 전환하거나 규칙을 끄거나 로컬 설정을 삭제하지 마세요. 인증은 규칙 분기 이후에 성립하며 REALITY 서버가 이미 핸드셰이크를 거부했다면 클라이언트 프록시 모드로 통과시킬 수 없습니다.

동일한 노드로 핸드셰이크와 실제 트래픽 검증하기

서비스를 재시작한 뒤 지연 시간 수치만 보지 마세요. 기존 Mihomo 노드, SNI, short-id, public key와 클라이언트 지문을 그대로 유지하고 원래 항상 실패하던 HTTPS 요청을 다시 시도한 다음 클라이언트 연결 기록과 서버 로그를 확인하세요.

수정이 성립하면 REALITY authentication failed가 더 이상 나타나지 않고, 서버에서 인바운드가 VLESS 처리로 들어가는 것을 볼 수 있으며, 클라이언트에 실제 업로드와 다운로드 트래픽이 생기고 적어도 두 번 연속 HTTPS 요청을 완료할 수 있습니다. 변경된 것은 서버의 허용 기준이므로 보통 구독을 다시 가져올 필요가 없습니다.

검증 체크리스트

  • Xray 설정 테스트가 성공하고 서비스가 한 개만 실행됨
  • 동일한 Mihomo 노드에서 REALITY authentication failed가 더 이상 표시되지 않음
  • 서버 로그가 해당 연결을 더 이상 인증 실패 분기로 보내지 않음
  • 지연 시간만 표시되는 것이 아니라 실제 HTTPS 요청이 내용을 반환함
  • 두 번 연속 재검증하고 네트워크를 바꾼 뒤에도 결과를 설명할 수 있음
  • UUID, 키, SNI, short-id 또는 skip-cert-verify를 변경하지 않음

위험을 감수할 수 없다면 원래 설정을 복원하고 호환성이 검증된 클라이언트 사용하기

최소 버전을 낮추는 데 따른 지문 위험을 감수할 수 없다면 수정 전 realitySettings를 복원하고 설정 테스트를 다시 실행한 뒤 기존 관리 방식으로 재시작하세요. 그러면 이전 Mihomo 클라이언트가 다시 실패하는 것은 예상된 결과이며, 기준을 충족하고 검증된 클라이언트로 바꿔야 합니다.

단기적으로 서비스를 복구해야 하지만 사용할 수 있는 호환 클라이언트가 없다면, 백업이 완전하고 출처를 확인할 수 있을 때 업그레이드 전에 검증한 공식 Xray v26.6.27로 일시적인 롤백을 고려할 수 있습니다. 이는 호환성을 위한 롤백일 뿐 이전 버전이 더 안전하다는 뜻이 아니며 후속 수정을 대체해서도 안 됩니다. 현재 버전의 설치 파일과 복구 계획을 보관하세요.

1.8.2를 명시해도 계속 실패하면 즉시 백업을 복원하고 값을 더 낮추지 마세요. 대신 서버가 실제로 불러온 설정, 인바운드 포트, UUID, short-id, SNI, 키와 클라이언트의 첫 번째 오류를 확인하세요.

공식 기록과 호환성 설정 관리

Mihomo issue #2967과 Xray issue #6477은 같은 설정도 클라이언트나 서버 버전에 따라 다르게 작동할 수 있음을 보여 줍니다. 3x-ui issue #5922는 패널에서 minClientVer을 명시적으로 설정한 뒤 복구된 사례를 기록합니다.

2026-09-02 기준 Xray의 고정 커밋과 유지관리자 논의는 최소 클라이언트 버전을 바꿀 때 지문에 따른 위험을 사용자가 감수해야 한다고 명시합니다. Mihomo issue #2967은 wontfix로 표시됐고 후속 문서 요청 #3132도 닫혔습니다. 유지관리자는 클라이언트 측의 공식 수정을 발표하지 않았으므로 특정 Mihomo 안정 버전을 기다리는 것을 확실한 해결 방법으로 볼 수는 없습니다.

현재 증거는 위 구성의 버전 호환성 문제를 뒷받침하지만 모든 REALITY authentication failed를 minClientVer 탓으로 돌릴 수는 없습니다. 잘못된 short-id, public key, SNI, 시간, 흐름 제어, 포트나 서버가 새 설정을 읽지 않은 경우에도 비슷한 증상이 나타날 수 있습니다.

Xray 또는 Mihomo의 정식 Release, 공식 문서 또는 병합된 코드가 호환성 요건 변경을 명확히 밝히고 같은 노드의 실제 요청 재시험도 완료됐을 때만 명시한 최소 버전을 제거하고 기본값으로 복원하세요. 서버 버전, 설정값, 호환이 필요한 클라이언트, 마지막 검증 날짜를 유지 관리 기록에 남기세요.

참고 자료