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

전체 오류부터 확인: 인증서 오류와 연결 시간 초과는 다릅니다

TLS 핸드셰이크는 프록시 프로토콜 인증보다 먼저 진행됩니다. 클라이언트는 보통 서버에 연결한 다음 암호화 매개변수를 협상하고 인증서를 받아 서버 신원을 확인한 뒤 상위 계층 통신을 시작합니다. 따라서 명확한 x509 인증서 오류가 발생했다면 먼저 시간, 이름, 신뢰 체인을 확인하세요. VMess나 VLESS 사용자 식별 정보를 먼저 바꿀 이유는 없습니다. 로그에 handshake failed만 표시된다면 원인을 단정할 수 없으므로 세부 오류를 더 확인해야 합니다.

v2rayN 기본 창의 로그 영역을 확인하세요. 일부 화면에서는 ‘정보’로 표시됩니다. 테스트할 노드를 선택하고 기존 로그를 지운 다음 실제 웹 요청을 한 번 보내고, 해당 시각 전후의 전체 오류 내용을 기록하세요. 메뉴 이름은 데스크톱 버전에 따라 다를 수 있습니다. 로그에 연결 실패만 표시된다면 ‘설정’ → ‘매개변수 설정’에서 로그 수준 항목을 찾아 일시적으로 info로 높인 뒤 다시 시도하세요. 점검이 끝나면 원래 수준으로 되돌리고, 로그를 공유하기 전에는 구독 주소, 사용자 식별 정보, 접속 대상을 삭제하세요.

시스템 시간 동기화: 날짜를 바로잡은 뒤 같은 노드로 재시도

인증서에는 ‘유효 시작 시간’과 ‘만료 시간’이 있습니다. 클라이언트는 PC의 현재 시간으로 인증서 사용 가능 여부를 판단합니다. 날짜가 몇 달 늦으면 인증서가 아직 유효하지 않다고 표시될 수 있고, 날짜가 미래로 설정되면 정상 인증서를 만료된 것으로 판단할 수 있습니다. 시간대 표시가 잘못됐다고 해서 실제 시간까지 틀린 것은 아닐 수 있으므로 날짜, 시계, 시간대를 함께 확인하세요. 작업 표시줄에 표시된 시각만으로 판단해서는 안 됩니다.

1. 시간 설정 열기

   Windows 11에서는 ‘설정’ → ‘시간 및 언어’ → ‘날짜 및 시간’으로 이동합니다. Windows 10에서도 같은 경로를 사용합니다. 먼저 연도, 월, 일이 올바른지 확인하세요.

2. 지금 동기화하기

   ‘자동으로 시간 설정’을 켜고 시간대가 현재 위치와 맞는지 확인한 다음, ‘시계 동기화’ 영역에서 ‘지금 동기화’를 선택하세요. 동기화에 실패하면 먼저 기본 인터넷 연결이 정상인지 확인하세요. 조직에서 관리하는 기기는 관리자가 지정한 시간 서버를 사용해야 합니다.

3. 동기화 결과 확인

   마지막으로 동기화에 성공한 시각이 갱신됐는지 확인하세요. 명령 프롬프트에서 w32tm /query /status를 실행하면 시간 원본과 최근 동기화 성공 시각을 확인할 수 있습니다. 명령이 실패하면 Windows Time 서비스 상태와 조직 정책을 점검하세요.

4. 기존 노드 재테스트

   서버 주소, 포트, SNI를 그대로 두고 같은 노드에 다시 연결해 웹페이지를 요청하세요. 오류가 계속 유효 기간을 가리킨다면 로그의 현재 시각과 인증서 유효 기간을 함께 서버 관리자에게 전달해 확인을 요청하세요.

Android 기기에서는 시스템 설정에서 ‘날짜 및 시간’을 검색하고 자동 시간 설정과 자동 시간대를 켠 뒤 다시 연결하세요. 설정 경로는 제조사마다 다르며, 시스템 시계를 바로잡기 위해 프록시 앱 설정을 변경할 필요는 없습니다. PC가 전원을 끌 때마다 날짜가 초기화된다면 펌웨어 시간과 메인보드 배터리도 확인하세요. 클라이언트에서 노드만 계속 바꾸면 근본 원인을 놓칠 수 있습니다.

w32tm /query /status
w32tm /query /source

위 두 명령은 상태를 확인할 뿐 노드 설정을 변경하지 않습니다. 로컬 시계를 시간 원본으로 사용하거나 동기화 실패 기록이 보이면 인증서 검증을 끄는 대신 시간 서비스를 계속 점검하세요. 다른 보안 연결에 영향을 줄 수 있으므로 시스템 시간을 과거로 되돌려 만료 전 인증서를 사용하려 해서도 안 됩니다.

SNI 입력 방법: 서버 주소, 인증서 이름, Host 구분하기

SNI는 TLS 핸드셰이크에서 서버로 전송하는 이름으로, 같은 진입점에서 적절한 사이트와 인증서를 선택하는 데 사용됩니다. 클라이언트는 보통 설정된 서버 이름으로 인증서도 검증하지만, 구체적인 대체 동작은 코어와 클라이언트에 따라 다릅니다. 비워 두면 항상 올바르게 처리된다고 가정하지 마세요. 노드 제공자가 명시한 TLS 매개변수를 기준으로 입력하고, https://, 경로, 포트 없이 도메인만 적으세요.

v2rayN 기본 목록에서 테스트할 노드를 두 번 클릭해 노드 편집 창을 여세요. ‘전송 계층 보안’에서 노드 요구 사항에 따라 TLS가 활성화되어 있는지 확인한 다음 ‘서버 이름’ 또는 SNI 항목을 살펴보세요. 프로토콜마다 편집 창이 조금씩 다릅니다. 해당 항목이 보이지 않으면 올바른 프로토콜과 전송 보안 유형을 편집 중인지 먼저 확인하세요. 구독 노드는 사본을 만들어 테스트하면 다음 구독 업데이트에서 수동 변경 사항이 덮어써지는 일을 피할 수 있습니다.

인증서 이름은 SAN, 즉 ‘주체 대체 이름’을 확인해야 합니다. 예를 들어 인증서가 example.com만 포함한다면 www.example.com까지 자동으로 적용되지는 않습니다. *.example.com은 일반적으로 a.example.com과 일치하지만 루트 도메인 example.com이나 하위 단계가 더 많은 a.b.example.com과는 일치하지 않습니다. 연결 대상이 IP인데 도메인 인증서를 사용해야 한다면 노드 요구 사항에 따라 이름을 명시적으로 입력하세요. 클라이언트가 IP를 도메인 인증서의 검증 대상으로 사용하도록 두면 안 됩니다.

• 아무 웹사이트에서나 찾은 정상 도메인을 SNI에 입력하지 마세요. 원격 진입점에 해당 이름으로 설정된 구성이 있어야 합니다.
• 인증서 이름 불일치를 해결하려고 Host만 바꾸지 마세요. 일반적으로 HTTP 요청은 TLS 검증을 통과한 뒤에야 전송됩니다.
• ‘위장 도메인’은 프로토콜에서 통일된 필드명이 아니며 Host를 가리킬 수도, SNI를 가리킬 수도 있습니다. 제공자가 어떤 항목을 뜻하는지 먼저 확인하세요.
• REALITY 노드는 전용 매개변수인 serverName, 공개 키 등을 기준으로 확인해야 합니다. 일반 TLS의 인증서 교체 방법을 그대로 적용할 수 없습니다.

인증서 체인과 TLS 버전: 서버가 올바른 인증서를 보내도록 점검

PC 시간과 SNI가 모두 올바른데도 문제가 계속되면 서버 인증서를 확인하세요. 인증서를 갱신했지만 리버스 프록시가 다시 불러오지 않은 경우가 흔합니다. 서버가 사이트 인증서만 보내고 필요한 중간 인증서를 보내지 않는 경우도 있습니다. 브라우저에서 간혹 인증서 체인을 보완하더라도 모든 클라이언트 코어에서 검증에 성공한다는 뜻은 아닙니다. 서버가 완전한 인증서 체인을 올바르게 제공해야 합니다.

명령줄을 사용할 수 있다면 OpenSSL로 TLS 진입점을 따로 확인할 수 있습니다. 아래 명령은 사용법만 보여 주는 예시이며 example.com은 문서용 도메인으로 실제 노드 서버가 아닙니다. 실제로 진단할 때는 자신의 연결 대상, 포트, SNI를 사용하세요. 명령은 대상을 직접 연결하며 v2rayN의 시스템 프록시 설정을 자동으로 사용하지 않습니다. 연결 주소와 SNI가 다르면 -connect와 -servername에 각각 입력하세요. 두 값을 억지로 같게 바꾸지 마세요.

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

응답된 인증서의 이름, 유효 기간, 인증서 체인, 검증 결과를 확인하세요. 명령에서 -servername은 SNI를 전송하고 -verify_hostname은 이름을 명시적으로 검증합니다. 두 옵션은 서로 다른 작업입니다. 도구에서 해당 옵션을 지원하지 않으면 먼저 설치된 OpenSSL 버전의 안내를 확인하세요. 핸드셰이크가 끝나면 Ctrl+C로 종료할 수 있습니다. 이 테스트는 TLS만 확인하므로 WebSocket 경로, 프록시 프로토콜 인증, 실제 트래픽 전달까지 정상임을 보장하지는 않습니다.

• ‘알 수 없는 인증 기관’ 오류: 전체 인증서 체인, PC의 루트 인증서 업데이트, 관리형 네트워크의 TLS 검사 여부를 확인하세요.
• 특정 네트워크에서만 실패한다면 모바일 핫스팟과 기존 네트워크를 비교하고, 인증서 발급자가 달라지는지 기록하세요.
• 프로토콜 버전이나 암호화 스위트가 호환되지 않는다는 오류가 표시되면 양쪽 설정을 대조하고, 버전을 무작정 고정하지 말고 노드 권장 기본 협상 설정으로 되돌리세요.
• 일반 TLS 포트에서 잘못된 서비스가 실행 중이라면 진입점이 평문 HTTP, 다른 프로토콜 또는 잘못된 전달 대상을 사용하고 있는지 확인하세요.

allowInsecure 설정 방법: 인증서 검증을 유지하고 인증서 문제를 해결

일반적인 TLS 설정에서 allowInsecure는 서버 인증서 검증을 건너뛰도록 허용하는 항목입니다. 켜면 이름이나 신뢰 체인 오류가 더 이상 발생하지 않을 수 있지만, 인증서 문제가 해결되었거나 의도한 서버에 연결되었다는 뜻은 아닙니다. 포트 연결 실패, 잘못된 프로토콜 선택, 서버의 핸드셰이크 거부를 해결하지 못하며 올바른 SNI를 대신할 수도 없습니다.

v2rayN 노드 편집 창에서 ‘안전하지 않은 연결 허용’ 항목을 찾으세요. 일부 화면에서는 allowInsecure로 표시됩니다. 클라이언트에 전역 기본값이 있다면 새로 가져온 노드에 영향을 주는지도 확인하세요. v2rayNG는 Xray 코어를, v2flyNG는 v2fly 코어를 사용하므로 편집 경로와 지원 항목이 다를 수 있습니다. 각 클라이언트의 실제 화면을 기준으로 하고 한 클라이언트에서 내보낸 모든 옵션을 다른 클라이언트에 그대로 적용하지 마세요.

1. 현재 노드의 서버 주소, 포트, SNI, 검증 설정을 기록하고 되돌릴 수 있도록 원래 설정을 보관하세요.
2. 인증서 검증을 다시 켜고 한 번 연결해 이름, 유효 기간, 신뢰 체인 중 어떤 오류가 계속 발생하는지 확인하세요.
3. 오류 유형에 맞게 해결하세요. 사설 인증서는 관리자가 제공한 신뢰할 수 있는 자료를 사용하고, 채팅 화면 캡처나 출처가 불분명한 첨부 파일에서 루트 인증서를 설치하지 마세요.
4. 작업을 마친 뒤 설정이 꺼져 있지 않은지 다시 확인해 테스트 설정이 구독 사본이나 다른 기기에 남지 않도록 하세요.

재테스트와 자주 묻는 질문: 한 번에 변수 하나씩 변경

수정한 뒤 같은 노드, 같은 대상 웹페이지, 같은 프록시 모드로 다시 테스트하세요. 먼저 로그에서 인증서 오류가 사라졌는지 확인한 다음 웹페이지가 열리는지 확인합니다. TLS는 통과했지만 접속할 수 없다면 전송 경로, 프록시 프로토콜 인증, DNS, 라우팅 규칙을 점검하세요. 노드 지연 시간은 해당 테스트 방식의 결과만 보여 주며 실제 요청을 대신할 수 없습니다.

• 시간: 시스템 동기화에 성공했고 재부팅 후에도 날짜가 초기화되지 않는지 확인하세요.
• 이름: SNI에 프로토콜 접두어나 경로가 없으며 서버 인증서 SAN과 일치하는지 확인하세요.
• 신뢰: 인증서 검증이 켜져 있고 서버가 완전한 인증서 체인을 제공하는지 확인하세요.
• 결과: 요청에 성공한 시각을 기록하세요. 문제를 신고할 때는 관련 오류만 민감 정보를 가린 뒤 첨부하고 전체 구독 정보는 보내지 마세요.