V2Ray TLS 핸드셰이크 실패·인증서 오류 해결: 시스템 시간 동기화와 SNI 설정 점검

오류 위치와 핸드셰이크 단계부터 구분하기

‘TLS 핸드셰이크 실패’는 결과일 뿐, 원인이 하나로 정해져 있지는 않습니다. 구독 주소가 HTTPS라면 구독을 업데이트할 때도 TLS 핸드셰이크가 이뤄집니다. 노드에서 TLS를 사용하면 프록시 코어가 노드 서버와 핸드셰이크합니다. 전자의 오류라면 구독 도메인과 구독 서비스를 점검해야 하고, 후자의 오류라면 노드의 SNI를 확인해야 합니다. 같은 오류 문구가 보인다고 두 설정을 한꺼번에 바꾸지 마세요.

먼저 연결을 중지하고 오류가 발생한 동작을 기록한 다음, 연결을 다시 시작해 웹페이지 요청을 한 번 보내세요. v2rayNG와 v2flyNG에서는 메인 화면의 사이드 메뉴에서 ‘로그’를 열 수 있고, v2rayN에서는 메인 화면의 로그 영역을 확인하면 됩니다. 버전에 따라 메뉴 이름은 조금씩 다를 수 있습니다. ‘연결 실패’ 문구만 캡처하지 말고 오류 전후의 로그 몇 줄, 대상 도메인과 포트를 함께 저장하세요. 로그를 공유하기 전에는 구독 주소, 사용자 식별 정보와 인증 정보를 가려야 합니다.

로그에 i/o timeout, connection refused 또는 EOF만 표시된다면 인증서 검증 오류가 발생했다고 단정할 수 없습니다. 먼저 서버 주소가 올바르게 해석되는지, 대상 포트에 연결할 수 있는지, 해당 포트에서 실제로 TLS를 제공하는지 확인하세요. 이후 단계는 일반 TLS를 명시적으로 사용하는 연결을 대상으로 합니다. REALITY는 매개변수와 검증 방식이 다르므로 이 절차를 그대로 적용하면 안 됩니다.

시스템 시간 동기화: 인증서 유효 기간 오판부터 해결하기

인증서에는 유효 시작일과 만료일이 포함됩니다. 기기 날짜가 실제보다 미래로 설정되면 유효한 인증서가 만료된 것으로 판단될 수 있고, 과거로 설정되면 아직 유효하지 않은 것으로 처리될 수 있습니다. 시계의 시·분만 확인해서는 부족합니다. 연도와 날짜, 자동 시간 동기화가 정상인지도 확인하세요. 표시되는 시간대가 다르다고 반드시 오류가 생기는 것은 아닙니다. 인증서 검증에 사용되는 것은 시스템이 나타내는 실제 시간입니다.

1. 시간 설정 찾기

   Android에서 ‘설정’ → ‘시스템’ → ‘날짜 및 시간’으로 이동하세요. 일부 기기에서는 ‘추가 설정’이나 ‘일반 관리’에 있을 수 있습니다. 설정 검색창에서 ‘날짜 및 시간’을 검색해도 됩니다.

2. 자동 동기화 켜기

   ‘시간 자동 설정’과 ‘시간대 자동 설정’을 켜고 네트워크 시간 동기화가 완료될 때까지 기다리세요. 날짜가 계속 잘못 표시되면 기기 네트워크와 시스템 시간 서비스를 먼저 확인하세요. 잘못된 날짜 상태로 노드 연결을 반복해서 테스트하지 마세요.

3. 데스크톱 시간 확인

   Windows에서는 ‘설정’ → ‘시간 및 언어’ → ‘날짜 및 시간’으로 이동해 자동으로 시간 설정을 켜고 ‘지금 동기화’를 누르세요. macOS에서는 ‘시스템 설정’ → ‘일반’ → ‘날짜 및 시간’으로 이동해 날짜와 시간 자동 설정을 켜세요.

4. 다시 연결하고 로그 저장하기

   클라이언트 연결을 중지했다가 다시 시작한 뒤 같은 웹페이지에 요청을 보내세요. 유효 기간 오류가 계속되면 로그에 표시된 현재 시간과 인증서 유효 기간을 기록해 노드 관리자에게 인증서 갱신 상태를 확인해 달라고 요청하세요.

Linux에서는 timedatectl status로 시스템 시간과 동기화 상태를 확인할 수 있습니다. systemd를 사용하는 시스템에서는 sudo timedatectl set-ntp true로 네트워크 시간 동기화를 켤 수 있습니다. 이 명령은 모든 배포판에서 사용할 수 있는 것은 아닙니다. 다른 시간 동기화 서비스가 이미 실행 중이라면 시스템 설정에 맞게 처리하고, 서로 충돌하는 서비스를 동시에 실행하지 마세요.

SNI, 서버 주소, 위장 도메인의 차이

서버 주소는 연결할 IP 또는 도메인을 지정하고, 포트는 접속할 리스닝 지점을 지정합니다. SNI는 TLS 핸드셰이크에서 전송되는 서버 이름으로, 서버가 인증서나 백엔드 사이트를 선택할 때 사용할 수 있습니다. 클라이언트는 보통 설정된 서버 이름을 인증서의 이름 검증에도 사용합니다. SNI에는 순수 도메인만 입력하세요. https://, 포트 또는 경로를 포함하면 안 됩니다.

가이드에서 말하는 ‘위장 도메인’이 항상 같은 설정 항목을 뜻하는 것은 아닙니다. WebSocket의 Host, HTTP 요청 경로, TLS의 SNI는 서로 다른 계층에 속합니다. 서버 구성에 따라 같은 도메인을 쓸 수도 있고 서로 다른 값을 쓸 수도 있습니다. Host에 도메인을 입력했다고 해서 인증서가 반드시 그 도메인을 포함한다고 볼 수는 없습니다. 웹 경로를 SNI에 복사해서도 안 됩니다.

이름 일치 여부는 주로 인증서의 SAN을 확인합니다. 와일드카드 *.example.com은 일반적으로 node.example.com과 일치하지만, 루트 도메인 example.com이나 a.node.example.com과는 일치하지 않습니다. 여기의 도메인은 일치 규칙을 설명하기 위한 예시일 뿐, 실제로 사용할 수 있는 노드가 아닙니다.

클라이언트별 SNI 및 인증서 검증 설정 위치

기존 노드의 주소, 포트, 전송 방식, TLS 유형, SNI와 Host 값을 먼저 기록해 두세요. 구독으로 생성된 노드는 다음 업데이트 때 수동 변경 사항이 덮어써질 수 있습니다. 먼저 별도의 테스트 설정으로 복사하는 것이 좋습니다. 화면에서 복사할 수 없다면 원래 매개변수를 저장한 뒤 직접 새 설정을 만드세요. 버전에 따라 항목 이름이 영어나 현지어로 표시될 수 있으므로, 명칭보다 항목의 의미를 기준으로 확인하세요. 모든 노드에 공통으로 적용되는 SNI를 전역 설정에서 찾지 마세요.

1. v2rayNG 확인하기

   메인 화면에서 대상 노드 옆의 연필 모양 편집 버튼을 눌러 설정 편집 화면으로 이동하세요. TLS 영역에서 보안 유형이 tls인지 확인하고 ‘SNI’를 점검하세요. ‘인증서 검증 건너뛰기’ 또는 allowInsecure는 꺼 둡니다. 저장한 뒤 해당 노드를 다시 선택하고 연결을 재시작하세요.

2. v2rayN 확인하기

   서버 목록에서 대상 노드를 두 번 클릭해 서버 편집 창을 여세요. ‘전송 계층 보안(TLS)’ 영역에서 TLS 유형, ‘SNI’, ‘인증서 검증 건너뛰기(allowInsecure)’를 확인하세요. 후자는 false로 설정하고 저장한 뒤 해당 서버를 활성 서버로 지정해 다시 연결하세요.

3. v2flyNG 확인하기

   메인 화면에서 대상 설정의 편집 버튼을 눌러 노드 설정 화면으로 이동하세요. TLS 관련 항목에서 serverName 또는 SNI를 확인하고 allowInsecure를 꺼 둡니다. 사용자 지정 JSON을 가져온 경우 해당 설정의 TLS 항목을 직접 확인하세요. 일반 노드 설정 화면이 사용자 지정 JSON을 덮어쓴다고 가정하면 안 됩니다.

4. 원래 매개변수와 대조하기

   편집 화면의 항목을 제공자가 안내한 설정과 하나씩 대조하세요. 특히 구독 업데이트 후 SNI가 사라졌는지, TLS 대신 다른 보안 유형이 잘못 선택되지는 않았는지 확인합니다. 한 번에 한 항목만 수정한 뒤 저장하고 다시 연결해 새 로그를 확인하세요.

v2rayNG는 Xray 코어를 사용하고 v2flyNG는 v2fly 코어를 사용합니다. 두 코어가 지원하는 설정 범위는 완전히 같지 않습니다. 특정 확장 기능을 포함한 설정을 테스트 목적으로 서로 바꿔 사용하지 마세요. 일반적인 VMess 또는 VLESS TLS 연결이라면 인증서 검증 문제를 살펴보기 전에 현재 코어가 해당 프로토콜과 전송 방식을 지원하는지 확인하세요. 사용자 ID 오류도 보통 SNI를 바꿔 해결할 수 있는 문제가 아닙니다.

인증서 체인과 서버 진입 지점 확인

시간과 SNI가 올바른데도 신뢰할 수 없다는 오류가 표시되면 서버가 보내는 인증서 체인을 확인하세요. 사이트 인증서만 설정하고 중간 인증서를 빠뜨리는 경우가 흔합니다. 갱신한 인증서 파일은 업데이트했지만 실제 TLS를 처리하는 리버스 프록시를 다시 불러오지 않았을 수도 있습니다. 앞단에 중계 서버나 CDN이 있다면 원본 서버 파일만 확인하지 말고 클라이언트가 실제로 연결하는 계층을 점검하세요.

• 직접 운영하는 서버: 실제 TLS 리스너 프로세스가 불러오는 인증서 경로, 전체 인증서 체인과 개인 키 설정을 확인하고 구성을 다시 불러오는 작업이 성공했는지 로그를 확인하세요.
• 구독 노드: 오류 원문, 발생 시각, 노드 이름과 사용 중인 클라이언트를 관리자에게 전달하세요. 전체 구독 주소나 인증 정보를 보내지 마세요.
• 특정 네트워크에서만 실패: 신뢰할 수 있는 다른 네트워크와 비교하고 로그인 포털, DNS 이상 또는 네트워크 장비의 인증서 교체 여부를 확인하세요. 출처를 알 수 없는 루트 인증서를 함부로 설치하지 마세요.
• 구형 기기에서만 실패: 시스템 업데이트와 신뢰 저장소 상태를 확인하세요. 데스크톱 도구에서 검증에 성공했더라도 Android의 코어가 같은 신뢰 환경을 사용한다는 뜻은 아닙니다.

OpenSSL이 설치된 macOS 또는 Linux 환경에서는 아래 명령으로 TLS 인증서 체인과 이름 검증 결과를 확인할 수 있습니다. 예시는 예약된 예시 도메인에 연결하므로 실제 노드 검증에는 사용할 수 없습니다. 실제 문제를 확인할 때는 접속 주소, 포트, 두 도메인을 자신의 설정에 맞게 바꾸세요. 이 명령은 연결을 설정하지만 VMess나 VLESS 인증, 이후 전송 경로까지 검증하지는 않습니다.

openssl s_client -connect example.com:443 -servername example.com -verify_hostname example.com -verify_return_error -showcerts

출력에서 인증서 유효 기간과 이름, 검증 오류를 확인하세요. Verify return code: 0 (ok)가 표시되더라도 현재 테스트 환경에서 인증서 검증에 성공했다는 뜻일 뿐, 프록시 설정 전체가 정상이라는 의미는 아닙니다. 일반 TLS 핸드셰이크는 성공하지만 클라이언트에서 실패한다면 전송 경로, Host, 프로토콜 인증, 클라이언트가 실제로 연결하는 주소가 같은지 계속 확인하세요.

allowInsecure와 자주 하는 오해

allowInsecure=true는 중요한 인증서 검증을 건너뛰어 서버 신원을 안전하게 확인할 수 없게 만듭니다. 인증서를 갱신하거나 인증서 체인을 보완하지 않으며 SNI도 자동으로 수정하지 않습니다. 이 설정을 켠 뒤 일시적으로 연결되더라도 검증 관련 문제가 있다는 범위를 좁힐 수 있을 뿐, 설정이 제대로 해결됐다고 판단해서는 안 됩니다.

수정 후 다시 확인하는 순서

문제 해결 후에는 시스템 시간이 올바른지, 인증서 검증이 켜져 있는지 확인한 다음 연결을 재시작하세요. 지연 시간 테스트 결과만으로 판단하지 마세요. 테스트 방식마다 확인하는 연결 단계가 다르며, 결과가 나온다고 인증, 전송, 웹 요청까지 모두 성공한 것은 아닙니다. 변수를 줄이려면 같은 노드, 같은 네트워크, 같은 대상을 사용해 다시 테스트하세요.

• 수정한 노드가 현재 활성 설정인지 확인하고, 기존 연결을 중지한 뒤 새로 연결하세요.
• 실제 웹페이지 요청을 한 번 보내고 로그에 같은 x509 또는 TLS 오류가 계속 표시되는지 확인하세요.
• 인증서 오류는 사라졌는데 웹페이지가 여전히 열리지 않는다면 새 로그를 기준으로 인증, WebSocket 경로, Host, DNS와 라우팅을 확인하세요. SNI를 계속 바꾸지는 마세요.
• 구독 업데이트가 수정한 매개변수를 덮어쓰지 않는지 확인하세요. 변경한 항목과 검증 결과를 기록해 두면 같은 문제가 생겼을 때 바로 비교할 수 있습니다.