외부 목록으로 이동하거나, 확인 기록을 읽어 보세요
한국야동은 외부 목록으로 연결하는 안내 페이지예요. 영상 재생 화면은 제공하지 않아요.
같은 주소인데,
왜 화면이 다를까요?
예전 문장이 남는 경우와, 글 대신 홈이 열리는 경우를 따로 확인했어요.
주소는 같은데 예전 문장이 보일 때와, 글을 열었는데 홈으로 갈 때는 확인할 곳이 달라요. 한국야동의 실제 응답과 브라우저 동작을 비교해 보니, 내용이 그대로인 경우에는 저장된 문서가, 목적지가 달라진 경우에는 주소의 이동 규칙이 관여할 수 있었어요.
그래서 먼저 “무엇이 달라졌나”를 나눠 봤어요. 화면의 문장만 오래된 것인지, 주소창에서 글의 경로가 사라졌는지, 아예 다른 탭을 보고 있는지예요. 이 구분 없이 기록과 쿠키부터 모두 지우면 원인을 확인하기가 더 어려워져요.
1. 서버는 B를 보냈는데, 다시 연 화면에는 A가 남았어요
확인 당시 홈과 두 블로그 글의 HTML에는 Cache-Control: public, max-age=2592000이 붙어 있었어요. 2,592,000초는 30일이에요. 저장된 응답을 새것으로 취급할 수 있는 기간을 지정한 값이지, 모든 방문자가 반드시 30일 동안 같은 화면을 본다는 뜻은 아니에요. 실제 재사용 여부에는 저장 상태와 요청 방식도 영향을 줘요. Cache-Control 설명
이 값이 화면에 어떤 차이를 만드는지 알아보려고, 같은 헤더를 쓰는 작은 실험 페이지를 로컬에 만들었어요. 처음에는 A를 보여 주고, 서버의 문장만 B로 바꿨어요. 브라우저의 저장 상태는 지우지 않았어요.
| 실제로 한 일 | 보인 문장 | 서버 기록 |
|---|---|---|
| 문서를 처음 열기 | A | 문서 요청 1회 |
| 서버를 B로 바꾸고, 저장하지 않는 대조 페이지 열기 | B | 대조 페이지 요청 확인 |
| 링크를 눌러 원래 문서 다시 열기 | A | 새 문서 요청 없음 |
| 그 화면에서 일반 새로고침 | B | 문서를 다시 요청 |
세 번째 단계가 핵심이었어요. 뒤로 가기를 누른 것도 아닌데 A가 다시 나타났어요. 화면만 보면 업로드가 안 된 것처럼 보이지만, 대조 페이지는 이미 B였고 서버에도 두 번째 문서 요청이 없었어요. 서버 내용이 바뀐 사실과, 브라우저가 그 내용을 다시 받아 온 사실은 따로 확인해야 한다는 차이가 드러났어요.
이 실험에서는 일반 새로고침으로 B를 확인했어요. 특정 방문자의 장애를 재현한 결과나 모든 브라우저에서 같은 순서로 해결된다는 보장은 아니에요. 단계별 화면 문장과 요청 기록을 함께 남겼어요.
2. 글 주소가 홈으로 바뀐 경우에는 캐시만 볼 수 없었어요
같은 날짜에 글 주소 두 개도 비교했어요. 경로는 같게 두고, 앞에 www가 있는지만 바꿨어요. 자동 이동을 따라가기 전의 첫 응답을 읽었기 때문에, 최종 화면만 보고 추측한 결과는 아니에요.
| 요청한 호스트 | 첫 응답 | 응답에서 확인한 내용 |
|---|---|---|
| ddalq15.org | 200 | 해당 글의 HTML |
| www.ddalq15.org | 301 | Location: https://ddalq15.org/ |
대표 주소 하나로 모으는 것과 글의 경로를 유지하는 것은 별개예요. 이번에 확인한 www 응답의 목적지에는 /blog/back-button-and-tabs/가 없었어요. 이 링크로 들어와 홈을 보게 됐다면, “글이 삭제됐나?”라고 판단하기 전에 주소창에서 경로가 남아 있는지 볼 이유가 있어요.
이 경우에는 같은 주소를 계속 새로고침하는 것보다 홈의 블로그 메뉴에서 해당 글을 다시 여는 편이 목적에 맞아요. 공유할 때도 글이 열린 상태의 전체 주소를 복사하세요. 이 관찰은 확인 시점의 응답 기록이며, 주소 이동 설정을 변경했다는 뜻은 아니에요.
3. HIT와 304는 ‘오래된 글’이라는 판정이 아니에요
홈의 응답에는 CDN-Cache: HIT가 있었어요. 이 값만으로 오래된 문서라고 판단하지 않았어요. 실제로 /와 /index.html을 각각 받아 비교했더니 둘 다 7,738바이트였고, 파일 내용의 SHA-256 값도 같았어요. 그 순간에는 한쪽만 새 버전이라는 근거가 없었어요.
/index.html에서 받은 ETag를 If-None-Match에 넣어 다시 요청하자, 본문이 없는 304가 돌아왔어요. 저장된 버전과 달라지지 않았으니 그 본문을 재사용하라는 응답이에요. 숫자가 200이 아니라는 이유만으로 글을 못 가져왔다고 볼 수는 없어요. 304 응답 설명
CDN에 저장된 응답과 내 브라우저에 저장된 응답도 구분해야 해요. 어느 한쪽을 새로 받아 왔다는 사실만으로 다른 쪽까지 확인된 것은 아니에요. 그래서 이번에는 응답 헤더뿐 아니라 문서 내용, 브라우저 화면, 실험 서버의 요청 기록을 같이 봤어요.
지금 보고 있는 화면에서는 이것부터 확인하세요
- 주소와 글 제목은 같은데 문장만 예전이라면: 먼저 그 탭에서 새로고침해 비교하세요. 그대로라면 변경 전후의 문장과 확인 시간을 남겨 두세요. 화면만으로 서버 업로드 실패인지 저장된 응답인지 단정하지 마세요.
- 글 대신 홈이 열렸다면: 주소창에
/blog/…/경로가 남아 있는지 보세요. 경로가 사라졌다면 블로그 목록에서 글을 다시 열어 전체 주소를 확인하세요. - 사이트 이름부터 달라졌다면: 탭이 새로 생겼는지 확인하세요. 홈의 바로가기 버튼을 실제로 눌렀을 때는 외부 목록이 새 탭에 열렸고, 이 홈은 원래 탭에 남았어요.
세 상황을 구분하면 필요한 조치도 짧아져요. 문서가 오래된 문제에는 내용을 다시 받는 확인이, 목적지가 달라진 문제에는 전체 경로 확인이, 다른 탭을 보고 있는 경우에는 원래 탭 확인이 먼저예요.
확인 범위: 2026-10-24의 공개 HTTP 응답, Windows 데스크톱 Chrome의 일반 클릭, 로컬 대조 실험. 휴대폰 실기기나 다른 지역의 동일 동작은 측정하지 않았어요. 응답 상태·헤더·파일 비교 기록과 실제 이동 순서를 공개해요.