V2Ray 또는 Xray 커널이 암호화 연결을 수립할 때는 먼저 TCP나 다른 하위 전송을 완료한 다음 TLS 핸드셰이크를 진행합니다. 인증서 유효 기간, 인증서 도메인, 시스템 시간, SNI, TLS 버전, 클라이언트 지문 중 하나라도 일치하지 않으면 프록시 요청을 보내기 전에 연결이 종료될 수 있습니다. 따라서 브라우저의 연결 실패 표시, v2rayN의 사용할 수 없음 측정 결과, v2rayNG 로그의 인증서 오류만으로 서버 포트가 닫혔다고 단정할 수 없습니다.
이 글은 TLS handshake, x509, certificate, serverName 또는 SNI 오류가 발생한 v2rayN, v2rayNG, v2flyNG 사용자를 위한 내용입니다. ‘로그 확인, 시간 점검, 도메인 대조, 매개변수 확인, 재테스트’ 순서로 진행하면 문제가 로컬 기기, 노드 설정, 서버 인증서 체인 중 어디에 있는지 판단할 수 있습니다.
먼저 로그로 TLS 오류 유형 구분하기
TLS 문제를 해결할 때 첫 단계는 지연 측정을 반복하는 것이 아니라 전체 로그를 한 번 저장하는 것입니다. v2rayN은 메인 화면의 로그 영역에서 커널 출력을 확인할 수 있으며, 「설정」→「매개변수 설정」에서 로그 수준도 확인할 수 있습니다. v2rayNG와 v2flyNG는 사이드 메뉴의 로그 페이지를 연 다음 다시 한 번 연결하세요. 점검할 때는 최초로 나타난 오류 행을 기록해야 합니다. 이후의 연결 종료와 재시도 실패는 대개 연쇄적으로 발생한 결과입니다.
오류: x509: certificate has expired or is not yet valid
원인과 해결: 기기 시간이 인증서 유효 기간과 맞지 않거나 서버 인증서가 실제로 만료된 상태입니다. 먼저 시스템 날짜, 시간, 시간대를 동기화한 뒤 인증서의 시작·종료 시간을 확인하세요.
오류: x509: certificate is valid for example.com, not edge.example.net
원인과 해결: 클라이언트가 검증하는 serverName과 인증서 도메인이 일치하지 않습니다. SNI를 인증서가 포함하는 전체 도메인으로 변경하고 서버 IP를 그대로 입력하지 마세요.
오류: tls: failed to verify certificate
원인과 해결: 인증서 체인, 발급 관계 또는 로컬 신뢰 환경 검증에 실패했습니다. 먼저 시간 문제를 배제한 뒤 서버가 전체 인증서 체인을 전송하는지 확인하세요.
오류: remote error: tls: handshake failure
원인과 해결: 원격 서버가 핸드셰이크 단계에서 연결을 능동적으로 종료했습니다. SNI, ALPN, TLS 지문, 전송 계층 설정을 대조하고 올바른 포트에 연결했는지 확인하세요.
오류: context deadline exceeded
원인과 해결: 제한 시간 안에 핸드셰이크가 완료되지 않았습니다. 먼저 네트워크 연결성과 포트를 확인한 뒤 앞선 로그와 함께 인증서 문제인지 판단하세요.
EOF, connection reset by peer, 시간 초과는 TLS에만 해당하는 오류가 아닙니다. 서버 프로세스가 수신 대기 중이지 않거나, 전송 경로가 맞지 않거나, 중간 네트워크 장비가 연결을 먼저 끊어도 발생할 수 있습니다. 로그에 x509, certificate, serverName 또는 명확한 TLS 핸드셰이크 문구가 함께 나타날 때만 인증서 체인을 우선 점검하세요.
- 가장 먼저 나타난 오류를 찾고 로그의 마지막 줄만 복사하지 마세요.
- 노드 주소, 포트, 전송 방식, TLS 활성화 여부와 SNI를 기록하되 구독 링크는 공개하지 마세요.
- 같은 노드는 연속으로 두 번만 테스트하면 됩니다. 지나치게 자주 재연결하면 로그가 중복 정보로 묻힙니다.
- 여러 노드에서 같은 기기로 동시에 인증서 시간 오류가 발생한다면 먼저 기기 시계를 확인하세요.
시스템 시간과 시간대가 첫 번째 점검 항목입니다
인증서에는 ‘유효 시작’과 ‘만료’라는 두 시점이 포함됩니다. 기기는 로컬 시스템 시계로 현재 시각이 유효 구간에 들어가는지 판단합니다. 날짜는 맞지만 시간대가 틀렸거나, 절전 모드 후 시계가 틀어졌거나, 가상 머신이 호스트 시간과 동기화되지 않으면 not yet valid 또는 expired 오류가 발생할 수 있습니다. 점검할 때는 작업 표시줄의 시·분만 보지 말고 연도, 월, 일, 시간대까지 확인해야 합니다.
-
날짜 확인
연도, 월, 일이 모두 정확한지 확인하세요. 기기가 장시간 절전 모드에서 복귀했다면 시스템이 네트워크 시간 동기화를 완료할 때까지 기다리세요.
-
시간대 확인
Windows에서 「설정」→「시간 및 언어」→「날짜 및 시간」을 열고 시간대가 현재 위치와 일치하는지 확인한 뒤 자동 시간 설정을 활성화하세요.
-
지금 동기화
같은 페이지에서 ‘지금 동기화’를 클릭하세요. 안드로이드 기기는 시스템 「설정」→「시스템」→「날짜 및 시간」으로 이동해 자동 시간 설정과 자동 시간대 설정을 켜세요.
-
커널 재시작
현재 연결을 중지하고 클라이언트 커널을 종료한 뒤 다시 시작하세요. 그런 다음 기존 노드에 대해 지연 측정과 실제 웹페이지 접속을 한 번씩 진행하세요.
Windows에서는 관리자 터미널에서 시간 서비스 상태를 조회하고 동기화를 실행할 수도 있습니다. Linux에서는 timedatectl로 로컬 시간, UTC 시간, 시간대, NTP 상태를 확인할 수 있습니다. 명령이 성공적으로 반환되면 V2Ray 또는 Xray 커널을 다시 시작해 이전 핸드셰이크 상태를 기존 연결이 계속 사용하지 않도록 하세요.
w32tm /query /status
w32tm /resync
timedatectl status
sudo timedatectl set-ntp true노드 주소, SNI, 인증서 도메인 확인
노드의 ‘주소’와 TLS의 serverName은 서로 다른 역할을 합니다. 주소는 DNS 조회와 네트워크 연결 수립에 사용되고, serverName은 TLS ClientHello의 SNI 확장에 포함되며 일반적으로 인증서 도메인 검증 대상이 됩니다. 서버 주소는 IP 또는 접속 도메인일 수 있지만 SNI는 서버 인증서가 포함하는 도메인과 일치해야 합니다.
예를 들어 클라이언트 연결 주소가 203.0.113.20이고 인증서가 edge.example.net만 포함한다면 주소는 IP로 유지해도 되지만 SNI에는 edge.example.net을 입력해야 합니다. SNI를 비워 두면 커널이 주소를 바탕으로 검증 이름을 추정할 수 있습니다. 주소가 IP인데 인증서에는 도메인만 포함된 경우 ‘인증서는 특정 도메인에 유효하지만 현재 주소에는 적용되지 않음’과 같은 오류가 발생하기 쉽습니다.
| 설정 항목 | 역할 | 올바른 확인 방법 |
|---|---|---|
| 주소 Address | 실제로 연결할 호스트를 결정 | 도메인이 해석되는지 또는 IP가 서버와 일치하는지 확인 |
| 포트 Port | 연결할 수신 대기 포트를 결정 | 서버가 해당 포트에서 올바른 TLS 인바운드를 제공하는지 확인 |
| SNI / serverName | 가상 호스트를 선택하고 인증서 검증에 참여 | 인증서가 포함하는 전체 도메인을 입력하고 프로토콜과 경로는 붙이지 않기 |
| Host | HTTP, WebSocket 등의 전송 계층에서 사용 | 서버 리버스 프록시 규칙에 따라 입력하며 SNI와 자동으로 같아지는 것은 아님 |
| ALPN | 애플리케이션 계층 프로토콜을 협상 | 서버가 요구하는 값을 사용하고 명확한 요구가 없다면 임의로 덮어쓰지 않기 |
-
노드 열기
v2rayN 메인 화면에서 대상 노드를 선택하고 편집 창을 여세요. v2rayNG 또는 v2flyNG에서는 해당 설정의 편집 메뉴를 여세요.
-
매개변수 기록
주소, 포트, 전송 프로토콜, TLS 활성화 여부, SNI, Host, ALPN, 지문을 기록하고 수정 전 원래 값을 보관해 되돌릴 수 있게 하세요.
-
도메인 대조
SNI와 오류에 표시된 인증서 도메인을 글자 단위로 비교하세요. 특히 불필요한 공백, 한글 문장 부호, 잘못된 접미사, 누락된 서브도메인을 확인해야 합니다.
-
저장 후 재테스트
저장한 뒤 커널을 다시 시작하고 이 노드 하나만 테스트하세요. 오류가 도메인 불일치에서 연결 시간 초과로 바뀌었다면 주소 해석과 포트 연결성을 별도로 확인하세요.
결론: 연결 주소에 접속된다고 인증서 이름이 올바른 것은 아닙니다
TCP 연결은 완료됐지만 x509가 도메인 불일치를 명확히 보고한다면 먼저 SNI를 수정하세요. 로컬 SOCKS 또는 HTTP 포트를 변경해도 원격 인증서 검증 결과는 달라지지 않습니다.
인증서 만료, 인증서 체인 누락, 서버 설정 오류 판단
시스템 시간과 SNI가 모두 올바른데도 인증서 검증 실패가 계속되면 서버 인증서 자체를 확인해야 합니다. 흔한 원인은 인증서 만료, 갱신 후 서비스 프로세스가 새 인증서를 다시 불러오지 않은 경우, 새 인증서가 잘못된 가상 호스트에 배포된 경우, 서버가 사이트 인증서만 보내고 중간 인증서를 누락한 경우입니다.
오류: x509: certificate signed by unknown authority
원인과 해결: 클라이언트가 신뢰할 수 있는 루트 인증서까지 완전한 체인을 구성하지 못했습니다. 서버에는 전체 인증서 체인을 배포하고 로컬 시스템의 인증서 저장소도 정상적으로 업데이트해야 합니다.
오류: x509: certificate has expired
원인과 해결: 시스템 시간이 정확한데 인증서 만료 시각이 이미 지났습니다. 갱신 후에는 실제로 TLS를 수신하는 서비스가 인증서 파일을 다시 불러오도록 해야 합니다.
오류: tls: bad certificate
원인과 해결: 원격 서버가 클라이언트가 제공한 인증서 또는 양방향 인증 매개변수를 거부했습니다. 해당 인바운드에서 클라이언트 인증서 인증을 활성화했는지 확인하고 그에 맞는 설정을 사용하세요.
같은 도메인을 일반 브라우저로 접속해도 인증서 이상이 표시된다면 서버 인증서 배포 문제일 가능성이 큽니다. 브라우저는 정상인데 V2Ray/Xray만 실패한다면 연결 포트, SNI, ALPN, 전송 계층을 계속 비교하세요. 브라우저 접속 성공은 브라우저가 연결한 도메인과 포트가 사용 가능하다는 뜻일 뿐, 노드 설정의 다른 포트가 같은 인증서를 사용한다는 의미는 아닙니다.
- 인증서의 유효 시작·만료 시간이 현재 시각을 포함하는지 확인하세요.
- 인증서의 주체 대체 이름에 SNI로 사용하는 전체 도메인이 포함되어 있는지 확인하세요.
- 리버스 프록시 또는 TLS 종료 서비스가 전체 인증서 체인을 전송하는지 확인하세요.
- 인증서 갱신 후 실제 수신 프로세스가 설정을 다시 불러왔는지 확인하세요.
- 포트 443 또는 사용자 지정 포트를 다른 서비스가 점유하고 있지 않은지 확인하세요.
- 구독 업데이트가 이전 도메인과 이전 포트를 클라이언트에 다시 기록하지 않는지 확인하세요.
allowInsecure, 지문, ALPN 설정 방법
allowInsecure는 클라이언트가 인증서 유효성과 도메인 검증을 건너뛸지 결정합니다. v2rayN, v2rayNG, v2flyNG에서는 ‘인증서 검증 건너뛰기’ 또는 비슷한 의미의 스위치로 표시될 수 있습니다. 공개적으로 신뢰되는 인증서를 정상적으로 사용할 때는 이 옵션을 끄고 커널이 인증서 체인과 serverName을 계속 검증하도록 해야 합니다.
이 옵션을 일시적으로 켜면 문제 범위를 좁히는 데 도움이 됩니다. 켠 직후 연결된다면 네트워크 주소, 포트, 주요 전송 경로는 대체로 접근 가능하고 문제는 인증서 유효 기간, 도메인 일치 여부 또는 신뢰 체인에 집중되어 있다는 뜻입니다. 단, 이 결과는 진단용일 뿐이므로 이후 엄격한 검증을 다시 활성화하고 실제 원인을 수정해야 합니다.
- allowInsecure: 인증서 검증에 영향을 주지만 잘못된 SNI를 수정하지 않으며 만료된 인증서를 갱신하지도 않습니다.
- fingerprint: TLS ClientHello 특성을 조정하는 데 사용됩니다. 예를 들어 설정에서 요구하는
chrome이 있습니다. 인증서 지문과는 다르며 인증서 체인 검증을 대신할 수 없습니다. - ALPN: 일반적인 값으로
h2와http/1.1이 있으며 서버 인바운드와 전송 방식에 맞아야 합니다. - TLS 버전: 클라이언트와 서버가 공통으로 지원하는 버전이 있어야 합니다. 오래된 시스템 환경에서는 최신 TLS 협상이 완료되지 않을 수 있습니다.
지문을 변경하기 전에 노드 제공자 또는 자체 구축 서비스의 설정에서 무엇을 요구하는지 먼저 확인하세요. 지문, ALPN, SNI를 한꺼번에 바꾸면 테스트 결과를 비교할 수 없게 됩니다. 올바른 방법은 원본 설정을 보관하고 한 번에 필드 하나만 변경한 뒤 커널을 다시 시작해 해당 로그를 저장하는 것입니다.
테스트 1: 엄격한 인증서 검증을 유지하고 시스템 시간만 수정
테스트 2: 다른 매개변수는 유지하고 SNI만 수정
테스트 3: 엄격한 검증을 복원하고 서버가 요구하는 지문만 조정
테스트 4: ALPN과 전송 계층을 확인한 뒤 다시 연결결론: 검증 건너뛰기는 문제 범위를 좁힐 때만 사용
인증서 검증을 끈 뒤 연결이 복구되더라도 인증서 유효 기간, 전체 체인, SNI를 다시 점검해야 합니다. 임시 진단용 스위치를 노드 설정에 계속 남겨 두지 마세요.
고정된 순서로 재테스트해 여러 설정의 상호 간섭을 피하세요
수정을 완료한 뒤 기존 연결을 중지하고 커널을 다시 시작해야 합니다. 화면에서 저장만 하면 이미 연결되었거나 재시도 중인 연결이 중단되지 않을 수 있습니다. 재테스트할 때는 먼저 노드 지연 측정을 한 번 실행하고, 일반 HTTPS 페이지에 접속한 다음, 로그에 같은 첫 번째 오류가 계속 나타나는지 확인하세요.
-
시간 동기화
시스템 시간 오차를 정상 범위로 줄이고 날짜, 시간대, 자동 시간 동기화 상태가 올바른지 확인하세요.
-
주소 확인
노드 도메인이 해석되는지, 서버 주소와 포트를 잘못 복사하지 않았는지, TLS 서비스가 실제로 대상 포트에서 수신 대기 중인지 확인하세요.
-
SNI 수정
serverName이 인증서가 포함하는 도메인과 일치하도록 설정하세요. 해당 필드에는 도메인만 입력하고
https://, 포트, 경로는 넣지 마세요. -
인증서 체인 검증
유효 기간, 중간 인증서, 실제 로드 상태를 확인하세요. 인증서를 갱신한 뒤 수신 서비스가 새 인증서를 사용하는지 확인해야 합니다.
-
매개변수 단계별 수정
필요할 때 지문과 ALPN을 확인하되 매 라운드마다 한 항목만 변경하고 변경 전후의 로그 결과를 보관하세요.
-
엄격한 검증 복원
진단이 끝나면 인증서 검증 건너뛰기 옵션을 끄고 커널을 다시 시작한 뒤 최종 연결 테스트를 진행하세요.
데스크톱과 안드로이드에서 같은 네트워크와 같은 노드가 동시에 실패하고 두 기기의 시간이 모두 정확하다면 서버 인증서와 SNI를 우선 확인하세요. 한 기기에서만 실패한다면 해당 기기의 시스템 시간, 클라이언트 설정, 시스템 인증서 환경을 먼저 비교하세요. 모든 TLS 노드가 실패하지만 비TLS 테스트 연결은 정상이라면 로컬 보안 소프트웨어, 네트워크 출구, 시스템 TLS 환경이 핸드셰이크 경로를 변경하고 있는지도 확인해야 합니다.