V2Ray TLS 핸드셰이크 오류 원인: 시스템 시간 불일치와 SNI 서버 이름 설정

TLS 핸드셰이크 실패 단계 확인

TLS 핸드셰이크는 보안 연결을 설정하는 과정에서 진행됩니다. 일반 TLS 노드에 연결할 때 클라이언트는 서버와 연결 매개변수를 협상하고 서버 인증서의 유효 기간, 인증서 체인, 서버 신원을 확인합니다. TCP 포트에 연결된다는 사실은 전송 계층에 도달했다는 뜻일 뿐, 인증서 검증이나 이후 VMess 또는 VLESS 인증이 성공했다는 의미는 아닙니다.

먼저 v2rayN 하단의 로그 영역에서 이번 테스트 기록을 찾으세요. 가장 구체적인 원인까지 확인하고, 바깥쪽의 failed to process outbound traffic만 잘라 보지 마세요. 하나의 연결 오류에는 여러 단계의 메시지가 포함될 수 있으며, 실제 원인은 보통 뒤이어 나오는 x509:, tls: 또는 dial tcp 부분에 표시됩니다.

시스템 시간 및 시간대 동기화

인증서 유효 기간은 절대 시각을 기준으로 판단하며, 화면에 표시되는 시간대 이름을 기준으로 하지 않습니다. 시간대만 잘못 설정되어 있고 실제 시스템 시각은 정확하다면 일반적으로 인증서가 무효가 되지는 않습니다. 날짜를 수동으로 앞당기거나, 듀얼 부팅 환경에서 시간 설정이 일치하지 않거나, 가상 머신을 오래된 스냅샷으로 복원하면 실제 시스템 시각이 어긋날 수 있습니다. 먼저 연도, 월, 일을 확인하고 분 단위까지 살펴보세요. 오른쪽 아래에 표시된 시각만 확인하면 안 됩니다.

1. 시간 기록 확인

   로그에 표시된 현재 시각과 인증서 유효 기간을 적어 두세요. 로그 시각이 UTC라면 변환한 뒤 비교해야 합니다. 예를 들어 UTC 02:00과 UTC+8 기준 10:00은 같은 시각이므로, 단순히 8시간 차이가 난다고 판단하면 안 됩니다.

2. 자동 시간 동기화 켜기

   Windows 11에서 「설정」→「시간 및 언어」→「날짜 및 시간」으로 이동해 「자동으로 시간 설정」을 켜고 시간대를 확인한 다음 「지금 동기화」를 누르세요. 동기화에 실패하면 현재 네트워크에서 시간 서비스에 연결할 수 있는지 먼저 확인하세요.

3. 동기화 상태 확인

   Windows 터미널에서 w32tm /query /status를 실행하면 시간 원본과 마지막 동기화 성공 시각을 확인할 수 있습니다. 수동으로 동기화를 시작하려면 관리자 권한 터미널에서 w32tm /resync를 실행하세요. 오류가 발생해도 노드 설정을 반복해서 바꾸지 마세요.

4. 다시 테스트하기

   클라이언트로 돌아가 현재 서버를 다시 선택한 뒤 실제 연결 지연 테스트를 실행하세요. 새 로그의 타임스탬프를 확인해 새 연결 기록인지 확인하고, 이전 기록으로 수정 결과를 판단하지 마세요.

다른 플랫폼에서 시간 동기화 확인

• macOS:「시스템 설정」→「일반」→「날짜 및 시간」으로 이동해 날짜 및 시간 자동 설정을 켜세요. 조직에서 관리하는 기기라면 정책에 따라 시간 원본이 잠겨 있지 않은지 먼저 확인하세요.
• Android:일반적으로 「설정」→「시스템」→「날짜 및 시간」에서 자동 시간 설정과 자동 시간대 설정을 켤 수 있습니다. 일부 기기에서는 「추가 설정」 또는 「일반 관리」에 있습니다. 설정 검색 결과를 참고하세요. 그런 다음 v2rayNG 또는 v2flyNG로 돌아가 다시 연결하세요.
• Linux:systemd를 사용하는 배포판에서는 timedatectl status를 실행해 시스템 시계가 동기화되었는지 확인하세요. sudo timedatectl set-ntp true를 실행하면 시스템에서 지원하는 네트워크 시간 동기화를 켤 수 있습니다. 별도의 시간 서비스를 사용하는 배포판이라면 해당 서비스의 상태를 확인하세요.

이 숫자는 서비스 용도를 구분하기 위한 것으로, 노드 포트를 모두 443으로 바꾸라는 뜻이 아닙니다. 시간 동기화 후에도 인증서가 만료되었다는 메시지가 표시되면 로그에 나온 인증서 만료 시각을 확인하세요. 클라이언트의 시간을 바꾸는 것으로 서버 인증서 갱신을 대신할 수는 없습니다.

SNI, 서버 주소, 전송 Host 확인

SNI는 TLS ClientHello에 포함되어 대상 서버 이름을 나타내는 정보입니다. 설정 화면에서는 「SNI」, 「서버 이름」 또는 「serverName」으로 표시되며, 일부 안내서에서는 위장 도메인이라고 부릅니다. 임의로 입력해도 되는 장식용 문구가 아닙니다. 일반적인 TLS 검증에서는 서버가 어떤 인증서를 선택할지와 클라이언트가 어떤 이름을 확인할지 모두에 영향을 줍니다.

예시 호스트 이름인 edge.example.invalid는 SNI의 텍스트 형식만 보여 줍니다. 실제 연결에는 사용할 수 없습니다. SNI에 https://edge.example.invalid:443/path를 입력하거나 구독 주소 전체를 붙여 넣으면 안 됩니다. 실제로 입력할 이름은 노드 제공업체에서 받아야 하며, 흔히 쓰이는 웹사이트 도메인으로 임의 변경해서는 안 됩니다.

1. 현재 노드 확인

   v2rayN 서버 목록에서 현재 선택한 항목과 구독 그룹을 확인한 뒤, 해당 항목을 두 번 클릭해 편집 창을 여세요. 이름이 같은 다른 노드를 수정하지 않도록 먼저 주소, 포트, 전송 방식, 전송 보안 유형을 기록해 두세요.

2. 서버 이름 확인

   전송 보안 설정에서 SNI 또는 서버 이름 항목을 확인하세요. 제공업체가 안내한 값과 하나씩 대조하고 앞뒤 공백을 제거하세요. https://, 포트, 경로는 추가하지 마세요. 항목 위치는 클라이언트 버전과 프로토콜에 따라 다를 수 있습니다.

3. Host 별도 확인

   WebSocket을 사용한다면 Host와 path도 확인하세요. 도메인 오류를 없애려고 주소, SNI, Host를 모두 같은 값으로 바꾸지 마세요. 진입 주소와 인증서 이름은 원래 서로 다를 수 있습니다.

4. 저장 후 다시 테스트

   저장한 뒤 해당 노드를 다시 선택하고 실제 연결 지연 테스트를 실행하세요. 오류가 인증서 이름 불일치에서 다른 유형으로 바뀌었는지 기록하고, 한 번에 관련된 항목 한 묶음만 수정하세요.

Android에서는 v2rayNG 또는 v2flyNG의 노드 목록에서 해당 항목의 편집 화면을 열고 TLS 관련 설정에서 서버 이름을 확인할 수 있습니다. 구독 노드를 수동으로 수정하면 다음 구독 업데이트 때 변경 내용이 덮어써질 수 있습니다. 수정 후 해결되었다면 기기에 임시 설정을 계속 적용하기보다 제공업체에 구독 원본 업데이트를 요청하세요.

인증서 체인 문제와 REALITY 설정 문제 구분

기기 시간이 정확하고 SNI도 설정과 일치하더라도 서버 측 문제일 수 있습니다. 일반 TLS 서버는 올바른 최종 인증서와 필요한 중간 인증서를 제공해야 합니다. 최종 인증서만 배포했거나, 갱신 후 서비스를 다시 불러오지 않았거나, 로드 밸런서 뒤 일부 서버만 업데이트된 경우 같은 노드에서도 간헐적으로 연결에 실패할 수 있습니다.

• 유효 기간 오류:관리자에게 디스크에 저장된 새 인증서의 날짜만 확인하지 말고, 현재 진입점이 실제로 반환하는 인증서를 확인해 달라고 요청하세요. 갱신에 성공했더라도 모든 진입점에 새 인증서가 적용된 것은 아닙니다.
• 이름 오류:인증서의 Subject Alternative Name이 설정된 서버 이름을 포함하는지 확인하세요. 와일드카드 *.example.invalid는 일반적으로 한 단계 하위 도메인에만 적용되며 루트 도메인이나 더 깊은 단계의 이름에는 적용되지 않습니다.
• 알 수 없는 인증 기관:중간 인증서 체인, 기기의 시스템 업데이트, 루트 인증서 신뢰 상태를 확인하세요. 회사 또는 학교 네트워크에서만 문제가 재현된다면 TLS 검사 정책이 있는지 문의하세요. 출처를 알 수 없는 루트 인증서를 바로 가져오지 마세요.
• REALITY 노드:서버 이름 외에도 제공업체 설정에 따라 공개 키, shortId, 지문, flow를 확인해야 합니다. REALITY는 일반적인 자체 인증서 배포 방식이 아니므로 「인증서 갱신」 방법만 적용해서는 안 됩니다.

v2rayNG는 Xray 코어를, v2flyNG는 V2Fly 코어를 사용합니다. REALITY 같은 기능과 관련된 문제가 발생하면 클라이언트와 코어가 해당 노드 설정을 지원하는지 먼저 확인하세요. 화면만 다른 클라이언트로 바꾼다고 프로토콜 지원이 자동으로 추가되지는 않습니다. 데스크톱에서는 클라이언트 비교를 참고해 v2rayN의 용도를 확인한 다음, 현재 사용하는 코어와 버전을 점검하세요.

실제 연결 지연 및 실제 접속 재검사

설정을 수정한 뒤 먼저 노드를 다시 테스트하고, 그다음 앱을 확인하세요. TCPing은 성공했지만 실제 연결 지연 테스트가 실패한다면 TLS, 프록시 인증 또는 테스트 대상 접속 단계에서 여전히 오류가 발생할 수 있습니다. 실제 연결 지연 테스트는 대상 주소와 라우팅 규칙의 영향도 받으므로, 지연 시간 하나만 보고 모든 앱이 정상이라고 판단하지 마세요.

1. 원래 노드를 복사해 두거나 주요 설정을 기록한 뒤 시간을 수정하고 먼저 한 번 테스트하세요. 도메인 오류가 계속되면 그다음 SNI를 확인해 여러 설정을 동시에 바꾸지 않도록 하세요.
2. 현재 노드에서 실제 연결 지연 테스트를 실행하고 같은 시각의 로그를 확인하세요. 테스트 방법은 실제 연결 지연 안내를 참고하세요.
3. 시스템 프록시 안내에 따라 앱이 실제로 프록시를 사용하는지 확인하세요. 시스템 프록시와 TUN은 트래픽을 처리하는 범위가 다르므로, 브라우저 연결이 실패해도 코어가 실행되지 않았다고 단정할 수는 없습니다.
4. 사용이 허용된 HTTPS 대상에 접속해 출구 정보를 확인하세요. 특정 대상 하나에만 연결되지 않는다면 라우팅 분할과 해당 대상의 인증서를 확인하고, 노드 SNI를 바로 다시 바꾸지는 마세요.
5. 문의할 때는 오류 원문, 발생 시각, 운영체제 버전, 클라이언트 및 코어 버전, 완료한 확인 항목을 함께 제출하세요. 구독 token, 사용자 식별 정보, 노드 인증 정보 전체는 가리세요.

TLS 핸드셰이크 문제 해결 FAQ