지원 담당자에게 “프록시가 안 된다”는 말만 하지 말고 실패한 단계와 정확한 오류를 제공하세요. 짧은 보고서는 다음 구조를 쓸 수 있습니다.

Client and version:
Proxy protocol and port:
Attempt time and timezone:
Connection / overall timeout settings:
Last completed stage:
Exact error or numeric status:
Same target over an allowed direct route:
Same target through another comparable endpoint:

단계를 프록시 연결, 프록시 인증, 터널 설정, 대상 TLS 또는 최종 HTTP 응답으로 설명하세요. 예를 들어 “8080 포트 HTTP 프록시, TCP 연결됨, CONNECT가 407 반환, 대상 TLS는 아직 시작 전”이면 로그인 정보를 노출하지 않고 문제를 특정할 수 있습니다. 인증서 오류는 범주와 예상 호스트 이름의 맥락을 남기되 필요한 비공개 이름을 가리세요.

공유하기 전에 실제 텍스트를 검토하세요. 프록시 URL의 userinfo, Proxy-Authorization, 대상 Authorization, Cookie, Set-Cookie, 비공개 쿼리 값과 요청 본문을 제거하세요. 세션 쿠키나 bearer token은 비밀번호처럼 보이지 않아도 접근 권한을 줄 수 있습니다. 도구의 마스킹은 버전과 출력 모드마다 다를 수 있으며, 상세 로그와 전체 추적의 가림 방식이 같을 필요는 없습니다.

REDACTED_PROXY_PASSWORD 같은 표시를 쓰되 헤더 이름, URL 구조와 숫자 오류는 보이게 유지하세요. 실패 주변의 전체 교환 내용을 삭제하지 마세요. 비공개 엔드포인트와 네트워크 세부 사항은 적절한 지원 채널에서만 공유하세요.

무해한 대상이나 자신이 제어하는 서비스에 최소 요청을 보내 문제를 재현할 수 있다면 업무 데이터 추적 대신 그 요청을 제공하세요. 원래 대상에서만 오류가 발생하면 명시하세요. 대상을 바꾸면 재현으로 확인할 수 있는 내용도 달라집니다. HTTP 프록시는 시간을 제한한 curl 요청을 최소 예제로 쓸 수 있습니다.

관련 글