V2Ray TLS 인증서 오류 해결 체크리스트: 시스템 시간 불일치와 SNI 설정 가이드

TLS 오류는 어느 단계에서 발생할까

V2Ray 또는 Xray가 TLS 연결을 설정할 때 클라이언트는 먼저 노드의 IP와 포트에 연결한 뒤 SNI가 포함된 ClientHello를 보냅니다. 서버는 SNI에 따라 인증서를 선택하고, 클라이언트는 인증서 유효 기간, 도메인 범위, 발급 체인과 시스템의 신뢰 상태를 확인합니다. 어느 하나라도 통과하지 못하면 프록시 프로토콜이 전송되기 전에 연결이 중단됩니다.

따라서 로그에 TLS 오류가 나타났다고 해서 VMess 또는 VLESS의 사용자 식별자가 잘못된 것은 아닙니다. 사용자 식별자, 암호화 방식과 흐름 제어 매개변수는 일반적으로 TLS 핸드셰이크가 완료된 뒤 통신에 사용됩니다. 문제를 해결할 때는 먼저 인증서 계층을 확인하고 UUID, 포트, 전송 방식과 라우팅 규칙을 동시에 바꾸지 않아야 원인을 좁힐 수 있습니다.

1단계: 시스템 시간과 시간대 맞추기

인증서에는 명확한 시작 시각과 만료 시각이 포함됩니다. 클라이언트는 로컬 시계를 기준으로 현재 시간이 유효 기간에 들어오는지 판단합니다. 시스템 날짜가 하루 틀리거나 시간대를 잘못 선택했거나 절전 모드 해제 후 시간이 동기화되지 않으면 정상 인증서도 아직 유효하지 않거나 만료된 것으로 판단될 수 있습니다. 듀얼 부팅 기기, 장기간 전원이 꺼져 있던 데스크톱과 자동 시간 동기화를 끈 기기에서 특히 자주 발생합니다.

1. 현재 시간 확인

   신뢰할 수 있는 시간 정보를 기준으로 연, 월, 일, 시, 분을 확인하세요. 오차가 5분에 이르면 노드 매개변수를 바꾸지 말고 먼저 시스템 시간 동기화를 처리합니다.

2. 로컬 시간대 확인

   Windows에서 「설정」→「시간 및 언어」→「날짜 및 시간」을 열고 시간대가 현재 위치와 일치하는지 확인한 뒤 자동 시간 설정을 켭니다.

3. 즉시 동기화 실행

   날짜 및 시간 페이지에서 「추가 설정」으로 들어가 즉시 동기화를 실행하세요. 한 점검 사례에서는 7분 12초의 오차를 수정하자 인증서가 아직 유효하지 않다는 메시지가 바로 사라졌습니다.

4. 클라이언트 코어 재시작

   v2rayN 메인 화면에서 「서버」→「서비스 재시작」을 실행한 다음 현재 서버의 지연 시간을 다시 테스트하세요. 기존 연결이 실패 상태를 계속 재사용하는 것을 막을 수 있습니다.

Android 기기도 「날짜 및 시간」에서 자동 시간 설정과 자동 시간대 설정을 확인해야 합니다. 분만 수동으로 맞추는 방법은 신뢰하기 어렵습니다. 날짜나 시간대가 잘못되어도 인증서 판단에 영향을 주기 때문입니다. 시간 동기화가 끝나면 v2rayNG 또는 v2flyNG를 완전히 종료한 뒤 다시 열어 노드를 테스트하세요.

2단계: SNI, serverName과 노드 주소 확인

SNI는 TLS 핸드셰이크에서 서버로 전송되는 호스트 이름입니다. V2Ray 및 Xray 설정에서는 보통 serverName으로 지정합니다. 명시적으로 입력하지 않으면 코어가 노드 주소를 바탕으로 추정할 수 있습니다. 노드 주소가 IP이거나 진입 도메인과 인증서 도메인이 다르거나 구독 변환 과정에서 SNI가 누락되면 서버가 기본 인증서를 반환하고 도메인 불일치가 발생할 수 있습니다.

세 가지 필드를 구분해야 합니다. 노드 주소는 연결할 대상을, 포트는 연결 진입점을, serverName은 TLS 핸드셰이크에서 선언할 도메인을 결정합니다. WebSocket의 Host 요청 헤더는 TLS 연결 이후에 전송되므로 SNI를 대신할 수 없습니다. Host를 올바르게 입력해도 serverName이 잘못되면 인증서 검증은 계속 실패합니다.

일반적인 VLESS TLS 아웃바운드 설정에서는 주소와 serverName이 서로 다를 수 있습니다. 아래 예시는 필드 간 관계만 보여 주며, 실제 주소, 사용자 식별자, 포트와 전송 방식은 유효한 구독 정보를 따라야 합니다.

{
  "outbounds": [
    {
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "edge.example.net",
            "port": 443,
            "users": [
              {
                "id": "11111111-2222-3333-4444-555555555555",
                "encryption": "none"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "security": "tls",
        "tlsSettings": {
          "serverName": "node.example.com"
        }
      }
    }
  ]
}

3단계: 인증서 유효 기간과 전체 인증서 체인 확인

시스템 시간과 SNI가 모두 올바른데도 unknown authority 또는 unable to verify certificate가 표시되면 서버가 반환한 인증서 체인을 중점적으로 확인합니다. 정상적인 경우 서버는 사이트 인증서와 필요한 중간 인증서를 함께 보내고, 클라이언트는 시스템이 신뢰하는 루트 인증서를 통해 검증을 완료합니다. 중간 인증서가 누락되면 일부 환경에서는 캐시된 인증서 덕분에 잠시 작동할 수 있지만 다른 기기에서는 계속 실패합니다.

명령줄 환경을 사용할 수 있다면 OpenSSL로 대상 진입점이 반환하는 인증서 체인을 직접 확인할 수 있습니다. -connect는 실제 연결 주소와 포트를 지정하고, -servername은 SNI를 지정합니다. 두 값을 의도적으로 분리하면 진입 도메인과 인증서 도메인이 다른 설정을 검증하기 쉽습니다.

openssl s_client \
  -connect edge.example.net:443 \
  -servername node.example.com \
  -showcerts

• 출력에서 사이트 인증서의 주체 도메인을 확인하고 node.example.com이 포함되어 있는지 확인하세요.
• 인증서의 Not Before와 Not After를 확인해 현재 시간이 유효 구간에 들어오는지 확인하세요.
• Certificate chain에 사이트 인증서와 필요한 중간 인증서가 포함되어 있는지 확인하세요. 번호 0인 단일 인증서만 있어서는 안 됩니다.
• 마지막 검증 결과가 성공인지 확인하세요. 체인이 완전하지 않다면 서버에서 중간 인증서를 보완한 뒤 진입점 설정을 다시 로드해야 합니다.
• 여러 노드가 같은 진입점을 공유하며 동시에 실패한다면 클라이언트 노드를 하나씩 수정하기보다 진입점 인증서 갱신과 리버스 프록시 설정을 먼저 확인하세요.

클라이언트 사용자는 일반적으로 서버의 인증서 체인을 직접 수정할 수 없습니다. 이때는 노드 이름, 테스트 시간, 첫 번째 오류 로그와 사용한 네트워크를 기록하고 구독을 한 번 업데이트한 뒤 다시 테스트하세요. 서로 다른 네트워크와 기기에서 같은 체인 오류가 발생한다면 해당 정보를 노드 관리자에게 전달해 인증서 배포 문제를 확인하도록 하세요.

4단계: 클라이언트별 TLS 매개변수 확인

외부에서 인증서가 정상임을 확인한 뒤 클라이언트에 저장된 노드 매개변수를 점검합니다. v2rayN 데스크톱 버전은 보통 Xray 코어를 사용하고, v2rayNG도 Xray 코어를 사용하며, v2flyNG는 V2Fly 코어에 대응합니다. 코어마다 로그 표현은 다를 수 있지만 주소, 포트, 전송 보안, SNI와 시스템 시간이라는 다섯 항목의 점검 순서는 같습니다.

1. 단일 노드로 고정

   자동 선택을 일시 중지하고 오류를 안정적으로 재현할 수 있는 노드 하나를 선택하세요. 여러 노드가 번갈아 선택되어 판단을 방해하지 않도록 노드 메모, 주소, 포트, 전송 방식과 TLS serverName을 먼저 기록합니다.

2. 코어 유형 확인

   v2rayN에서 「설정」→「매개변수 설정」→「Core 유형」을 열고 현재 프로토콜이 예상한 코어를 사용하는지 확인하세요. 저장한 뒤 「서버」→「서비스 재시작」을 실행합니다.

3. 서버 편집

   v2rayN 서버 목록에서 노드를 선택하고 편집 창을 연 뒤 주소, 포트, 전송 프로토콜, 전송 계층 보안과 SNI를 하나씩 확인하세요. 노드 메모를 serverName에 복사하지 마세요.

4. Android 설정 확인

   v2rayNG 또는 v2flyNG의 설정 목록에서 대상 노드 편집 화면을 열고 「주소」, 「포트」, 「전송 계층 보안」과 「SNI」를 확인하세요. 저장한 뒤 해당 노드를 다시 선택하고 연결을 시작합니다.

5. 구독 업데이트 후 재테스트

   수동 노드는 정상인데 구독 노드만 비정상이라면 구독을 업데이트하고 TLS 필드를 비교하세요. 여러 구독 그룹이 함께 있을 때는 현재 노드가 방금 업데이트한 그룹에서 온 것인지 확인합니다.

6. 첫 번째 오류 읽기

   로그를 지우거나 구분한 뒤 한 번만 연결하고, certificate 또는 handshake 오류 중 첫 번째 메시지를 우선 확인하세요. 이후 오류 키워드에 따라 해당 점검 분기로 돌아갑니다.

5단계: 인증서 문제, 네트워크 문제와 프로토콜 문제 구분

일부 로그에는 handshake failed가 포함되지만 원인이 인증서가 아닐 수 있습니다. 대상 포트에서 TLS를 제공하지 않거나 네트워크 중간에서 연결이 재설정되거나 서버 진입점이 수신 대기하지 않아도 핸드셰이크가 조기에 끝납니다. 오류에 x509, certificate, hostname, expired 또는 unknown authority가 명시되어 있는지 확인하는 것이 핵심입니다. 이런 키워드가 있으면 인증서 분기를 먼저 진행하고, 없으면 네트워크 연결 가능성과 서버 수신 대기를 확인하세요.

한 번에 변수 하나만 바꾸는 것이 좋습니다. 먼저 시간을 동기화하고 재테스트한 뒤 SNI를 수정해 다시 테스트하고, 다음으로 인증서 체인을 확인한 후 마지막에 코어를 업데이트하거나 노드를 다시 만드세요. 네트워크, 코어와 포트를 동시에 바꾸고 구독까지 다시 가져오면 연결이 복구되어도 무엇이 실제로 해결했는지 알 수 없습니다.

최종 재테스트 체크리스트

설정을 수정한 뒤에는 클라이언트 상태가 연결됨으로 바뀌었는지만 보지 말고 재현 가능한 전체 테스트를 한 번 수행해 결과를 확인하세요. 먼저 코어를 재시작하고 노드 지연 시간을 테스트한 다음 실제 웹페이지나 애플리케이션 요청을 실행하고, 마지막으로 로그에 새로운 TLS 오류가 남아 있는지 확인합니다. 연결은 성공했지만 웹페이지에 접근할 수 없다면 TLS 계층을 통과한 것이므로 시스템 프록시, DNS, 라우팅 분할과 아웃바운드 설정을 확인해야 합니다.

• 시스템 날짜, 시간과 시간대가 정확하고 자동 시간 동기화를 실행했습니다.
• 노드 주소에 공백이나 이전 도메인이 없고 포트가 서버 진입점과 일치합니다.
• 구독 설정에 따라 전송 계층 보안이 활성화되어 있으며 TLS 진입점은 일반적으로 명확한 포트를 사용합니다.
• serverName이 인증서에 포함된 도메인과 일치하며 노드 메모나 IP를 잘못 입력하지 않았습니다.
• WebSocket Host와 TLS SNI를 따로 확인했으며 두 필드를 같은 항목으로 취급하지 않았습니다.
• 인증서가 유효 기간 내에 있고 서버가 필요한 중간 인증서를 전송합니다.
• 구독을 업데이트한 뒤 현재 새 노드를 사용 중인지, 이전 그룹의 같은 이름 설정이 아닌지 확인했습니다.
• 로그에서 첫 번째 인증서 오류가 사라졌고 연속 세 번의 연결 테스트 결과가 일치합니다.

이 순서대로 점검하면 막연한 handshake failed를 검증 가능한 구체적 문제로 나눌 수 있습니다. 시간 이상은 유효 기간 판단에 영향을 주고, SNI 오류는 불일치하는 인증서를 반환하며, 체인 누락은 신뢰 검증을 중단시키고, 포트나 진입점 오류는 핸드셰이크가 끝나기 전에 연결을 끊을 수 있습니다. 매번 변경한 내용과 재테스트 결과를 기록하는 편이 클라이언트를 반복 삭제하거나 노드 매개변수를 일괄 변경하는 것보다 원인을 찾기 쉽습니다.