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

1. TLS 핸드셰이크 오류, 연결 단계부터 확인하기

GUI 클라이언트는 노드를 저장하고 설정을 생성하며, 실제 연결은 Xray나 V2Fly 같은 코어가 처리합니다. v2rayNG는 Xray 코어를, v2flyNG는 V2Fly 코어를 사용합니다. v2rayN에서 실제로 사용하는 코어는 현재 설정과 로그를 확인하세요. 코어와 버전에 따라 로그 접두어가 다를 수 있으므로, 가장 바깥쪽의 ‘연결 실패’만 보지 말고 오류 메시지의 마지막 부분을 확인해야 합니다.

TLS를 사용하는 VLESS, VMess, Trojan 노드는 보통 서버 주소를 먼저 확인한 뒤 원격 TCP 포트에 연결하고 TLS 핸드셰이크를 수행합니다. 핸드셰이크가 성공해야 이후 프록시 프로토콜 통신이 시작됩니다. 프로토콜 이름만으로 일반 TLS 사용 여부를 판단할 수 없으므로 보안 계층 설정을 확인하세요. REALITY는 자체 매개변수와 검증 방식을 사용하므로 이 글의 인증서 처리 방법을 그대로 적용하면 안 됩니다.

예를 들어 원격 포트가 443으로 설정되어 있는데 핸드셰이크가 시작되기도 전에 connection refused 오류가 발생한다면 인증서 옵션을 바꿔도 해결되지 않습니다. 443은 흔히 쓰이는 포트일 뿐이므로 서비스 제공자가 안내한 실제 포트를 사용하세요. 여기에 입력하는 포트는 로컬 프록시 포트가 아닙니다.

2. 시스템 시간과 인증서 유효기간: 기기 시계부터 바로잡기

인증서에는 유효 시작 시각과 만료 시각이 포함됩니다. 클라이언트는 기기의 현재 시각을 기준으로 인증서가 유효기간 안에 있는지 확인합니다. 날짜가 과거로 초기화되면 ‘아직 유효하지 않음’으로, 미래로 잘못 설정되면 ‘만료됨’으로 표시될 수 있습니다. 정확한 실제 시각이 표시되어야 하며, 시간대만 바꾸는 것으로 잘못된 시스템 시계가 바로잡히지는 않습니다.

1. 오류 기록하기

   클라이언트 로그에서 이번 연결에 해당하는 오류를 찾아 현재 시각과 인증서 유효기간 관련 안내를 기록하세요. 이전 로그와 새 로그가 뒤섞이지 않도록 연속해서 테스트하기 전에 잠시 멈추세요.

2. 시간 동기화하기

   Windows 11에서 ‘설정’ → ‘시간 및 언어’ → ‘날짜 및 시간’을 열고 ‘시간 자동 설정’을 켠 다음 ‘지금 동기화’를 누르세요. 먼저 기기가 네트워크에 연결되어 있는지 확인하세요.

3. Android 설정 확인하기

   Android 기본 인터페이스에서는 보통 ‘설정’ → ‘시스템’ → ‘날짜 및 시간’에서 ‘자동 설정’을 켭니다. 제조사에 따라 메뉴 이름이 다를 수 있으니 설정에서 ‘날짜 및 시간’을 검색해 자동 시간 설정이 적용되는지 확인하세요.

4. 다시 연결하기

   클라이언트로 돌아가 다시 연결한 뒤 새 로그를 확인하세요. 기기 시간이 정확한데 인증서가 실제로 만료되었다면 클라이언트 날짜를 계속 바꾸지 말고 서버에서 인증서를 갱신한 다음 다시 적용해야 합니다.

인증서 유효기간은 엄격한 경계이며 ‘5분 정도 허용’ 같은 고정된 유예 기간은 없습니다. 예를 들어 인증서가 UTC 00:00에 유효해지는데 기기의 실제 시계가 10분 느려 전날 23:50을 가리키면 검증에 실패할 수 있습니다. 로그와 인증서 도구가 서로 다른 시간대로 표시될 수 있으므로 UTC나 동일한 현지 시간대로 맞춰 비교하세요.

3. 서버 주소, SNI, 인증서 도메인에 무엇을 입력해야 할까

서버 주소는 연결할 대상을 지정합니다. SNI는 TLS 핸드셰이크에서 서버에 알리는 대상 호스트 이름으로, 서버는 이를 기준으로 사이트와 인증서를 선택할 수 있습니다. 일반적인 코어 설정의 serverName도 검증할 서버 이름을 지정하므로 임의로 적는 메모처럼 사용할 수 없습니다.

서비스 제공자가 연결 주소 edge.example.com, 원격 포트 443, TLS 이름 tls.example.com을 안내했다고 가정해 보겠습니다. 클라이언트에는 각 값을 해당 필드에 입력해야 합니다. 주소와 TLS 이름이 다르다고 반드시 잘못된 것은 아니지만, 서버 설정이 이를 지원해야 합니다. 검색 결과에서 임의로 도메인을 골라 SNI로 사용하지 마세요.

• 서버 주소: 노드에 안내된 도메인이나 IP 주소를 입력하세요. https://나 웹페이지 경로는 붙이지 않습니다.
• SNI / serverName: 서비스 제공자가 지정한 TLS 호스트 이름을 입력하세요. 일반적으로 포트, 프로토콜 접두어, 슬래시는 포함하지 않습니다.
• 인증서 SAN: 인증서의 주체 대체 이름(SAN)에 검증 대상 이름이 포함되어야 합니다. 인증서에 표시된 조직 이름만 확인해서는 안 됩니다.
• WebSocket Host: 이후 HTTP 요청에 사용되는 필드이며 TLS의 SNI와는 다릅니다. Host만 바꿔서는 인증서 이름 불일치를 해결할 수 없습니다.

와일드카드 인증서에도 적용 범위가 있습니다. *.example.com은 일반적으로 node.example.com과 일치하지만, example.com이나 a.node.example.com까지 포함하지는 않습니다. 서버 주소를 IP로 바꿨는데 검증할 이름을 따로 지정하지 않으면 코어가 해당 IP를 검증하려 할 수 있습니다. 도메인 SAN만 있는 인증서는 이 검증을 통과할 수 없습니다.

4. 자주 발생하는 인증서 오류: 원문 메시지로 원인 찾기

아래는 로그에 자주 나타나는 핵심 오류 문구입니다. 앞뒤에는 송신 연결 이름, 연결 번호, 주소 등이 더 붙을 수 있습니다. 로그 전체의 마지막에 표시된 일반적인 안내를 유일한 원인으로 단정하지 마세요. 인증서 오류에서는 x509 뒤에 이어지는 설명을 빠짐없이 보관하고, 서비스 제공자에게 전달할 때는 구독 토큰, 사용자 식별 정보, 개인 주소를 가리세요.

EOF만 표시된다고 해서 ‘인증서를 신뢰할 수 없다’고 단정할 수는 없습니다. 상대가 연결을 일찍 종료했거나 진입점 설정이 맞지 않거나 네트워크 장비가 연결을 끊어도 같은 결과가 발생할 수 있습니다. 먼저 더 앞선 TLS 상세 오류가 있는지 확인한 뒤 서비스 제공자의 지원이 필요한지 판단하세요.

5. allowInsecure의 역할과 위험 범위

일반적인 TLS 설정에서 allowInsecure는 서버 인증서 검증을 건너뛸지 제어합니다. ‘호환성을 높이는’ 만능 옵션이 아닙니다. 검증을 건너뛰면 잘못된 서버로 연결되거나 중간자 공격을 받아도 클라이언트가 일반적인 인증서 검증으로 연결을 차단하지 못할 수 있습니다. 연결이 암호화되었다고 해서 상대의 신원이 확실히 확인된 것은 아닙니다.

아래는 코어의 송신 설정 streamSettings 안에 들어가는 TLS 필드의 예시일 뿐, 그대로 가져와 사용할 수 있는 완전한 노드 설정은 아닙니다. tls.example.com은 설명을 위한 도메인이며 실제 값은 서비스 제공자가 지정한 TLS 이름을 사용해야 합니다. GUI 클라이언트가 보통 이 필드를 생성하므로 노드 편집 화면에서 수정하는 것을 권장합니다.

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

• 일상적인 연결: 인증서 검증을 켜 두세요. 화면에서 ‘인증서 검증 건너뛰기’, ‘안전하지 않은 연결 허용’처럼 반대 방향으로 표시하는 옵션은 꺼야 합니다.
• 통제된 진단: 우선 인증서 체인과 서버 로그를 확인하세요. 단기간 비교 테스트가 꼭 필요하다면 통제된 테스트 환경에서만 진행하고, 그동안 계정, 토큰 또는 기타 민감한 정보를 전송하지 마세요. 테스트가 끝나면 즉시 검증을 다시 켜세요.
• 결과 해석: 검증을 건너뛴 뒤 연결에 성공해도 실패 원인이 건너뛴 검증과 관련 있다는 점만 알 수 있습니다. 서버 신원이 올바르다거나 도메인 불일치만이 문제였다는 뜻은 아닙니다.
• 사설 인증서 환경: 관리자가 해당 시스템과 코어에 적합한 신뢰 방식을 신뢰할 수 있는 경로로 설정해야 합니다. 모든 사용자에게 검증을 계속 건너뛰도록 해서는 안 됩니다.

6. v2rayN과 v2rayNG 점검 순서

화면 문구는 버전에 따라 달라질 수 있으므로 문제 해결 전에 클라이언트 버전과 실제 코어 버전을 기록하세요. 일반적인 노드 편집 방법은 다음과 같습니다. v2rayN에서는 서버 목록의 대상 노드를 두 번 클릭하고, v2rayNG에서는 대상 설정 오른쪽의 편집 아이콘을 누릅니다. 같은 노드의 주소, 포트, 보안 계층, SNI, 인증서 검증 상태를 확인하고 전역 설정과 개별 노드 설정을 혼동하지 마세요.

1. 대상 지정

   점검할 노드를 하나만 선택하고 별칭과 출처 그룹을 기록하세요. 로그가 다른 노드나 자동으로 전환된 송신 연결이 아니라 해당 노드에 해당하는지 확인합니다.

2. 진입점 확인

   노드 편집 화면에서 서버 주소, 원격 포트, 전송 방식, 보안 계층이 TLS인지 서비스 제공자의 매개변수와 하나씩 대조하세요. 예시의 443을 실제 설정값 대신 사용하면 안 됩니다.

3. 이름 확인

   ‘SNI’ 또는 ‘serverName’ 필드를 확인하고 프로토콜 접두어, 포트, 앞뒤 공백이 없는지 살펴보세요. Host 필드도 있다면 서비스 제공자의 안내에 따라 각각 입력하고 서로 대체하지 마세요.

4. 검증 유지

   ‘인증서 검증 건너뛰기’ 또는 같은 의미의 옵션을 끄고 저장하세요. 메인 화면으로 돌아가 연결을 다시 시작하고, 필요하면 클라이언트의 코어 재시작 기능으로 변경 사항을 적용하세요.

5. 로그 대조

   실제 요청을 한 번 보내고 변경 전후의 오류를 비교하세요. TLS 오류가 사라졌지만 인증이나 전송 오류가 나타난다면 사용자 식별 정보, 경로, 서버 프로토콜 매개변수를 확인하세요.

구독 노드는 업데이트로 변경 내용이 덮어써질 수 있습니다. 구독에서 생성된 항목을 직접 수정하면 다음 업데이트 때 원래 값으로 돌아갈 수 있습니다. 문제 해결을 위해 수정해야 한다면 클라이언트가 지원하는 경우 별도 항목으로 복사하고 용도를 표시하세요. 장기적인 해결을 위해서는 서비스 제공자가 구독 매개변수를 바로잡아야 합니다. 전체 노드 설정, 원본 JSON, 구독 주소를 도움 요청 페이지에 공개하지 마세요.

7. 자주 묻는 질문: 브라우저는 되는데 클라이언트는 왜 실패하나요?