설정을 바꾸기 전에 한 요청을 기록하기
먼저 문제가 보이는 정확한 URL을 하나 정합니다. 같은 URL의 상태·본문·이동 목적지를 저장해야 서로 다른 캐시나 페이지를 비교하는 일을 피할 수 있습니다. 아래 예제는 로그인 없는 공개 문서를 GET으로 읽고 새 임시 폴더에 결과를 남깁니다. example.com 주소를 검사할 페이지로 바꾸세요. 첫 요청은 이동을 자동으로 따라가지 않으므로 301·302가 나오면 저장한 Location부터 확인합니다.
check_dir=$(mktemp -d)
curl -sS --connect-timeout 3 --max-time 10 \
-D "$check_dir/headers.txt" -o "$check_dir/body.html" \
-w "HTTP=%{http_code} bytes=%{size_download}\n" https://example.com/
printf "saved: %s\n" "$check_dir"curl 종료 코드 0은 전송이 완료됐다는 뜻입니다. HTTP 404나 500인지와 기대한 본문인지는 따로 확인합니다. 저장 API에 이 GET 예제를 대신 쓰거나 실패한 POST를 곧바로 반복하지 마세요. 이 사이트의 HEAD·GET 실험에서는 두 요청이 모두 200이어도 다른 릴리스의 본문을 반환하는 경우가 있었습니다.
저장한 결과에서 조사 방향 정하기
| 받은 결과 | 다음 확인 | 이 단계의 완료 기준 |
|---|---|---|
| HTTP 응답 전 연결·TLS 오류 | 이름 해석, IPv4·IPv6, 인증서 이름 | 인증서 검증을 유지한 요청 완료 |
| 200인데 본문이 다름 | 도착한 경로, 공개 주소와 원본, 캐시 상태 | 기대한 문구·문서 버전 일치 |
| 조건부 요청만 304 | 원래 ETag와 조건 없는 GET | 새 본문과 검증자 관계 확인 |
| 저장 요청 timeout | 기존 요청 식별자로 서버 처리 결과 조회 | 미처리·처리완료·확인불가를 구분 |
브라우저에서 보이는 오류와 저장한 응답이 다르면 브라우저가 실제 요청한 URL과 조건 헤더를 비교합니다. 처음부터 캐시를 모두 지우면 원인을 보여줄 자료도 사라질 수 있습니다. 응답을 남긴 뒤 아래의 해당 실험에서 동일한 조건을 찾아 읽는 순서가 유용합니다.