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

이 글의 핵심

v2rayN에서 일반 TLS 노드에 연결할 때 인증서 만료, 도메인 불일치 또는 알 수 없는 발급 기관 오류가 발생하는 경우를 다룹니다. 먼저 구독 다운로드 오류와 노드 핸드셰이크 오류를 구분한 다음, 시스템 시간, 서버 이름, 서버 인증서 체인 순으로 확인하세요. 마지막으로 allowInsecure를 비활성화한 상태에서 수정 결과를 검증하는 방법을 안내합니다. REALITY 노드는 해당 인증 매개변수를 확인해야 하며, 일반 인증서 체인 점검 절차를 적용하면 안 됩니다.

오류가 구독과 노드 연결 중 어디서 발생했는지 확인

TLS 오류가 보이면 먼저 어떤 동작을 했을 때 발생했는지 기록하세요. 구독 업데이트를 누를 때 나타나는 HTTPS 인증서 오류는 대개 구독 주소 연결에서 발생합니다. 노드를 선택하고 웹페이지에 접속할 때 코어 로그에 표시되는 핸드셰이크 오류라면 프록시 노드 문제일 수 있습니다. 두 연결은 대상 도메인이 다르므로 노드의 SNI를 바꿔도 구독 사이트 인증서 오류는 해결되지 않습니다.

대상 주소 확인 TCP 연결 TLS 핸드셰이크 인증서 검증 프록시 프로토콜 인증

일반 TLS 프록시 연결은 다음 순서로 이해할 수 있습니다. TCP 포트에 연결된다는 것은 서비스가 응답한다는 뜻일 뿐, 인증서가 올바르거나 프록시 인증에 성공했거나 웹페이지가 열린다는 의미는 아닙니다. VMess와 VLESS는 프록시 프로토콜이고 TLS는 함께 사용할 수 있는 전송 보안 계층입니다. 모든 노드가 TLS를 사용하는 것은 아닙니다.

대상 기록: 로그에 표시된 대상 주소, 포트, 오류 발생 시각과 오류 전문을 보관하세요. 공유하기 전에는 구독 토큰, 사용자 식별 정보와 비밀번호를 삭제하세요.
포트 확인: 노드가 443 포트를 사용한다면 해당 포트를 테스트하세요. 클라이언트의 로컬 수신 포트를 원격 포트로 착각하지 마세요.
오류 단계 구분: connection refused가 나타나면 먼저 수신 대기 설정과 방화벽을 확인하세요. i/o timeout은 연결 또는 핸드셰이크 중에 발생할 수 있으므로 앞뒤 로그를 함께 살펴보세요.
변수 줄이기: 노드 하나와 테스트 대상 하나를 고정하고 한 번에 한 항목만 변경하세요. DNS, 전송 방식, 프록시 모드를 동시에 바꾸지 마세요.

오류 메시지에 따라 점검 방향 정하기

코어와 버전에 따라 오류 앞부분에 연결 정보가 추가될 수 있습니다. 바깥쪽의 “연결 실패”만 보고 클라이언트를 반복해서 재시작하지 말고, 가장 안쪽의 x509 또는 tls 원인을 먼저 확인하세요. 아래 영어 문구는 흔히 볼 수 있는 오류 형식이며, 실제 로그에는 인증서 날짜나 구체적인 도메인이 함께 표시될 수 있습니다.

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

원인: 기기의 시간이 인증서 유효 기간을 벗어났을 수 있습니다. 기기 시계가 잘못되었거나 서버 인증서가 만료된 경우가 해당합니다.

해결: 먼저 시스템 시간을 동기화한 뒤 인증서의 시작일과 만료일을 확인하세요. 인증서가 만료됐다면 서버 관리자가 갱신한 후 서비스를 다시 불러와야 합니다.

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

원인: 신뢰할 수 있는 루트 인증서까지 체인을 구성하지 못한 상태입니다. 중간 인증서 누락, 자체 서명 인증서 또는 신뢰 저장소 이상이 흔한 원인입니다.

해결: 먼저 서버가 전송하는 인증서 체인을 확인하고, 다음으로 기기의 신뢰 저장소를 점검하세요. 출처가 불분명한 루트 인증서는 설치하지 마세요.

오류: `x509: certificate is valid for example.com, not www.example.com`

원인: 인증서 검증에 사용된 서버 이름이 인증서에서 허용하는 도메인에 포함되지 않았습니다. 여기서 도메인은 형식을 보여 주기 위한 예시입니다.

해결: 노드 제공자가 안내한 SNI와 인증서 SAN을 확인하세요. www를 임의로 추가하거나 삭제하지 마세요.

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

원인: 상대 서버가 핸드셰이크를 종료한 상태입니다. SNI, TLS 매개변수, 클라이언트 인증 요구 사항 또는 서버 정책이 원인일 수 있으며, 인증서를 신뢰할 수 없다는 뜻은 아닙니다.

해결: 연결 매개변수를 확인하고 서버 로그를 함께 살펴 원인을 찾으세요. 검증 건너뛰기를 켜는 것만으로는 상대 서버의 핸드셰이크 거부를 해결할 수 없습니다.

시스템 시간을 맞춘 뒤 인증서 만료 여부 확인

TLS 검증은 실제 시각을 기준으로 합니다. 작업 표시줄에 표시되는 시간대만 바꿔서는 기기의 시계가 정확해지지 않습니다. 반대로 표시되는 시간대가 다르다고 반드시 인증서 오류가 발생하는 것도 아닙니다. 절전 모드에서 복귀한 뒤, 메인보드 배터리 이상, 날짜를 수동으로 변경한 경우 등에는 시계가 실제 시간과 어긋날 수 있습니다.

날짜 확인

Windows 11에서 「설정」→「시간 및 언어」→「날짜 및 시간」을 열고 연도, 월, 일을 확인하세요. 특히 연도가 잘못 설정되어 있지 않은지 살펴보세요.
시계 동기화

「자동으로 시간 설정」을 켠 다음 「추가 설정」에서 「지금 동기화」를 누르세요. 동기화에 실패하면 먼저 네트워크 또는 시간 서비스 문제를 해결하세요. 자동 설정이 켜져 있다는 사실만으로 동기화가 완료된 것은 아닙니다.
연결 재시도

v2rayN으로 돌아가 현재 노드를 다시 활성화하고 요청을 한 번 보내세요. 이전 오류로 수정 결과를 판단하지 않도록 새 타임스탬프가 찍힌 로그를 확인하세요.
유효 기간 확인

만료 오류가 계속되면 인증서의 notBefore와 notAfter를 확인하세요. 기기 시간은 정상인데 인증서 유효 기간이 지났다면 서버 관리자에게 인증서 갱신을 요청하세요.

Android 기기에서는 시스템 설정에서 「날짜 및 시간」을 검색하고 자동 시간 설정을 켠 뒤 v2rayNG 또는 v2flyNG에 다시 연결하세요. 기기마다 메뉴 위치는 다를 수 있습니다. 스위치만 켜는 것이 아니라 동기화된 실제 날짜가 맞는지 확인해야 합니다. 장기적인 해결책으로 시스템 날짜를 인증서 유효 기간 안으로 되돌리지 마세요.

SNI, 연결 주소, 전송 Host 확인

SNI는 TLS 핸드셰이크에서 서버에 전달하는 이름이며, 서버는 이를 기준으로 인증서를 선택할 수 있습니다. 일반 TLS 설정의 serverName은 보통 인증서 검증에 사용할 대상 이름도 지정합니다. “위장 도메인”은 혼동하기 쉬운 표현입니다. TLS의 SNI를 뜻할 수도 있고 WebSocket의 Host를 뜻할 수도 있으므로, 변경하기 전에 어떤 필드인지 확인하세요.

필드	기능	확인할 사항
서버 주소	연결할 원격 호스트 지정	도메인 또는 IP가 올바른 접속 지점인지 확인
서버 포트	연결할 원격 서비스 지정	제공자 설정과 일치하는지 확인(예: 443)
SNI / serverName	TLS 이름 선택 및 검증에 영향	대상 서비스 및 인증서 SAN과 일치하는지 확인
WebSocket Host	HTTP 요청의 가상 호스트 라우팅에 영향	일반 TLS의 인증서 검증을 끄는 설정이 아님
WebSocket 경로	서버의 전송 경로와 일치해야 함	경로가 잘못되면 HTTP 상태 코드 오류로 나타날 수 있음

v2rayN 메인 화면에서 대상 노드를 두 번 클릭해 편집 창을 여세요. 먼저 「주소」와 「포트」를 확인한 다음 TLS 영역에서 SNI와 인증서 검증 건너뛰기 항목을 살펴보세요. 화면의 항목 이름은 버전에 따라 조금 다를 수 있습니다. 「설정」→「매개변수 설정」에서 전역 옵션을 바꾸는 것으로 해당 노드의 매개변수 확인을 대신하지 마세요.

연결 주소로 IP를 사용할 때도 제공자가 지정한 도메인을 SNI에 입력해야 하는 경우가 많습니다. IP를 기준으로 인증서를 직접 검증하려면 인증서에 해당 IP 유형의 SAN이 포함되어 있어야 합니다. 도메인만 포함된 인증서로는 이 조건을 충족할 수 없습니다. 와일드카드에도 제한이 있습니다. *.example.com은 일반적으로 example.com이나 a.b.example.com과 일치하지 않습니다.

주의: 웹페이지 도메인을 SNI에 임의로 입력하지 마세요

먼저 노드 제공자에게 확인된 서버 이름을 받아 인증서 SAN과 대조하세요. 웹페이지가 열린다고 해서 같은 도메인을 프록시 노드의 SNI로 사용할 수 있는 것은 아닙니다. HTTP Host가 맞더라도 TLS 이름 검증을 대신할 수 없습니다.

전체 인증서 체인과 서버가 실제로 반환하는 인증서 확인

서버는 보통 리프 인증서와 필요한 중간 인증서를 전송해야 하며, 루트 인증서는 대개 클라이언트의 신뢰 저장소에서 제공됩니다. 리프 인증서만 설정하면 어떤 환경에서는 작동해도 다른 기기에서는 알 수 없는 발급 기관 오류가 날 수 있습니다. 브라우저가 중간 인증서를 캐시했을 수도 있으므로 브라우저에서 정상적으로 열린다는 사실만으로 서버의 인증서 체인이 완전하다고 판단할 수 없습니다.

직접 서버를 관리한다면 OpenSSL이 설치된 환경에서 아래 명령을 실행하세요. example.com은 예시용 도메인입니다. 실행 전에 두 곳의 이름을 실제 TLS 도메인으로 바꾸고, 포트도 실제 노드 포트로 변경하세요. 이 명령은 일반 TLS 접속 지점을 확인하며 이후의 VMess 또는 VLESS 인증은 검증하지 않습니다.

openssl s_client -connect example.com:443 -servername example.com -verify_hostname example.com -verify_return_error -showcerts

실제 인증서 확인: 반환된 인증서의 주체 대체 이름과 유효 기간을 확인해 기본 사이트나 오래된 인증서가 선택되지 않았는지 살펴보세요.
검증 결과 확인: Verify return code: 0 (ok)는 해당 테스트 환경과 검증 매개변수에서 통과했다는 뜻입니다. 모든 기기의 신뢰 저장소가 같다는 의미는 아닙니다.
체인 누락 확인: unable to get local issuer certificate는 서버의 중간 인증서 누락 때문일 수도 있고 테스트 환경에 필요한 신뢰 루트가 없기 때문일 수도 있습니다. 양쪽을 따로 확인해야 합니다.
적용 위치 확인: 리버스 프록시나 엣지 접속 지점에서 TLS를 종료한다면 실제 TLS 종료 계층의 인증서를 갱신하세요. 백엔드 코어의 파일만 바꿔서는 안 됩니다.
반영 상태 확인: 인증서를 갱신한 뒤 서비스 설정에 따라 다시 불러오고 인증서를 재확인하세요. 디스크의 파일을 바꿔도 실행 중인 프로세스가 새 인증서를 사용한다는 보장은 없습니다.

allowInsecure 이해하기: 검증을 유지하고 스위치로 오류를 덮지 않기

allowInsecure는 일반 TLS 인증서 검증을 건너뛸지 결정합니다. true로 설정하면 연결이 암호화된 상태일 수는 있지만, 서버 신원은 정상적인 인증서 신뢰 체인과 이름 검증으로 보호되지 않습니다. 인증서가 수정된 것도 아니며, 의도한 서버에 연결된다고 보장할 수도 없습니다.

아래는 일반 TLS 아웃바운드 설정의 tlsSettings 필드 일부이며, 바로 가져올 수 있는 전체 노드 설정이 아닙니다. 예시 도메인을 실제 서버 이름으로 바꾸세요. 구독으로 관리하는 노드라면 다음 업데이트 때 로컬 수정 사항이 덮어써지지 않도록 원본 설정을 먼저 수정하는 것이 좋습니다.

{
  "tlsSettings": {
    "serverName": "example.com",
    "allowInsecure": false
  }
}

일상적인 연결: false를 유지하고 시계, 이름, 인증서 체인 또는 신뢰 저장소의 실제 문제를 해결하세요.
통제된 진단: 임시로 비교 테스트해야 한다면 접속 지점을 확인한 테스트 환경에서만 진행하세요. 계정, 결제 정보 또는 민감한 데이터를 전송하지 말고 테스트가 끝나면 즉시 검증을 다시 활성화하세요.
판단 범위: 검증을 끈 뒤 연결되더라도 문제 지점이 인증서 검증 단계일 수 있다는 점만 알 수 있습니다. 인증서 만료, 이름 오류, 신뢰할 수 없는 체인 중 무엇이 원인인지는 구분할 수 없습니다.
자체 서명 인증서 배포: 신뢰할 수 있는 경로로 예상 인증서 또는 신뢰할 수 있는 사설 CA를 배포하고 설정하세요. 구체적인 방법은 코어 지원 여부에 따라 다릅니다. 검증 건너뛰기를 장기간 사용해 신뢰 설정을 대신하지 마세요.

마무리 점검: 검증을 복원한 뒤 테스트

allowInsecure를 false로 유지한 채 다시 연결해 인증서 오류가 사라졌는지 확인한 다음, 웹페이지 연결과 예상된 외부 IP를 검증하세요. 검증 건너뛰기를 켰을 때만 연결된다면 문제는 아직 해결되지 않은 것입니다.

자주 묻는 질문과 수정 후 재검증

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

노드 설정부터 바꾸지 마세요. 구독 주소의 도메인, 기기 시간, 해당 HTTPS 서비스의 인증서를 확인하세요. 업데이트 요청이 프록시를 통해 전송된 것이 분명하다면 프록시 연결과 구독 사이트를 각각 검사해 어느 단계에서 실패했는지 확인하세요.

PC에서는 되는데 Android에서 인증서를 신뢰할 수 없다고 나옵니다. 어떻게 해야 하나요?

먼저 두 기기의 주소, 포트, SNI, 인증서 검증 설정을 비교한 다음 Android의 시스템 시간과 업데이트 상태를 확인하세요. 매개변수가 같다면 중간 인증서가 누락되지 않았는지 서버 관리자에게 확인하는 것이 우선입니다. 출처가 불분명한 루트 인증서를 기기에 바로 설치하지 마세요.

REALITY 연결에 실패해도 중간 인증서를 추가해야 하나요?

일반 TLS 해결 절차를 그대로 적용하지 마세요. 노드의 보안 유형이 REALITY인지 확인한 뒤 서버 이름, 공개 키, shortId 등 제공자가 요구한 매개변수와 코어 호환성을 하나씩 점검하세요. allowInsecure를 켜도 필요한 인증 매개변수를 대신할 수 없습니다.

한 번 연결된 뒤 수정이 제대로 됐는지 어떻게 확인하나요?

인증서 검증을 켠 상태로 현재 연결을 다시 시작하고 실제 웹페이지 요청을 여러 차례 보내세요. 새 로그에 같은 오류가 남아 있는지 확인한 다음 시스템 프록시 또는 TUN이 적용되는 범위도 살펴보세요. TCP 지연 시간이 표시되는 것만으로는 이 검증을 대신할 수 없습니다.

마지막으로 발생 동작, 구체적인 오류 유형, 변경 전후의 단일 설정, 재검증 시각과 결과를 짧게 기록해 두세요. 계속 실패한다면 기록과 민감 정보를 가린 로그를 서버 관리자에게 전달하고, 단순히 “노드가 작동하지 않는다”고만 하지 말고 실제 접속 지점이 반환하는 인증서를 확인해 달라고 요청하세요. 프록시 적용 단계를 다시 확인하려면 연결 테스트 안내를 참고하세요.