브라우저는 HTTP 301을 얼마나 오래 캐시합니까?

380

HTTP 301 영구 리디렉션과 관련된 문제를 디버깅 중입니다. 빠른 테스트 후 Safari는 다시 시작될 때 301 캐시를 지우지 만 Firefox는 그렇지 않습니다.

IE, Chrome, Firefox 및 Safari는 언제 301 캐시를 삭제합니까?

업데이트 : 예를 들어로 리디렉션 example1.com하고 example2.com싶지만 실수로로 리디렉션하도록 설정 example3.com하면 문제가됩니다. 실수를 바로 잡을 수는 있지만 example1.com그 동안 방문한 사람은에 대한 잘못된 리디렉션을 캐시 example3.com했기 때문에 캐시가 지워질 때까지 example1.com또는 도달 할 수 없습니다 example2.com. 조사 결과, 나는이 더 있다고 찾을 Cache-Control및 Expires헤더를 설정합니다. 잘못된 301 응답의 헤더는 다음과 같습니다.

HTTP/1.1 301 Moved Permanently
Date: Wed, 27 Feb 2013 12:05:53 GMT
Server: Apache/2.2.21 (Unix) DAV/2 PHP/5.3.8
X-Powered-By: PHP/5.3.8
Location: http://example3.com/
Content-Type: text/html

내 자신의 테스트는 다음을 보여줍니다.

  • IE7, IE8, Android 2.3.4는 전혀 캐시하지 않습니다.
  • Firefox 18.0.2, Safari 5.1.7 (Windows 7) 및 Opera 12.14는 모든 캐시이며 브라우저를 다시 시작할 때 캐시를 지우십시오.
  • IE10 및 Chrome 25가 캐시되지만 브라우저를 다시 시작할 때 지워지지 않으므로 언제 지워 집니까?
http  http-status-code-301 
— 리암
소스
7
크롬에게이 301 개의 지옥 구멍을 벗어날 방법이 필요하다고 말해주세요. bugs.chromium.org/p/chromium/issues/…
— BT
@BT는 문제가 모든 브라우저에 영향을 미치기 때문에 실제로는 TTL이없는 캐시 된 301에 대해 필수 제한 시간을 정의하여 브라우저가 캐시 된 가정을 다시 확인하도록 IETF 만 해결할 수 있습니다.
— McGuireV10
1
IETF 메일 링리스트에 대한 토론을 시작했는데,이 문제를 계속 따르는 사람이 무게가 나가는 느낌이 든다면 : lists.w3.org/Archives/Public/ietf-http-wg/2017OctDec/0363.html
— McGuireV10

답변:

299

Chrome과 Firefox의 두 개 이상의 브라우저는 만료 날짜없이 301 리디렉션을 캐시 합니다 .

즉, 브라우저의 캐시가이를 수용 할 수있는 한 캐시 된 상태로 유지됩니다. 캐시를 수동으로 지우거나 캐시 항목을 제거하여 새 캐시를위한 공간을 확보하면 캐시에서 제거됩니다.

about:cache디스크 캐시 로 가서 찾아서 최소한 Firefox에서이를 확인할 수 있습니다 .

IE10 / IE11과 같은 다른 브라우저의 동작에 대해 모르겠습니다. 그러나 다른 브라우저가 무기한으로 캐시하는 경우 어쨌든이를 수용해야합니다.

Chrome / Firefox를 포함한 모든 브라우저에서 아래에 설명 된대로 헤더를 사용하여이 기본 동작을 무시할 수 있습니다.

참고 :이 답변은 2014 년에 작성되었으며 브라우저 동작은 시간이 지남에 따라 변경 될 수 있습니다.

리디렉션을 캐시하지 않으려는 경우

이 무기한 캐싱은 Cache-Control 헤더가없는 경우 이러한 브라우저에 의한 기본 캐싱입니다. 논리는 "영구적"리디렉션을 지정하고 다른 캐싱 명령을 제공하지 않기 때문에 마치 영구적으로 캐시되기를 원하는 것처럼 취급합니다.

브라우저는 여전히 지정된 경우 다른 응답과 마찬가지로 Cache-Control 및 Expires 헤더를 유지합니다.

당신은 같은 헤더를 추가 할 수 있습니다 Cache-Control: max-age=3600또는 Expires: Thu, 01 Dec 2014 16:00:00 GMT귀하의 301 리디렉션에. 당신은 추가 할 수 Cache-Control: no-cache가 브라우저에 의해 영구적으로 캐시되지 않거나, 그래서 Cache-Control: no-store그래서 심지어 브라우저에 의해 임시 저장소에 저장 될 수 없습니다.

그러나 내 의견으로는 더 나은 대안은 302 또는 307 리디렉션을 사용하는 것입니다. 이것들은 브라우저가 "영구적"리다이렉션하고 따라서 Cache-Control 헤더가없는 상태에서 캐싱되어서는 안된다는 것을 암시하지 않습니다.

나에게는 301 리디렉션을 발행하는 것처럼 보이지만 캐시 할 수 없음으로 표시하는 것은 기술적으로 유효하더라도 301 리디렉션 의 정신 에 위배 됩니다. YMMV 및 "영구적"리디렉션이 시간 제한을 갖는 것이 적합한 경우를 찾을 수 있습니다.

이전에 301 리디렉션을 발행했지만 실행을 취소하려는 경우

사람들이 여전히 브라우저에 캐시 된 301 리디렉션을 가지고 있다면 소스 페이지에 여전히 리디렉션이 있는지 여부에 관계없이 대상 페이지로 계속 이동합니다. 이 문제를 해결하기위한 옵션은 다음과 같습니다.

  • 가장 간단하고 최상의 솔루션은 다시 301 리디렉션을 다시 발행하는 것입니다.

    브라우저는 이전에 사용 중지 된 URL이라고 생각했던 것으로 되돌아 가고 있음을 인식하고, 이로 인해 해당 URL을 다시 가져 와서 이전 리디렉션이 아직 존재하지 않음을 확인해야합니다.

    편집 : 일부 의견은 이것에 의문을 제기합니다 (아래 참조).

  • 이전 리디렉션 대상이있는 사이트를 제어 할 수없는 경우 운이 좋을 것입니다. 사이트 소유자에게 다시 리디렉션하도록 요청하십시오.

또한 예방은 치료보다 낫습니다. 이전 URL을 영구적으로 해제하지 않으려면 301 리디렉션을 피하십시오.

— 토마스
소스
18
또한 브라우저가 원래 URL을 다시 가져와 순환 영구 ​​리디렉션을 처리한다는 것을 보여주는 참조가 있습니까?
— Kevin Christopher Henry
7
301 리디렉션이 작동하지 않음, 브라우저가 여전히 오래된 301 리디렉션을 캐시하고 무한 루프를 본다
— Yuriy Kolodovskyy
5
어떻게 테스트 했습니까 : 얼마 전에 나는 301 리디렉션을 http://www.SOMEHOST.com했습니다 https://www.SOMEHOST.com. 그러나 이제 http://www.SOMEHOST.com사이트의 기본 호스트 여야합니다. 따라서 https에서 http 로의 리디렉션이 제거되었습니다. 보시다시피 301을에서 https://www.SOMEHOST.com으로 리디렉션 http://www.SOMEHOST.com했지만 루프를 참조하십시오. 브라우저는 ...-가져 오는 재하지 않았다
— YURIY Kolodovskyy
8
처음 301 리디렉션을 제거한 경우 (내 경우에는 PHP 리디렉션으로) 리디렉션이 Chrome에서 완벽하게 작동한다는 것을 확인합니다.
— Vincent Poirier
15
리디렉션이 완벽하게 작동 함을 확인할 수 있습니다. 리디렉션 루프가 나타나는 브라우저는 캐시 항목을 무효화합니다. IE11, Firefox 52, Safari 10, Chrome 57에서 테스트되었습니다.
— Munhitsu
258

Chrome에서 71

영구 리디렉션을 지우려면 chrome : // settings / clearBrowserData로 이동하여 "캐시 된 이미지 및 파일"만 지우면 리디렉션이 지워집니다.

크롬 48-70

chrome : // net-internals로 이동하십시오. 상단 빨간색 상태 표시 줄의 오른쪽에서 아래쪽 화살표 ▼를 클릭하여 드롭 다운 메뉴를 열고 "도구"그룹에서 "캐시 지우기"를 선택하십시오.

버전 48부터는 캐시 된 301을 지우는 데 도움이 된 유일한 방법이었습니다.

— 맥과이어
소스
14
Chrome 버전 54부터는 불행히도 작동하지 않습니다.
— pwagner
4
제 생각에, 정말 대답하지 않았다 진짜 ", 얼마나이 브라우저는 301 캐시 않습니다"질문을하고, 내 대답은 아마도 영구적으로 수있는 방법이 필요합니다 공개에 직면 사이트를 리디렉션되지 도움말 사람이 301을 취소 할 것 야생에서 얼마나 많은 브라우저가 리디렉션을 캐시했는지 모른 채 다른 답변은 해당 시나리오를 부분적으로 해결합니다. 내 대답은 실제로 영향을받는 모든 사용자와 통신 할 수있는 개발자 또는 인트라넷 시나리오에만 유용합니다.
— McGuireV10
1
Chrome 버전 68.0.3440.106 (공식 빌드)에서 작동
— Thum Choon Tat
12
chrome : // net-internals는 Chrome 71에서 잘 렸습니다. 드롭 다운 / 도구 섹션이 사라졌습니다. DNS> 호스트 확인자 캐시> 호스트 캐시 지우기 버튼이 있지만 캐시 된 301을 제거하는 데는 작동하지 않습니다.
— t-jam
52
Chrome 71에서는 chrome : // settings / clearBrowserData와 "캐시 된 이미지 및 파일"만 지우면 리디렉션이 지워졌습니다.
— Bemmu
179

리디렉션 캐시를 필사적으로 제거하려는 사람들을 돕는 답변 :

Chrome은 로컬 디스크 캐시에서 301 리디렉션을 무한 캐시합니다. 이 캐시를 지우려면

  • 당신의 열 DevTools로 (보도를 F12)
  • 온 네트워크 탭 확인 "사용 안함 캐시" 체크 박스를
  • DevTools를 연 상태로 유지 하고 페이지를 다시로드 하십시오 (을 누르십시오 F5)

모든 것이 정상이면 "캐시 비활성화"를 선택 해제하면 모든 것이 예상대로 계속 작동합니다.

— 올라프
소스
14
이 기능은 캐싱을 다시 활성화 한 후에도 리디렉션이 사라졌습니다. 고마워!
— migg
2
로컬 호스트 파일을 통해 127.0.0.1을 가리키는 도메인에서는 이것이 작동하지 않는 것 같습니다. 이 경우 다른 옵션이 있습니까?
— pwagner
작동하지 않는 경우 리디렉션, unintendedly에서와 같은 다른 포트에 점 localhost:8000을 localhost(포트 80). 또한 localhost와 localhost : 8000에서 전체 사이트 / 응용 프로그램 데이터를 지 웠지만 어느 것도 도움이되지 않았습니다.
— Dennis98
3
이 솔루션은 2019 년 11 월 16 일 버전 78.0.3904.97부터 Chrome에서 작동합니다. 다른 솔루션은 더 이상 사용할 수 없습니다. 작업이 완료되면 개발자 도구를 닫을 수 있으며 계속 제대로 작동합니다.
— 피터 우스터
허용 된 답변.
— Aysennoussi
43

사용자가 해당 URL에 게시 양식을 제출하고 캐시 된 리디렉션이 사라지게합니다. :)

<body onload="document.forms[0].submit()">
<form action="https://forum.pirati.cz/unreadposts.html" method="post">
    <input type="submit" value="fix" />
</form>
</body>
— 크 르텍 넷
소스
2
나는 이것이 나사를 풀기 위해 찾은 가장 좋은 방법이라는 데 동의합니다.
— esjay
다른 답변과 달리이 방법은 개발자 콘솔을 열지 않고도 다른 사람들의 문제를 해결하는 데 적합합니다! 감사합니다
— Alexey Rytikov
4
fetch ( 'URL', {method : 'POST'})도 같은 방식으로 트릭을 수행해야합니다. 감사! 이것은 나에게 두통을 구했다!
— calvin
나는 이것이 나를 위해 일한 유일한 방법이라고 믿을 수 없다 (나는 다른 모든 방법을 먼저 시도했다. 심지어 크로스 사이트 보안 정책으로 인해 콘솔 fetch ()조차 실패했다).
— user36388 2016 년
24

301는 HTTP RFC 당 캐시 가능한 응답이며 브라우저는 응답에있는 HTTP 캐싱 헤더에 따라이를 캐시합니다. FireBug 또는 Charles를 사용하여 응답 헤더를 검사하여 응답이 캐시되는 정확한 기간을 알 수 있습니다.

당신은 캐싱 시간을 제어하려는 경우, 당신은 HTTP 응답 헤더를 사용 Cache-Control하고 Expires동일한 작업을 수행 할 수 있습니다. 또는 301응답을 전혀 캐시하지 않으려면 다음 헤더를 사용하십시오.

Cache-Control: no-store, no-cache, must-revalidate
Expires: Thu, 01 Jan 1970 00:00:00 GMT
— 알렉스 J
소스
12
기술적으로는 정확하지만 귀하의 답변은 사용자의 질문에 대한 답변이 아니므로 여기에 온 질문에 대한 답변이 아닙니다. 브라우저에 이미 존재하는 캐시되지 않은 헤더가있는 301은 언제 주 브라우저에 대해 만료됩니까?
— rob
누구든지 여전히 관심 이 있다면, 이 링크 지침은 캐시를 301로 토글 할 수 있습니다.
— Francisco Presencia
링크는 FF에 대한 것이며 저에게는 효과가 없었습니다. 웹 개발자 확장 1.2.5를 설치하고 FF 23.0.1을 사용함
— phu
질문에 대답하지 않았습니다. 문제는, 시간을 재 지정은 유효 기간이 지정되지 않은 경우에 대한 캐시됩니다 한
— 데니스 Flagg을
21

http 리디렉션 (예 : 301, 307 등)을위한 브라우저 캐시를 제거하는 매우 간단한 방법이 있습니다.

개발자 콘솔에서 네트워크 패널을 크롬으로 열 수 있습니다. 네트워크 통화를 선택하십시오. 마우스 오른쪽 버튼으로 클릭 한 다음 브라우저 캐시 지우기 를 클릭 하여 캐시 된 리디렉션을 제거하십시오.

네트워크 통화 상황에 맞는 메뉴

— 라지 쉬 폴
소스
1
대단히 감사합니다! 간단한 해결책과 일했습니다! 이 방법은 미래에도 작동해야합니다.
— sgon00
16

확인 !! 사용자가 영향을받는 URL에 게시 요청을 제출하도록하고 캐시 된 리디렉션을 잊어 버립니다.

가능한 경우 브라우저 콘솔에 입력하면됩니다.

fetch('example.com/affected/link', {method: 'post'}).then(() => {})

영향을받는 브라우저 (특히 개발 중)를 알고있는 경우 유용합니다.

또는 이전 301 리디렉션 페이지에 액세스 할 수있는 경우이 스크립트를 페이지에 추가하고 방문 할 때마다 캐시 된 301을 잊어 버릴 수 있습니다.

— 에메 케 아예
소스
이것은 위의 포스트 형식과 비슷하지만 노력이 적습니다.
— jpswade
맞습니다 @jpswade
— Emeke Ajeh
12

나에게 도움이되는 답변을 게시 할 것입니다.

URL로 이동 : 

chrome://settings/clearBrowserData

팝업을 호출해야합니다.

  • 선택하십시오 : cached images and files.
  • 시간 상자 선택 : from beginning
— 존 부족
소스
Chrome에서 작업 79!
— webaholik
Chrome 80에서 작업 해 주셔서 감사합니다.
— 요셉
6

@thomasrutter의 답변으로

이전에 301 리디렉션을 발행했지만 실행을 취소하려는 경우

사람들이 여전히 브라우저에 캐시 된 301 리디렉션을 가지고 있다면 소스 페이지에 여전히 리디렉션이 있는지 여부에 관계없이 대상 페이지로 계속 이동합니다. 이 문제를 해결하기위한 옵션은 다음과 같습니다.

가장 간단하고 최상의 솔루션은 다시 301 리디렉션을 다시 발행하는 것입니다.

브라우저는 이전에 해제 된 URL이라고 생각했던 것으로 되돌아 가고 있음을 인식하고, 이로 인해 해당 URL을 다시 가져 와서 이전 리디렉션이 아직 존재하지 않음을 확인해야합니다.

이전 리디렉션 대상이있는 사이트를 제어 할 수없는 경우 운이 좋을 것입니다. 사이트 소유자에게 다시 리디렉션하도록 요청하십시오.

실제로 이것은 다음을 의미합니다.

  1. a.com 301에서 b.com으로

  2. a.com의 301 삭제

  3. a.com에 b.com 301 추가

그런 다음 작동합니다.

— 필 한
소스
2
더러운 수정 - (:하지만 당신은 여전히 b.com의 301 주위에 거짓말이
— BT
1
다른 페이지 에서 다른 301을 발행하여 리디렉션을 지울 수 있습니까 ? 예를 들어 ( a.com301-> b.com) ( a.com301 삭제 ) ( a.com/abcdefg301-> 추가 a.com) 클라이언트가 a.com/abcdefg어떻게 든 보도록 강요 합니까?
— nemec
고마워요! IE11, Firefox 52, Safari 10, Chrome 57에서 테스트
— Munhitsu
a.com과 b.com을 모두 사용하려는 상황이있었습니다. 따라서 b.com 301 a.com은 옵션이 아닙니다. 우리의 솔루션은 HTTPS로 전환하는 것이 었습니다 – HTTPS에 대한 리디렉션이 없었습니다
— rosell.dk
6

IE, Chrome 및 FF를 포함한 모든 주요 브라우저 (최신 버전)에서 작동하는 간단한 솔루션이 있습니다.

  1. Ctrl + Shift + Del
  2. -
    1. Chrome : "브라우징 기록"및 "캐시 ..."를 선택하십시오.
    2. IE : 기본 옵션 인 "임시 인터넷 파일 및 웹 사이트 파일", "쿠키 및 웹 사이트 데이터", "기록"을 그대로 둡니다.
    3. FF : "찾아보기 및 다운로드 기록", "캐시"
  3. "삭제"를 클릭하십시오
  4. 브라우저를 닫았다가 다시 엽니 다. 작동해야합니다
— 둥 레
소스
일부 브라우저는 열린 페이지에서 캐시 된 항목을 지우지 않기 때문에 해당 페이지에 있지 않은지도 확인해야합니다.
— Oliver Schimmer
6

캐시 된 리디렉션을 피하기 위해 테스트 목적으로 사람들은 새 개인 창을 열 수 있습니다 . CTRL+SHIFT+N[Mozilla를 사용하는 경우 사용 P]을 클릭하십시오 .

— 토 두아
소스
아마도 "개인 창"의 주요 약속은 캐시에 쓰지 않고 여전히 읽기 / 재사용 할 수 있기 때문입니다. 그러나 Firefox 37.0.1 (Linux)에서 나를 위해 이것은 효과가 있었고 매우 빠르고 유용했습니다. 개인 창은 웹 서버의 현재 / 미시 설정을 반영하는 반면 일반 브라우저 탭은 캐시 된 301 리디렉션을 사용합니다.
— alfonx
alfonx : 서버 소유자가 쿠키 방식으로 요소를 사용하여 해당 사용자의 이전 ID를 표시 할 수 있기 때문에 개인 창에서 캐시를 재사용하지 못할 수 있습니다. 캐시 재사용은 아마도 포르노를 싫어하는 아내로부터 안전하다는 것을 인정해야합니다.
— Zdenek
6
캐시 된 301이 이미있는 경우 작동하지 않습니다. 개인은 실제로 캐시 된 리디렉션을 사용합니다.
— jeffmcneill
1

시크릿 / 비밀번호 모드를 사용하여 리디렉션을 테스트하여 브라우저를 닫으면 해당 캐시가 플러시되고 창을 다시 열면 캐시가 포함되지 않습니다.

— yougotiger
소스
1

다른 답변이 보여주는 것처럼. 브라우저에서 캐싱이 무기 한일 수 있습니다. 이것은 매우 위험합니다. 그러지 마 적어도 캐시 헤더를 추가하십시오. htaccess에서 나는 항상 지금 캐싱 하면서이 방법을 수행합니다.

<IfModule mod_rewrite.c>
  RewriteCond %{HTTP_HOST} ^(www\.)?example\.com$ [NC]
  # The E=nocache:1 sets the environment variable nocache to the value of one
  RewriteRule ^/?(.*) https://www.example.org/$1 [L,R=301,E=nocache:1]
</IfModule>


<IfModule mod_headers.c>
  ## Set the response header if the "nocache" environment variable is set
  ## in the RewriteRule above.
  Header always set Cache-Control "no-store, no-cache, must-revalidate" env=nocache

  ## Set Expires too ...
  Header always set Expires "Thu, 01 Jan 1970 00:00:00 GMT" env=nocache
</IfModule>
— 운젠
소스
1

로컬 호스트 주소의 문제를 해결하기 위해 사이트가 실행되는 포트 번호를 변경했습니다. 이것은 Chrome 버전 73.0.3683.86에서 작동했습니다.

— 전투 c2
소스
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.