V2Ray TLS 핸드셰이크 실패·인증서 오류 해결: 시스템 시간, SNI 및 지문 설정

이 글 미리보기

노드를 가져온 뒤 연결할 때 TLS 또는 x509 오류가 발생하는 경우에 해당합니다. 먼저 구독 다운로드 오류인지 노드 연결 오류인지 확인한 다음, 시스템 시간, 인증서 도메인, 신뢰 체인, 지문 순으로 점검하세요. 한 번에 필드 하나만 수정하고 비교할 수 있도록 원본 노드를 보관하세요. 인증서 검증을 끄는 것은 해결 방법이 아닙니다.

구독 오류와 노드 핸드셰이크 실패 구분하기

“TLS 핸드셰이크 실패”는 단일 원인을 가리키지 않습니다. 구독 주소가 HTTPS라면 구독을 가져올 때 TLS 연결이 수립됩니다. 클라이언트가 TLS를 사용하는 프록시 노드에 연결할 때도 별도의 연결이 만들어집니다. 브라우저에서 HTTPS 사이트를 열 때는 브라우저 자체 인증서 검증도 수행됩니다. 세 경우 모두 x509가 표시될 수 있지만, 수정해야 할 대상은 서로 다릅니다.

구독 업데이트를 누르자마자 오류가 나고 노드 목록이 바뀌지 않았다면 구독 주소 사이트의 인증서를 먼저 확인하세요. 구독은 정상적으로 업데이트되지만 특정 노드를 선택해 웹사이트에 접속할 때 코어에서 오류가 난다면 해당 노드의 TLS 설정을 확인해야 합니다. 브라우저에서만 인증서 경고가 표시되고 코어 로그에는 관련 오류가 없다면 브라우저 신뢰 저장소, 네트워크 로그인 페이지, 로컬 HTTPS 검사 소프트웨어도 점검하세요.

주소 확인 전송 연결 수립 핸드셰이크 정보 전송 서버 인증서 검증 프록시 프로토콜 인증

오류가 발생한 동작을 기록하세요: 구독 업데이트, 노드 연결, 특정 웹사이트 열기 중 무엇을 했는지 적어 두세요. “연결 실패”라고만 기록하면 원인을 찾기 어렵습니다.
오류 발생 시각을 기록하세요: 먼저 클라이언트 로그를 확인한 다음 요청을 한 번 보내고, 마지막 요약 줄이 아니라 같은 시각에 기록된 구체적인 오류를 찾으세요.
보안 계층을 확인하세요: VMess와 VLESS는 프록시 프로토콜 이름이며 모든 노드가 일반 TLS를 사용한다는 뜻은 아닙니다. 보안 계층이 REALITY라면 전용 매개변수를 확인해야 합니다. 일반 TLS의 점검 방법을 그대로 적용하지 마세요.

오류 메시지로 점검 방향 정하기

로그에는 아래 영어 메시지의 앞뒤로 서버 주소, 시각, 코어 호출 정보가 붙을 수 있습니다. 가장 구체적인 원인을 찾아 확인하세요. EOF나 context deadline exceeded만으로는 인증서 문제라고 단정할 수 없습니다. 서버가 연결을 끊었거나 네트워크가 차단되었거나 핸드셰이크 시간이 초과됐을 수도 있습니다.

오류: `x509: certificate has expired or is not yet valid`

원인: 현재 시간이 인증서 유효 기간에 포함되지 않습니다. 기기 시계가 잘못됐거나 서버 인증서가 만료됐을 수 있습니다. 해결: 먼저 기기 시간을 동기화하세요. 시간이 정확한데도 오류가 계속되면 로그의 유효 기간 정보를 서비스 제공자에게 전달해 인증서 배포 상태를 확인하도록 요청하세요.

오류: `x509: certificate is valid for …, not …`

원인: 클라이언트가 검증한 이름이 서버 인증서에 포함된 도메인과 일치하지 않습니다. 생략된 부분에 실제 도메인이 표시됩니다. 해결: 노드의 SNI와 serverName을 제공자가 안내한 인증서 도메인과 비교하세요. 연결 주소만 바꾸지 마세요.

오류: `x509: certificate signed by unknown authority`

원인: 인증서 체인을 신뢰할 수 있는 루트 인증서까지 연결할 수 없습니다. 중간 인증서 누락, 자체 서명 인증서, 로컬 신뢰 저장소 문제 등이 원인일 수 있습니다. 해결: 먼저 다른 네트워크에서도 같은 문제가 발생하는지 확인한 뒤 서버 측에 전체 인증서 체인을 점검해 달라고 요청하세요. 출처가 불분명한 루트 인증서는 설치하지 마세요.

오류: `remote error: tls: handshake failure`

원인: 원격 서버가 핸드셰이크를 거부했습니다. SNI, TLS 매개변수, 프로토콜 진입점 또는 서버 정책과 관련된 문제일 수 있습니다. 해결: 구독에서 제공한 원래 매개변수를 복원하고 포트와 보안 계층이 일치하는지 확인하세요. 인증서 검증을 끄지 말고 서버 로그를 함께 확인해 원인을 찾으세요.

시스템 시간: 먼저 동기화한 뒤 다시 연결

인증서 검증은 화면에 표시된 시각만이 아니라 절대 시간을 기준으로 합니다. 시간대 표시가 달라도 절대 시간이 정확하면 일반적으로 인증서가 무효 처리되지 않습니다. 하지만 시계를 수동으로 앞당기거나 늦추면 오류가 발생할 수 있습니다. 기기를 오랫동안 꺼 두었거나, 듀얼 부팅을 사용하거나, 자동 시간 동기화에 실패한 경우 특히 먼저 확인해 보세요.

컴퓨터 시간 동기화

Windows에서 「설정」→「시간 및 언어」→「날짜 및 시간」으로 이동해 「시간 자동 설정」을 켜고 시간대를 확인한 다음 「지금 동기화」를 누르세요. 동기화에 실패하면 일반 네트워크 연결이 되는지 먼저 확인하고 노드 설정을 반복해서 바꾸지 마세요.
휴대전화 시간 동기화

Android에서는 보통 「설정」→「시스템」→「날짜 및 시간」에서 「시간 자동 설정」과 「시간대 자동 설정」을 켤 수 있습니다. 일부 기기에서는 설정에서 “날짜 및 시간”을 검색하면 됩니다. 메뉴 이름은 기기 시스템에 따라 다를 수 있습니다.
연결 다시 수립하기

v2rayN에서는 코어를 다시 시작하세요. v2rayNG에서는 연결을 중지한 다음 다시 시작하세요. 요청을 새로 보내고 새 로그를 확인해 시간 동기화 전의 오류를 현재 오류로 오인하지 않도록 하세요.
인증서 유효 기간 확인

시간을 바로잡은 뒤에도 유효 기간 오류가 발생하면 로그에 표시된 현재 시각, 인증서 시작·종료 시각, 시간대를 기록하세요. 인증서가 실제로 만료됐다면 서버에서 인증서를 갱신하고 다시 불러와야 합니다. 클라이언트 날짜를 바꾸는 것으로는 올바르게 해결되지 않습니다.

Windows에서는 터미널에서 아래 명령을 실행해 로컬 시간과 시간 서비스 상태를 확인할 수 있습니다. 두 번째 명령은 시스템 서비스가 실행 중이 아닐 때 오류를 반환할 수 있습니다. 보조 진단용 명령이므로 오류가 나더라도 노드 문제라는 뜻은 아닙니다. 도움을 요청할 때 기기 정보를 전부 제출할 필요는 없습니다.

powershell -NoProfile -Command "Get-Date -Format o"
w32tm /query /status

SNI, 연결 주소, Host를 따로 확인하기

노드의 “주소”는 연결할 IP 또는 도메인을 지정합니다. SNI는 TLS 핸드셰이크 때 전송되는 서버 이름이며, 보통 인증서의 도메인 검증에도 사용됩니다. WebSocket의 Host는 이후 HTTP 요청에 포함되는 필드입니다. 세 값이 같은 배포 환경도 있고 서로 다른 환경도 있습니다. 세 필드를 모두 접속 가능한 웹사이트 도메인으로 바꾼다고 해서 노드가 정상 작동하는 것은 아닙니다.

설정 항목	기능 및 확인 사항
주소 및 포트	실제 연결 진입점을 지정합니다. 443 포트는 TLS에 자주 사용되지만, 포트 번호만으로 해당 진입점에서 TLS를 사용하는지 판단할 수는 없습니다. 구독에 표시된 값을 기준으로 하세요.
SNI / serverName	TLS 서버에 접속 대상 이름을 알립니다. 일반 TLS 노드에는 제공자가 지정한 인증서와 일치하는 도메인을 입력하세요. 프로토콜 접두사, 경로, 포트는 포함하지 않습니다.
Host	WebSocket 등 HTTP 전송에서 가상 호스트를 지정할 때 주로 사용합니다. Host를 변경해도 SNI는 바뀌지 않으며 인증서 이름 불일치도 해결되지 않습니다.
경로 및 ALPN	경로는 해당 전송 진입점에 사용되며, ALPN은 애플리케이션 계층 프로토콜을 협상합니다. 명시적인 안내가 없다면 구독 값을 유지하고 h2나 http/1.1을 임의로 강제하지 마세요.

v2rayN 메인 화면에서 대상 노드를 두 번 클릭해 서버 편집 창을 열고 주소, 포트, 전송 프로토콜, TLS 영역의 서버 이름을 확인하세요. v2rayNG에서는 대상 노드 오른쪽의 편집 아이콘을 누르고 「주소」, 「포트」, TLS 아래의 「SNI」를 확인할 수 있습니다. 버전에 따라 serverName 또는 서버 이름으로 표시될 수 있으니, 모든 버전에 공통된 메뉴를 찾기보다 필드의 의미를 기준으로 확인하세요.

결론: 원래 SNI를 복원한 뒤 DNS 확인

인증서 이름이 일치하지 않으면 최근에 가져온 구독 노드와 비교해 SNI를 먼저 복원하세요. 필드 값이 일치하는데도 잘못된 인증서가 반환된다면 노드 주소의 DNS 조회 결과와 서버 진입점을 확인하세요. 임의로 “위장 도메인”을 바꾸면 확인할 변수만 늘어납니다.

연결 주소로 IP를 사용하는 것이 항상 잘못된 것은 아닙니다. 서버에서 IP 연결을 허용하고 SNI를 올바르게 설정했다면 도메인 인증서를 검증할 수 있습니다.
와일드카드 인증서는 보통 한 단계의 하위 도메인만 일치합니다. 예를 들어 *.example.com은 a.b.example.com과 일치하지 않습니다. 여기서 든 도메인은 규칙 설명용이며 노드 설정값이 아닙니다.
구독 노드를 수동으로 수정하면 이후 업데이트에서 변경 사항이 덮어써질 수 있습니다. 진단할 때는 노드를 복사해 편집하고, 비교할 수 있도록 구독 원본을 보관하세요.

인증서 체인과 검증 건너뛰기: 같은 설정으로 취급하지 마세요

인증서 검증은 도메인뿐 아니라 서명 체인과 유효 기간도 확인합니다. 서버가 중간 인증서를 빠뜨리면 일부 브라우저는 기존 캐시 덕분에 페이지를 열 수 있지만 프록시 코어에서는 오류가 계속 발생할 수 있습니다. 따라서 “브라우저에서 열린다”는 사실은 참고 정보일 뿐, 코어의 검증 결과를 대신할 수 없습니다.

특정 노드 하나만 실패: 같은 기기의 다른 TLS 노드는 정상이라면 해당 진입점의 전체 인증서 체인, 인증서 도메인, 인증서 적용 상태를 서비스 제공자에게 확인해 달라고 요청하세요.
같은 기기에서 여러 서비스가 실패: 시스템 업데이트, 루트 인증서 신뢰 저장소, 로컬 HTTPS 검사 소프트웨어를 확인하세요. 테스트를 위해 보안 기능을 전부 끄지 마세요.
특정 네트워크에서만 실패: 먼저 네트워크 로그인 인증을 완료한 다음 신뢰할 수 있는 다른 네트워크에서도 확인하세요. 받은 인증서의 발급자가 수상하다면 구독 정보를 입력하지 말고 네트워크 환경을 점검하세요.
자체 서명 인증서를 사용하는 것이 명확한 경우: 신뢰할 수 있는 경로로 서버 신원을 확인하고 클라이언트와 코어가 지원하는 방식으로 신뢰 설정을 구성해야 합니다. 신원을 확인할 수 없다면 검증을 무시한 채 계속 사용하지 마세요.

인증서 검증 건너뛰기를 켜 둔 적이 있다면 문제 해결이 끝난 뒤 해당 옵션을 끄고 다시 연결하세요. 검증을 복원한 상태에서 같은 오류가 로그에 나타나지 않고 실제 요청도 성공해야 해결된 것입니다. 지연 시간 테스트 한 번에 성공했다고 해서 모든 요청이 의도한 TLS 진입점을 거친다는 뜻은 아닙니다.

TLS 지문: 노드 요구 사항에 맞게 설정하고 무작정 바꾸지 마세요

TLS 지문은 확장 항목의 배열이나 지원 매개변수 조합처럼 클라이언트 핸드셰이크 메시지의 특징에 영향을 줍니다. 인증서를 대체하지 않으며 만료된 인증서를 다시 유효하게 만들지도 않습니다. 일반 TLS와 REALITY는 관련 매개변수 요구 사항이 다르므로 한 종류의 노드에서 사용한 설정을 다른 종류에 그대로 복사하지 마세요.

v2rayN은 클라이언트 인터페이스이며 실제 핸드셰이크는 현재 선택된 코어가 수행합니다. v2rayNG는 Xray 코어를, v2flyNG는 V2Fly 코어를 사용합니다. 인터페이스에 필드가 표시된다고 해서 코어마다 동일하게 지원된다는 뜻은 아닙니다. 문제를 진단할 때는 사용 중인 코어 이름과 서비스 제공자의 요구 사항을 확인하고 클라이언트 이름만 비교하지 마세요.

보안 계층을 확인하세요. 노드를 편집해 TLS인지 REALITY인지 확인하고 구독 원본을 보관하세요. 일반 TLS에서 x509 오류가 발생하면 먼저 시간, SNI, 인증서 체인을 확인하세요.
지문 필드를 확인하세요. 노드 편집 화면의 TLS 또는 REALITY 영역에서 「지문」이나 fingerprint를 찾으세요. 구독에 chrome 같은 값이 명시되어 있다면 우선 해당 값을 유지하고 ALPN은 추가로 수정하지 마세요.
코어 지원 여부를 확인하세요. 로그에 특정 필드가 지원되지 않는다고 표시되면 호환되는 클라이언트와 코어를 업데이트한 뒤 구독을 다시 가져오세요. 필드를 삭제하는 방법을 모든 환경에 통하는 호환성 해결책으로 취급하지 마세요.
REALITY는 별도로 확인하세요. serverName과 지문 외에도 공개 키, shortId 등 제공자가 안내한 매개변수를 점검해야 합니다. 공개 키를 인증서 경로에 입력하지 말고 일반 TLS의 검증 건너뛰기 옵션으로 이러한 매개변수를 대체하지 마세요.

결론: 인증서 오류는 먼저 인증서 조건부터 바로잡기

로그에 인증서 만료 또는 도메인 불일치가 명확히 표시되면 해당 문제부터 해결한 뒤 지문 호환성을 확인하세요. 시간, 진입점, 매개변수를 모두 점검했는데도 원격 서버가 핸드셰이크를 거부할 때 클라이언트 핸드셰이크 특성과 서버 정책을 추가로 확인하세요.

자주 묻는 질문과 해결 후 재검사

휴대전화에서는 연결되는데 컴퓨터에서 인증서 오류가 나는 이유는 무엇인가요?

먼저 두 기기에서 같은 노드, 같은 SNI, 같은 보안 계층을 사용 중인지 확인한 다음 컴퓨터 시간을 동기화하세요. 이어서 두 기기를 같은 네트워크에 연결해 다시 테스트하세요. 컴퓨터에서만 계속 실패한다면 신뢰 저장소와 로컬 HTTPS 검사 소프트웨어를 확인하세요. 노드 이름이 같다는 이유만으로 설정까지 같다고 단정하지 마세요.

「인증서 검증 건너뛰기」를 켜면 작동하는데 계속 켜 둬도 되나요?

일상적인 설정으로 유지하지 마세요. 먼저 원래 인증서 오류를 기록한 뒤 옵션을 끄고 시간, 도메인, 인증서 체인을 차례로 점검하세요. 제공자가 검증을 계속 무시하라고 요구한다면 알 수 없는 인증서를 바로 받아들이지 말고 신원 확인 방식을 먼저 확인하세요.

전역 모드로 바꾸면 TLS 핸드셰이크 실패를 해결할 수 있나요?

인증서 오류를 직접 해결할 수는 없습니다. 라우팅 규칙은 요청이 어떤 아웃바운드 경로를 사용할지 결정하고 TLS 검증은 해당 연결의 서버 신원을 확인합니다. 먼저 로그에서 실제로 선택된 노드를 확인하세요. 모드를 바꾼 뒤 오류가 사라져도 트래픽의 출구만 바뀐 것일 수 있으므로 원래 노드도 계속 점검해야 합니다.

구독 업데이트 중 인증서 오류가 나도 노드 SNI를 바꿔야 하나요?

노드부터 바꿀 필요는 없습니다. 먼저 시스템 시간을 동기화하고 구독 URL의 도메인이 올바른지 확인하세요. 해당 구독 주소에서만 실패한다면 서비스 제공자에게 구독 사이트의 인증서를 점검해 달라고 요청하세요. 기존 노드의 SNI를 바꿔도 구독 사이트의 HTTPS 인증서는 바뀌지 않습니다.

최종 재검사에서는 같은 기기, 같은 네트워크, 같은 노드를 사용하고 한 번에 항목 하나만 수정하세요. 연결을 다시 시작한 뒤 코어 로그와 실제 웹페이지 접속을 각각 확인하고, 검증 건너뛰기를 끈 상태에서도 정상 작동하는지 확인하세요. 도움을 요청할 때는 아래 최소 정보만 제출하고 전체 구독 주소, UUID, 비밀번호, 기타 인증 매개변수는 공개하지 마세요.

클라이언트 이름, 실제 설치 버전, 현재 코어와 버전, 운영체제 이름.
오류를 발생시킨 동작, 정확한 시각, 민감 정보를 가린 전체 오류 메시지.
전송 방식, 보안 계층, 포트, SNI가 제공자 요구 사항과 일치하는지 여부.
시간 동기화, 네트워크 변경, 원래 노드 복원 후의 결과. 매번 변경한 항목 하나를 명시하세요.