v2rayN, v2rayNG 또는 v2flyNG 로그에서 인증서 검증 실패가 확인된 경우에 적합합니다. 먼저 구체적인 오류를 확인하고, 시스템 시간을 동기화한 뒤 TLS의 SNI와 인증서 이름을 대조하고 서버 인증서 체인을 점검하세요. 인증서 검증은 계속 활성화하고 설정은 한 번에 하나씩 변경해, 일시적인 연결 성공을 완전한 해결로 착각하지 않도록 합니다.
먼저 로그 확인: 인증서 오류와 연결 시간 초과 구분하기
노드에 연결할 수 없다고 해서 반드시 TLS 문제인 것은 아닙니다. TLS 핸드셰이크는 하위 연결이 성립한 후, 프록시 프로토콜 데이터를 전송하기 전에 이루어집니다. 로그에 x509, certificate 또는 구체적인 핸드셰이크 오류가 명시된 경우에만 인증서 문제를 조사하세요. context deadline exceeded만 있다면 대기 시간이 초과되었다는 뜻이며, 이것만으로 인증서 만료를 판단할 수는 없습니다.
v2rayN 기본 창 아래쪽의 로그 영역을 확인하세요. 사용 중인 버전에서 로그가 별도 메뉴에 있다면 「로그」를 연 다음 다시 연결합니다. v2rayNG는 기본 화면의 사이드 메뉴에서 「로그」를 열고, 서비스를 중지했다가 다시 시작해 새로 생성된 기록을 확인하세요. v2flyNG에서도 이번 연결의 코어 로그를 확인해야 하며, 이전 실패 기록을 현재 결과로 착각하지 않도록 합니다. 버전에 따라 메뉴 위치가 다를 수 있으므로 실제 화면을 기준으로 확인하세요.
- 가장 바깥쪽의 “연결 실패” 문구만 캡처하지 말고 클라이언트 버전, 현재 코어 종류, 연결 시간, 구체적인 하위 오류를 기록하세요.
- 브라우저의 백그라운드 요청을 잠시 중지한 뒤 다시 연결해 여러 오류가 뒤섞여 잘못 판단하는 일을 줄이세요.
- 로그를 공유하기 전에 구독 링크, 인증 정보, 서버 주소를 가리세요. 오류 유형과 타임스탬프, 가려진 도메인 간의 대응 관계는 남겨 두세요.
x509 오류 문구로 점검 방향 파악하기
아래는 실제로 자주 나타나는 오류 문구입니다. 전체 로그에는 코어 접두어, 인증서 이름 또는 날짜가 추가될 수 있고, 코어 버전에 따라 표현이 달라질 수도 있습니다. 가장 안쪽에 표시된 원인을 확인하세요. 특히 유효기간 오류는 로그에 나온 현재 시간과 인증서 유효기간을 함께 살펴야 합니다. ‘만료’라는 문구만 보고 노드를 교체해 달라고 요청해서는 안 됩니다.
오류: x509: certificate has expired or is not yet valid
원인 및 해결 방법: 클라이언트에서 인증서가 유효기간 밖에 있다고 판단한 상태입니다. 먼저 시스템 시간을 확인하세요. 시간이 정확한데도 같은 오류가 반복되면 서버 관리자에게 인증서의 유효 시작일과 종료일, 갱신 후 배포 상태를 확인해 달라고 요청하세요.
오류: x509: certificate signed by unknown authority
원인 및 해결 방법: 인증서 체인을 신뢰할 수 있는 루트 인증서까지 연결할 수 없는 상태입니다. 중간 인증서 누락, 사설 인증서 또는 시스템 신뢰 저장소 문제가 원인일 수 있습니다. 인증서 발급처와 서버의 전체 인증서 체인을 확인하세요. 관리 대상 기기라면 네트워크의 인증서 대체 정책도 점검해야 합니다.
오류: x509: cannot validate certificate for 192.0.2.1 because it doesn't contain any IP SANs
원인 및 해결 방법: 클라이언트가 해당 IP 주소에 대응하는 IP 유형 SAN이 없는 인증서를 검증하고 있습니다. 이 주소는 문서 예시일 뿐입니다. 실제로는 서버에서 안내한 인증서 적용 TLS 이름을 입력해야 하며, 임의의 도메인으로 바꾸면 안 됩니다.
오류: remote error: tls: handshake failure
원인 및 해결 방법: 원격 서버가 TLS 핸드셰이크를 중단한 상태로, 로컬의 인증서 검증 실패가 아닐 수도 있습니다. SNI, 포트, TLS 설정, 서버의 접속 요건을 확인한 뒤 관리자에게 같은 시간대의 서버 로그를 대조해 달라고 요청하세요.
로그에 인증서가 특정 이름에는 유효하지만 현재 이름에는 적용되지 않는다고 나온다면 SNI와 검증 이름을 먼저 확인하세요. EOF만 표시되거나 연결이 재설정된 경우에는 해당 포트의 서비스가 현재 핸드셰이크를 허용하지 않는 것일 수도 있습니다. 이를 곧바로 시스템 시간 문제로 단정하지 마세요.
시스템 시간 동기화: 시계를 바로잡은 뒤 인증서 만료 여부 확인하기
인증서에는 유효 시작 시간과 만료 시간이 있습니다. 기기 시간이 이 구간을 벗어나면 서버 설정이 정상이어도 인증서가 아직 유효하지 않거나 이미 만료된 것으로 처리됩니다. 듀얼 부팅, 메인보드 배터리 이상, 장기간 오프라인 상태, 날짜 수동 변경 등으로 시간 오차가 생길 수 있습니다. 시간대는 주로 표시 방식에 영향을 줍니다. 시간대만 바로잡아도 시스템의 실제 시각이 정확해지는 것은 아닙니다.
-
날짜와 시간 확인
먼저 연도, 월, 일, 시각을 확인하세요. Windows PowerShell에서
Get-Date -Format o를 실행해 시간대 오프셋이 포함된 시각을 확인하고 신뢰할 수 있는 시계와 비교합니다. -
시계 동기화
Windows 11에서 「설정」→「시간 및 언어」→「날짜 및 시간」을 열고 「시간 자동 설정」을 켠 다음, 「추가 설정」에서 「지금 동기화」를 누르세요. 동기화에 실패하면 먼저 네트워크 또는 시간 서비스 문제를 해결합니다.
-
Android 설정 확인
Android에서는 보통 「설정」→「시스템」→「날짜 및 시간」에서 「시간 자동 설정」과 「시간대 자동 설정」을 켭니다. 제조사에 따라 메뉴가 다를 수 있으므로 설정에서 “날짜 및 시간”을 검색하고 표시된 시간이 갱신됐는지 확인하세요.
-
다시 연결
동기화가 끝나면 클라이언트 연결을 중지했다가 다시 시작하고 새 로그를 확인하세요. 현재 시간이 정확한데 인증서 만료일이 실제로 지났다면 서버에서 인증서를 갱신하고 다시 불러와야 합니다.
Windows에서는 w32tm /query /status 명령으로 시간 동기화 출처와 상태도 확인할 수 있습니다. 서비스가 실행 중이 아니라는 오류가 나오면 프록시 코어를 반복해서 재시작하지 말고 먼저 Windows Time 서비스를 점검하세요. 조직 정책으로 관리되는 기기라면 지정된 시간 원본을 바로잡도록 관리자에게 문의하고 관리 정책을 임의로 덮어쓰지 마세요.
SNI와 위장 도메인: 주소, 이름, Host를 각각 확인하기
SNI는 TLS 핸드셰이크에서 서버에 접속 대상 이름을 알리는 확장 기능입니다. 서버는 이를 바탕으로 인증서나 가상 호스트를 선택할 수 있습니다. 일반적으로 입력한 TLS 서버 이름은 인증서 이름 검증에도 사용되지만, 일부 코어에서는 검증 이름을 별도로 지정할 수 있으므로 이름을 명시적으로 덮어쓰는 설정이 있는지도 확인해야 합니다. 서버 안내의 “위장 도메인”은 일관된 설정 항목명이 아니므로 SNI, HTTP Host 또는 다른 전송 매개변수 중 무엇을 의미하는지 확인하세요.
| 설정 항목 | 실제 역할 | 확인할 사항 |
|---|---|---|
| 주소 및 포트 | 연결할 서버 접속 지점을 결정합니다. | 주소는 도메인 또는 IP일 수 있습니다. 포트는 서버 설정과 일치해야 하며, TLS를 사용한다고 무조건 443으로 바꾸면 안 됩니다. |
| SNI / serverName | 일반적으로 TLS 이름을 전송하며 인증서 이름 검증 기준으로도 사용됩니다. | 서버에서 지정한 도메인만 입력하고 프로토콜 접두어, 경로, 포트는 제외하세요. |
| 인증서 SAN | 검증이 허용되는 DNS 이름 또는 IP 주소를 나열합니다. | 검증 이름은 SAN에 포함되어야 합니다. 와일드카드 *.example.com은 일반적으로 example.com 또는 더 깊은 하위 도메인까지 포함하지 않습니다. |
| WebSocket Host | TLS 이후의 HTTP 요청을 라우팅하는 데 사용됩니다. | 전송 설정에 맞게 입력하세요. Host를 바꿔도 그 전에 발생한 인증서 이름 불일치는 해결되지 않습니다. |
| WebSocket Path | HTTP 업그레이드 요청에 사용할 경로를 지정합니다. | 서버에서 안내한 경로를 그대로 사용하세요. 경로 오류는 보통 인증서 검증 문제와 관련이 없습니다. |
v2rayN에서 대상 노드를 더블 클릭해 노드 편집 창을 연 다음 TLS 영역의 「SNI」 또는 이에 해당하는 서버 이름 항목을 확인하세요. v2rayNG에서는 노드 오른쪽의 편집 아이콘을 눌러 TLS 설정에서 「SNI」를 확인합니다. 버전에 따라 항목명이 다를 수 있으므로 TLS 영역을 기준으로 찾고, 전송 설정의 「Host」와 같은 항목으로 취급하지 마세요. v2flyNG에서도 현재 코어와 노드 프로토콜에 맞는 항목을 사용해야 합니다.
예를 들어 서버에서 TLS 이름으로 edge.example.com을 사용하라고 명시했다면 이 항목에 https://edge.example.com/을 입력하면 안 됩니다. 이 도메인은 형식 설명을 위한 예시이며 실제 노드 매개변수가 아닙니다. 서버 주소가 IP라고 해서 반드시 잘못된 것은 아닙니다. 올바른 접속 대상으로 연결하고, TLS에는 인증서에 포함된 승인된 이름을 사용한다면 주소 입력란까지 해당 도메인으로 바꿀 필요는 없습니다.
요점: TLS 이름을 먼저 확인한 다음 전송 설정을 점검하세요
로그에 이름 불일치가 명확히 표시되면 서버에서 안내한 SNI와 인증서 SAN을 먼저 대조하세요. 인증서 검증을 통과한 뒤에도 HTTP 또는 업그레이드 오류가 발생할 때만 Host와 경로를 확인합니다.
인증서 검증 유지: 서버 체인과 네트워크 환경 확인
“인증서 검증 건너뛰기”는 allowInsecure 또는 비슷한 옵션으로 표시될 수 있습니다. 이 기능을 켜면 클라이언트가 인증서 체인이나 이름을 제대로 확인하지 않을 수 있습니다. 그렇다고 서버 신원이 확인되거나 기존 설정 문제가 해결된 것은 아닙니다. 문제를 해결하는 동안에는 이 옵션을 끈 상태로 두세요. 이미 켰다면 다시 검증을 활성화하고 새로 표시되는 정확한 오류를 바탕으로 원인을 찾으세요.
- 특정 노드 하나에서만 발생: 관리자에게 인증서 유효기간, 전체 중간 인증서 체인, SNI에 해당하는 가상 호스트, 갱신 후 서버의 인증서 재적용 여부를 확인해 달라고 요청하세요.
- 여러 노드에서 동시에 발생: 먼저 기기의 시계, 시스템 업데이트, 현재 네트워크를 확인하세요. 회사 네트워크나 보안 소프트웨어의 HTTPS 검사로 인증서 신뢰 경로가 달라질 수 있지만, 근거 없이 오류만 보고 차단이 있다고 단정해서는 안 됩니다.
- 네트워크를 바꾸면 해결됨: 기존 네트워크에서 웹 인증이 필요한지, DNS가 예상한 접속 지점으로 연결되는지, 네트워크 정책이 TLS에 영향을 주는지 확인하세요. 연결을 위해 출처가 불분명한 루트 인증서를 설치하지 마세요.
- 사설 인증서를 사용하는 경우: 명확한 관리 요건이 있고 발급자와 인증서 출처를 확인할 수 있을 때만 관리자 지침에 따라 신뢰 설정을 구성하세요. 일반 구독 사용자는 먼저 제공업체에 설정을 문의해야 합니다.
이 문서는 일반적인 TLS 인증서 검증을 다룹니다. 노드의 보안 유형이 REALITY라면 서버에서 안내한 서버 이름, 공개 키, 짧은 ID, 클라이언트 코어의 지원 여부를 추가로 확인해야 합니다. 일반 인증서 갱신 절차를 그대로 적용해서는 안 됩니다. v2rayNG는 Xray 코어를, v2flyNG는 V2Fly 코어를 사용하므로 지원되는 프로토콜과 보안 매개변수가 완전히 같지 않습니다. 클라이언트 이름만 바꾸면 설정이 호환된다고 볼 수 없습니다.
연결 복구 후 확인 및 자주 묻는 질문
설정을 변경할 때마다 새로 연결하고 새 로그를 확인하세요. 기존 연결이 계속 사용 중이거나 구독 업데이트가 수동 설정을 덮어쓰면 결과가 앞뒤와 맞지 않아 보일 수 있습니다. 시간, SNI, DNS, 라우팅을 한꺼번에 바꾸지 마세요. 변경 항목과 새 오류를 단계별로 기록해야 어떤 설정이 효과가 있었는지 확인할 수 있습니다.
시간 동기화를 마쳤는데도 인증서가 만료됐다고 나오는 이유는 무엇인가요?
오류에 표시된 현재 시간과 인증서 만료 시간을 비교하세요. 기기 시간이 정확하고 인증서가 실제로 만료됐다면 오류 내용에서 민감 정보를 가리고 발생 시각과 함께 관리자에게 전달해 갱신 결과와 현재 사용 중인 인증서를 확인해 달라고 요청하세요.
브라우저에서 도메인은 정상적으로 열리는데 클라이언트에서는 왜 오류가 발생하나요?
브라우저는 다른 포트나 접속 지점을 사용하거나 별도의 신뢰 저장소를 이용할 수 있습니다. 노드 주소, 포트, SNI를 대조하세요. 브라우저에서 홈페이지가 열린다는 사실만으로 프록시 접속 지점의 인증서까지 정상이라고 판단할 수는 없습니다.
SNI를 바꾼 뒤에는 연결되지만 구독을 업데이트하면 다시 실패할 때는 어떻게 하나요?
노드를 다시 편집해 해당 항목이 구독 업데이트로 덮어쓰였는지 확인하세요. 구독의 TLS 매개변수를 제공업체에 알려 수정해 달라고 요청하세요. 임시 비교가 필요하면 별도의 테스트 설정을 유지하되, 이후에는 수정된 구독을 기준으로 사용해야 합니다.
인증서 검증을 꺼야 연결된다면 문제 해결이 끝난 건가요?
아닙니다. “인증서 검증 건너뛰기”를 다시 끄고 오류 유형에 따라 시간, 이름 또는 신뢰 체인을 바로잡으세요. 정상적인 검증을 켠 상태에서도 다시 연결되어야 기존 인증서 문제가 해결된 것입니다.
- 시스템의 자동 시간 동기화가 작동하고 날짜와 시간대가 올바르게 표시되는지 확인하세요.
- 노드의 TLS 이름이 서버 안내와 일치하고 인증서 검증을 건너뛰지 않는지 확인하세요.
- 연결을 중지했다가 다시 시작하고 새 로그에 같은 종류의 인증서 오류가 더 이상 나타나지 않는지 확인하세요.
- 문제가 계속되면 클라이언트 및 코어 버전, 발생 시각, 확인한 항목, 민감 정보를 가린 구체적인 오류를 전달하세요. 구독 전체를 그대로 보내지 마세요.