기술 · 실용 가이드
curl error 35 “wrong version number”? TLS를 바꾸기 전에 어느 홉이 평문을 말했는지 증명하세요
대개 낡은 TLS보다 프로토콜 불일치입니다. 프록시와 원본 홉을 추적하고 검증을 유지한 채 정확한 계약만 고치세요.
대개 낡은 TLS보다 프로토콜 불일치입니다. 프록시와 원본 홉을 추적하고 검증을 유지한 채 정확한 계약만 고치세요.
이 문구는 오해를 부를 수 있습니다. 어느 경계에서 핸드셰이크가 기대한 것과 다른 프로토콜 바이트를 받았다는 뜻이지, TLS 버전 자체가 낡았다는 증거는 아닙니다.
1. 실패 경로 고정
재시도 전에 정확한 curl 명령, URL, curl -V, 종료 코드와 비밀을 제거한 curl -v 또는 --trace-time을 저장하세요. 프록시 변수와 .curlrc는 환경에 따라 달라지므로 호스트와 셸도 기록합니다.
http_proxy, HTTPS_PROXY, ALL_PROXY, NO_PROXY를 자격 증명 없이 나열하세요. --noproxy "*"는 정책과 라우팅이 직접 연결을 허용할 때만 유효한 대조입니다.
2. 모든 네트워크 홉 명명
경로를 클라이언트→프록시, CONNECT, 터널, 원본으로 적으세요. http:// 프록시는 프록시까지 평문이며 https:// 프록시는 먼저 프록시와 TLS를 수행합니다.
대상 scheme과 서비스 포트도 확인하세요. 평문 HTTP 포트에 HTTPS를 보내면 양쪽이 최신 TLS를 지원해도 wrong version number가 날 수 있습니다.
3. 상세 로그 경계 읽기
상세 출력에서 마지막 성공 소켓과 첫 TLS 레코드 실패를 찾으세요. CONNECT 전인지, CONNECT 응답인지, 성공한 터널 뒤 원본 인사 단계인지 결정합니다.
ServerHello 대신 프록시 배너, HTTP 상태 줄, 읽을 수 있는 평문이 보이면 경로 증거입니다. 인증 헤더, 쿠키와 쿼리 비밀은 삭제하세요.
4. 한 프로토콜 계약만 수정
증명된 불일치만 고치세요. 프록시 URL scheme, 프록시 포트, 대상 scheme, 서비스 리스너 또는 오래된 환경 변수가 대상입니다. 처음부터 -k나 TLS 버전 강제를 쓰지 마세요.
승인된 TLS 검사라면 경로를 증명한 뒤 허용된 신뢰 체인을 제한적으로 설치하세요. 예상하지 않았다면 낯선 프록시나 인증서를 보안·설정 사고로 다룹니다.
5. 수정 결과 증명
의도한 경로로 상세 요청을 한 번 반복하고 올바른 프록시/터널 순서, 완료된 TLS, 호스트 이름 검증과 실제 HTTP 상태를 요구하세요.
수정 명령, 비밀 제거 추적과 설정 차이를 저장한 뒤 원래 앱이나 설치 프로그램도 검사하세요. 그 환경은 현재 셸과 다를 수 있습니다.
