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

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

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

본문 읽기블로그로 돌아가기
  • Mihomo
  • REALITY
  • Xray
  • minClientVer
  • VLESS
이 글의 목차
게시일
예상 읽기 시간
약 10분

먼저 동일한 REALITY 호환성 문제인지 확인하기

이 글은 다음과 같은 명확한 조합만 다룹니다. 서버는 Xray-core v26.7.11 이상을 사용하고 VLESS 인바운드에서 REALITY를 활성화했으며 realitySettings에 minClientVer를 명시하지 않았습니다. 클라이언트는 Clash Verge Rev, FlClash 또는 다른 Mihomo 프런트엔드처럼 Mihomo 코어를 사용합니다.

일반적인 증상은 설정이 정상적으로 로드되고 서버 포트도 수신 대기 중이지만 클라이언트에 REALITY authentication failed가 표시되거나 서버에 authentication failed or validation criteria not met가 기록되며 실제 트래픽은 계속 0인 경우입니다.

x509, certificate, invalid short id, invalid public key, SNI 오류 또는 일반적인 노드 timeout이라면 해당 필드부터 확인해야 하며 이 글의 직접적인 범위가 아닙니다.

Mihomo issue #2967에는 세션 버전 1.8.2와 기본 최소 기준의 충돌이 기록되어 있습니다. Xray issue #6477에는 동일한 설정으로 v26.6.27에서 v26.7.11로 업그레이드한 뒤 연결이 실패하고 서버 버전을 롤백하면 복구되는 현상이 기록되어 있습니다.

3x-ui issue #5922에도 관리 패널에서 호환되는 minClientVer를 명시한 뒤 복구된 사례가 기록되어 있습니다.

최근 issue #3132에서도 이 알려진 경계를 Mihomo 문서에 추가해 달라고 요청했지만, 유지관리자가 클라이언트 측의 공식 수정 사항을 발표하지는 않았습니다.

네 조건이 모두 맞을 때만 이 글을 따르세요

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

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

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

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

서버에서 Xray 버전 확인
xray version

변경 전 롤백 기준

  • 현재 Xray 설정을 통제된 위치에 백업함
  • 서버 Xray-core 및 클라이언트 Mihomo 버전을 기록함
  • 클라이언트와 서버의 첫 번째 오류를 저장함
  • UUID, public key, private key, short-id와 SNI를 변경하지 않음
  • 동일한 네트워크에서 실패한 테스트 결과를 확보함

Xray가 Mihomo를 거부하는 이유 이해하기

Xray REALITY 공식 문서는 minClientVer를 서버가 허용하는 최소 클라이언트 버전으로 정의하며 현재 기본값이 26.3.27이라고 설명합니다. 동일한 설정으로 재현한 Xray issue #6477과 함께 보면, v26.7.11부터는 이 필드가 비어 있어도 서버가 제한 없음으로 해석하지 않고 기본 최소 기준을 적용합니다.

Mihomo issue #2967에 제시된 현재 구현 근거에 따르면 REALITY ClientHello 세션 버전은 1.8.2입니다. 서버가 1.8.2를 기본 최소 버전 26.3.27과 비교하면 핸드셰이크를 거부하므로, 동일한 노드가 Xray 클라이언트에서는 작동하고 Mihomo 클라이언트에서는 실패할 수 있습니다.

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

Xray 클라이언트는 작동하지만 Mihomo에서 REALITY authentication failed 발생

서버 minClientVer와 양쪽 버전을 우선 확인하세요.

모든 클라이언트가 실패함

버전만 보지 말고 인바운드 수신 대기 상태, UUID, short-id, SNI, 키와 방화벽을 확인하세요.

한 노드만 실패하고 서버를 업그레이드하지 않음

해당 노드의 전체 REALITY 매개변수와 서비스 상태부터 확인하세요.

클라이언트에 x509 또는 certificate 오류만 있음

minClientVer를 낮추지 말고 인증서, 시간 및 SNI 점검으로 이동하세요.

버전 또는 기준값 하나만 바꿔 대조하기

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

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

대조 결과 해석 방법

비교 결과다음 단계
Xray 클라이언트 성공, Mihomo 실패minClientVer와 Mihomo 세션 버전 확인
두 종류의 클라이언트 모두 실패포트, 인바운드와 REALITY 매개변수 점검으로 돌아가기
v26.6.27 성공, v26.7.11+ 실패버전 경계를 확인한 뒤 명시적인 호환 기준을 평가
네트워크를 바꿔야만 복구됨네트워크 경로나 차단을 확인하고 결과를 minClientVer 탓으로 단정하지 않기

최소 버전을 낮출지 먼저 결정하기

Xray 공식 문서는 minClientVer를 낮추면 이전 클라이언트의 접속을 허용하지만, 이전 클라이언트의 TLS 지문은 실제 브라우저와 차이가 더 커서 DPI에 더 쉽게 식별될 수 있다고 명확히 경고합니다. 이는 호환성과 DPI에 식별될 위험 사이의 절충이지 비용 없는 수정이 아닙니다.

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

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

서버에서 최소한의 호환성 조정하기

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를 동시에 실행하지 마세요.

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

서비스를 재시작한 뒤 지연 시간 수치만 보지 마세요. 기존 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, 키와 클라이언트의 첫 번째 오류를 확인하세요.

이 작업들로는 버전 기준 문제를 해결할 수 없습니다

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

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

흔한 잘못된 조치

작업효과가 없거나 위험한 이유
skip-cert-verify 활성화minClientVer는 일반적인 인증서 검증이 아님
UUID와 REALITY 키 다시 만들기기존 대조를 깨뜨리면서 버전 기준은 바꾸지 않음
minClientVer를 0으로 설정호환 범위와 지문으로 식별될 위험을 키우며 최소 수정이 아님
지연 시간 복구만 확인지연 시간은 실제 HTTPS 트래픽 통과를 뜻하지 않음

현재 근거의 범위와 향후 유지관리

2026-09-02 현재 Xray REALITY 공식 문서는 여전히 26.3.27을 minClientVer 기본값으로 제시하고 그 값을 낮출 때의 지문 위험을 명시합니다. Mihomo issue #2967은 wontfix로 표시되었고 후속 문서 요청 #3132도 닫혔으므로 특정 Mihomo 공식 버전을 기다리는 것을 확정된 수정 경로로 적을 수 없습니다.

현재 근거는 이 글에서 한정한 버전 호환성 판단을 뒷받침하지만 모든 REALITY authentication failed를 minClientVer 탓으로 돌릴 수는 없습니다. 잘못된 short-id, public key, SNI, 시간, 흐름 제어, 포트 또는 서버가 새 설정을 불러오지 않은 경우에도 비슷한 증상이 생길 수 있습니다.

향후 Xray 또는 Mihomo의 공식 Release, 공식 문서나 병합된 코드에서 이 경계가 명확히 바뀌고 동일한 노드로 실제 요청 재검증까지 마친 경우에만 이 글의 임시 호환 설정을 철회해야 합니다. 유지관리 기록에는 서버 버전, 명시된 기준값, 호환이 필요한 클라이언트와 마지막 검증 날짜를 남기세요.

참고 자료