v2rayN, v2rayNG, v2flyNG에서 발생하는 TLS 핸드셰이크 실패, 인증서 만료, 도메인 불일치, 연결 종료 문제에 대응할 수 있습니다. 먼저 시스템 시간을 맞춘 뒤 노드 주소, SNI, 전송 계층 설정을 확인하고, 마지막으로 코어 로그를 통해 로컬 설정·네트워크 차단·서버 인증서 문제를 구분하세요.
TLS 핸드셰이크 순서대로 장애 구간 찾기
TLS는 전송 연결 위에서 동작합니다. 클라이언트는 먼저 서버 주소를 해석하고 TCP 연결을 만든 다음, 프로토콜 버전·암호화 스위트·SNI가 포함된 ClientHello를 보냅니다. 서버가 인증서를 반환하면 Xray 또는 V2Fly 코어가 인증서 유효 기간, 발급 체인, 도메인을 확인합니다. 어느 하나라도 실패하면 VMess 또는 VLESS 인증 데이터는 아직 정상적으로 교환되지 않은 상태이므로 UUID, alterId 또는 라우팅 규칙을 바꿔도 인증서 오류가 해결되지 않는 경우가 많습니다.
점검할 때는 먼저 코어 로그 전체를 저장하고 화면에 표시된 “연결 실패”만 보지 마세요. v2rayN에서는 메인 창 하단 로그 영역 또는 「도움말」→「로그 보기」에서 최근 출력을 확인할 수 있습니다. v2rayNG에서는 왼쪽 상단 메뉴의 「로그」를 열어 코어 오류를 확인하세요. 코어 버전에 따라 표현은 조금 다를 수 있지만 x509, certificate, handshake, server name 등의 키워드만으로도 문제 방향을 파악할 수 있습니다.
오류: x509: certificate has expired or is not yet valid
원인 및 해결: 기기의 시간이 인증서 유효 기간을 벗어났거나 서버 인증서가 실제로 만료된 상태입니다. 날짜·시간·시간대를 자동 동기화한 뒤 다시 연결하세요. 여러 기기에서 동시에 오류가 발생하면 설정 제공자에게 인증서 갱신을 요청해야 합니다.
오류: x509: certificate is valid for another domain, not current domain
원인 및 해결: SNI에 지정한 도메인이 인증서의 주체 대체 이름에 포함되어 있지 않습니다. TLS의 serverName을 인증서가 포함하는 도메인으로 변경하고 서버 IP를 그대로 입력하지 마세요.
오류: remote error: tls: handshake failure
원인 및 해결: 서버가 핸드셰이크를 거부한 상태입니다. SNI, 포트, TLS 활성화 여부 또는 전송 방식이 서로 다를 때 흔히 발생합니다. 서버 설정을 항목별로 대조하고 WS, gRPC, TCP 등의 전송 매개변수를 혼용하지 않았는지 확인하세요.
오류: tls: failed to verify certificate
원인 및 해결: 인증서 체인, 도메인 또는 유효 기간 검증에 실패했습니다. 먼저 시간과 SNI를 바로잡고, 인증서 검증을 끄는 방법을 일반적인 해결책으로 사용하지 마세요.
시스템 시간·시간대·네트워크 시간 동기화 확인
인증서에는 명확한 시작 시각과 만료 시각이 포함되며, 검증에는 기기의 현재 시계가 사용됩니다. 시스템 시간이 몇 분만 어긋나도 새로 발급되거나 갱신된 인증서가 “아직 유효하지 않음” 구간으로 판단될 수 있습니다. 절전 후 시계 오차, 듀얼 부팅 환경의 시계 기준 불일치, 가상 머신 일시 정지 후 복원, 라우터의 시간 동기화 차단 등이 이런 오류를 일으킬 수 있습니다.
Windows에서는 「설정」→「시간 및 언어」→「날짜 및 시간」을 차례로 열고 자동으로 시간 설정 및 자동으로 시간대 설정을 켠 다음 지금 동기화를 실행하세요. macOS에서는 「시스템 설정」→「일반」→「날짜와 시간」에서 자동 설정을 활성화할 수 있습니다. Android에서는 시스템 「설정」→「시스템」→「날짜 및 시간」으로 이동해 네트워크 제공 시간과 시간대를 모두 켜세요. Linux에서는 시스템 시간, 시간대, 시간 동기화 서비스가 모두 정상인지 확인해야 합니다.
-
원본 오류 기록하기
현재 연결을 끊고 로그 표시를 지운 다음 다시 연결해 보세요. x509, TLS, 대상 도메인이 포함된 전체 오류 행을 보관해야 합니다.
-
날짜와 시간대 확인
연도, 월, 일, 시각, 시간대를 확인하세요. 시계만 고치고 시간대를 수정하지 않으면 재부팅 후 다시 어긋날 수 있습니다.
-
시간 동기화 실행
시스템 자동 시간 설정을 활성화하고 수동으로 한 번 동기화를 실행하세요. 동기화에 실패하면 네트워크 시간 서비스에 정상적으로 접근할 수 있는 연결로 먼저 전환합니다.
-
클라이언트 재시작
v2rayN, v2rayNG 또는 v2flyNG를 완전히 종료한 뒤 코어를 다시 시작하세요. 이전 연결이 기존 핸드셰이크 상태를 계속 재사용하는 것을 막을 수 있습니다.
-
다른 기기에서 교차 확인
시간이 정확한 다른 기기에서 같은 설정을 테스트하세요. 한 기기에서만 실패한다면 해당 기기의 시간과 인증서 환경을 우선 점검합니다.
서버 주소·SNI·인증서 도메인 확인
서버 주소는 연결을 대상 호스트로 전달하고, SNI는 TLS 핸드셰이크 단계에서 서버에 어떤 인증서를 반환해야 하는지 알립니다. 두 값은 같을 수도 있고 다를 수도 있습니다. 예를 들어 서버 주소는 IP일 수 있지만 SNI에는 인증서가 포함하는 도메인을 입력해야 합니다. IP를 SNI에도 입력하면 공개 인증서가 보통 도메인만 포함하므로 도메인 불일치 오류가 발생하기 쉽습니다.
인증서 도메인을 확인할 때는 기본 도메인과 서브도메인을 구분해야 합니다. 인증서가 example.net을 포함한다고 해서 edge.example.net까지 반드시 포함하는 것은 아닙니다. 와일드카드 인증서가 1단계 서브도메인을 포함하더라도 더 깊은 단계까지 자동으로 포함하지는 않습니다. 노드의 host, SNI, serverName, 위장 도메인은 서로 다른 역할을 할 수 있으므로 문자열이 비슷하다는 이유만으로 모두 같은 값으로 입력하면 안 됩니다.
| 설정 항목 | 역할 | 올바른 입력 원칙 | 자주 발생하는 오류 |
|---|---|---|---|
| 주소 | DNS를 조회하고 연결을 수립하는 데 사용 | 노드에서 제공한 도메인 또는 IP 입력 | 프로토콜 접두사, 경로 또는 불필요한 공백을 붙여 넣음 |
| 포트 | 원격 서비스가 수신 대기하는 위치 지정 | 서버가 실제로 수신 대기하는 포트와 일치 | 로컬 프록시 포트 10808을 잘못 입력 |
| SNI | TLS 인증서와 가상 호스트 선택 | 인증서가 포함하며 서버가 요구하는 도메인 입력 | IP 또는 관련 없는 도메인을 입력 |
| Host | HTTP, WS 또는 기타 전송 계층 요청에 사용 | 노드 안내에 따라 입력하고 SNI와 억지로 합치지 않음 | 경로가 포함된 전체 URL을 입력 |
| 전송 보안 | TLS 또는 해당 보안 계층의 활성화 여부 결정 | 서버 배포 방식과 완전히 일치 | 서버는 TLS를 활성화했지만 클라이언트에서 none을 선택 |
오류: x509: cannot validate certificate for an IP because it does not contain any IP SANs
원인 및 해결: 클라이언트가 IP를 기준으로 인증서를 검증하지만 인증서에 해당 IP가 포함되어 있지 않습니다. 연결 주소에는 IP를 유지하고 SNI 또는 serverName에는 인증서에 해당하는 도메인을 입력하세요.
오류: EOF 또는 connection closed by peer
원인 및 해결: 원격 서버가 핸드셰이크 중 연결을 즉시 종료했습니다. 먼저 포트와 TLS 활성화 여부를 확인한 다음 SNI, 전송 방식, 네트워크가 연결을 잘못된 서비스로 보내고 있지 않은지 점검하세요.
구독 노드의 TLS 필드는 보통 구독 내용에서 생성됩니다. 수동으로 수정한 뒤 구독을 다시 업데이트하면 변경 사항이 덮어써질 수 있습니다. 같은 그룹의 모든 노드에서 동일한 오류가 발생한다면 먼저 구독을 업데이트하고 내용이 수정되었는지 확인하세요. 특정 노드 하나만 실패한다면 해당 노드의 인증서, 도메인 또는 서버 리스닝 설정 문제일 가능성이 높습니다.
allowInsecure의 용도 제대로 이해하기
allowInsecure는 클라이언트가 일부 인증서 검증을 건너뛸지 결정합니다. 공개 서비스를 정상적으로 연결할 때는 이 옵션을 끄고 코어가 인증서 체인, 유효 기간, 도메인을 계속 검사하도록 해야 합니다. 켠 뒤 일시적으로 연결되더라도 문제 지점이 인증서 검증 단계라는 의미일 뿐, SNI·인증서 배포·시스템 시간이 올바르다는 뜻은 아닙니다.
- 일상적인 사용: allowInsecure를 끄고 인증서, 시스템 시간, SNI를 수정하세요.
- 단기 진단: 위험을 충분히 이해하고 문제 계층을 확인해야 할 때만 임시로 테스트하고, 테스트가 끝나면 즉시 다시 끄세요.
- 자체 서명 환경: 검증을 장기간 건너뛰기보다 관리 대상 기기에 신뢰할 수 있는 루트 인증서를 올바르게 설치하세요.
- 구독 설정: 모든 노드에 이 옵션을 일괄 활성화하지 마세요. 노드마다 다른 인증서 문제를 가릴 수 있습니다.
REALITY 설정에서도 serverName 관련 문제가 발생할 수 있지만 보안 계층 매개변수를 일반 TLS 노드에 그대로 적용할 수는 없습니다. VLESS는 프록시 프로토콜일 뿐이며 TLS, XTLS Vision, REALITY는 전송 보안 설정에 해당합니다. 점검할 때는 먼저 노드가 어떤 보안 방식을 사용하는지 확인한 뒤 해당 필드를 검사하세요. 일반 TLS의 인증서 처리 방법을 다른 보안 계층에 기계적으로 적용하지 마세요.
v2rayN·v2rayNG·v2flyNG에서 항목별 재확인
데스크톱과 Android의 화면 이름은 다를 수 있지만 확인해야 할 필드는 같습니다. 주소, 포트, 전송 프로토콜, 전송 보안, SNI, Host, 경로, 코어 로그를 확인하세요. 먼저 원본 설정을 복사해 백업하고, 한 번에 한 항목만 수정한 뒤 다시 테스트해야 어떤 필드가 변화를 일으켰는지 판단할 수 있습니다.
-
코어 설정 확인
v2rayN에서 「설정」→「매개변수 설정」→「Core 유형」을 열고 노드가 예상한 코어로 처리되는지 확인하세요. 일반 Xray 설정을 호환되지 않는 코어로 잘못 전환하지 않도록 주의합니다.
-
노드 필드 편집
v2rayN에서 노드를 더블클릭해 편집 화면을 열고 주소, 포트, 전송 프로토콜, TLS, 보안 유형, SNI를 차례로 확인하세요. 주소 입력란에 https:// 접두사를 추가하지 마세요.
-
Android 설정 확인
v2rayNG 또는 v2flyNG의 설정 목록에서 대상 설정을 선택해 편집 화면으로 들어간 다음 「위장 도메인」, 「SNI」 또는 이에 해당하는 필드를 확인하세요. 저장한 뒤 연결을 다시 시작합니다.
-
구독 내용 업데이트
구독 그룹을 열고 업데이트를 실행한 뒤 실패한 노드의 필드가 변경되었는지 비교하세요. 구독 업데이트 실패와 노드 TLS 실패는 서로 다른 연결 과정이므로 로그도 따로 확인해야 합니다.
-
기존 연결 종료
클라이언트 프록시를 중지하고 기존 연결이 해제될 때까지 기다린 뒤 다시 시작하세요. 데스크톱에서는 시스템 프록시가 종료된 이전 인스턴스가 아니라 현재 로컬 리스닝 포트를 가리키는지도 확인합니다.
-
다른 노드와 비교
같은 구독의 다른 노드를 테스트하세요. 모든 노드가 실패하면 로컬 환경을 확인하고, 특정 노드만 실패하면 해당 노드의 인증서와 서버 설정을 집중적으로 점검합니다.
라우팅 분할은 일반적으로 원격 인증서 내용을 바꾸지 않지만 연결이 어떤 아웃바운드에서 시작되는지는 결정할 수 있습니다. 규칙이 노드 도메인을 사용할 수 없는 프록시 아웃바운드로 보내면 시간 초과나 연결 종료처럼 나타날 수 있습니다. 분할 라우팅의 영향을 배제하려면 잠시 직접 연결을 명시한 테스트 규칙으로 전환하세요. TLS가 복구된 것을 확인한 뒤 기존 라우팅 설정으로 되돌리고 매칭 로그를 항목별로 점검합니다.
자주 묻는 질문과 최종 점검 목록
시간, SNI, 인증서 검증을 확인했는데도 연결이 실패한다면 네트워크 계층과 서버를 계속 점검해야 합니다. DNS 오염으로 도메인이 잘못된 주소로 해석될 수 있고, 투명 프록시가 연결 경로를 바꿀 수도 있으며, 서버 리버스 프록시가 갱신된 인증서를 불러오지 못했을 수도 있습니다. 이때는 UUID를 반복해서 바꾸기보다 해석 결과, 연결 포트, 서버 로그를 함께 확인해야 합니다.
휴대폰은 연결되는데 컴퓨터에서 계속 인증서 시간 오류가 표시되나요?
먼저 컴퓨터의 연도, 시간대, 자동 시간 동기화를 확인하세요. 동기화가 끝나면 v2rayN을 완전히 종료하고 코어를 다시 시작해 테스트합니다. 노드 연결만 끊었다가 바로 다시 연결하지 마세요.
SNI를 비워 두면 클라이언트가 자동으로 판단하나요?
연결 주소가 인증서 도메인과 같을 때는 일부 설정에서 주소를 기본 serverName으로 사용할 수 있습니다. 주소가 IP, 앞단 도메인 또는 특수 배포 진입점이라면 노드 안내에 따라 SNI를 명시적으로 입력해야 합니다.
구독 업데이트 후 모든 노드에서 동시에 핸드셰이크가 실패하면 어떻게 하나요?
먼저 시스템 시간을 확인한 다음 구독에서 전송 보안, SNI 또는 포트가 변경되었는지 살펴보세요. 여러 기기에서 동시에 같은 오류가 발생했다면 보통 설정 제공자가 인증서와 서버 배포 상태를 확인해야 합니다.
allowInsecure를 켜면 사용할 수 있는데 계속 켜 둬도 되나요?
권장하지 않습니다. 단시간 문제를 파악할 때만 사용하는 옵션입니다. 엄격한 검증을 다시 활성화하고 도메인 일치, 인증서 체인 또는 시간 문제를 수정하세요.
TLS 오류가 VMess·VLESS 키와 관련 있나요?
인증서 검증은 프록시 프로토콜 인증보다 먼저 수행됩니다. 로그가 x509, certificate 또는 server name을 명확히 가리킨다면 먼저 TLS를 처리하세요. 핸드셰이크가 성공한 뒤 UUID, 암호화 방식, 흐름 제어 매개변수를 확인합니다.
- 기기의 날짜, 시간, 시간대가 정확하고 자동 동기화가 정상적으로 완료되었는지 확인하세요.
- 노드 주소에 프로토콜 접두사, 경로, 공백 또는 잘못 복사된 내용이 없는지 확인하세요.
- 원격 포트가 서버 리스닝 포트와 일치하며 10808 같은 로컬 포트를 잘못 입력하지 않았는지 확인하세요.
- SNI가 인증서에 포함된 도메인인지, 인증서가 포함하지 않는 IP를 직접 입력하지 않았는지 확인하세요.
- TLS, WS, TCP, gRPC 등의 전송 매개변수가 서버와 일치하는지 확인하세요.
- allowInsecure를 끈 상태로 유지하고 로그에서 실제 인증서 오류를 확인하세요.
- 구독 업데이트가 수동 수정 내용을 덮어쓰지 않았는지 확인하고, 필요하면 설정을 복사해 별도로 테스트하세요.
- 다른 기기와 다른 노드를 비교해 로컬 문제인지 서버 문제인지 구분하세요.
점검 순서는 일정하게 유지하세요. 먼저 로그를 읽고, 시간을 동기화한 다음 주소·포트·SNI·전송 보안을 확인하고, 마지막으로 인증서 체인과 서버 상태를 점검합니다. 이 순서를 따르면 인증서 문제를 노드 인증, 시스템 프록시 또는 라우팅 규칙 문제로 잘못 판단하는 일을 줄이고 불필요한 일괄 수정도 피할 수 있습니다.