동일한 도메인에 호스팅된 반응 앱과 WordPress 앱이 포함된 Cloudfront 배포 - WordPress 앱을 렌더링하기 위해 캐시된 반응 앱이 있는 브라우저를 얻는 방법은 무엇입니까?

동일한 도메인에 호스팅된 반응 앱과 WordPress 앱이 포함된 Cloudfront 배포 - WordPress 앱을 렌더링하기 위해 캐시된 반응 앱이 있는 브라우저를 얻는 방법은 무엇입니까?

Cloudfront를 통해 s3 버킷에 반응 웹 사이트를 호스팅하는 도메인이 있습니다. 해당 도메인의 하위 도메인에 호스팅되는 WordPress 사이트도 있으며 웹 앱용 CloudFront 배포에는 경로 패턴으로 설정된 두 가지 동작이 있으며 en이는 en/*WordPress 하위 도메인을 원본으로 설정합니다.

en/*이 설정은 시크릿 모드에서 경로를 방문할 때와 기본 도메인을 방문한 적이 없는 브라우저에서 작동하는 것으로 보입니다 . 하지만 이전에 해당 도메인을 방문한 적이 있는 브라우저에서는 브라우저가 WordPress 페이지 대신 React 앱을 렌더링합니다. 빈 캐시를 실행하고 강제로 다시 로드하면 WordPress 페이지가 표시되지만, 그 후 다시 새로 고치면 웹 앱 렌더링으로 돌아갑니다. 이것은 매우 지속적으로 발생합니다.

WordPress 앱을 렌더링해야 하는 URL에서 반응 앱이 렌더링되면 다음 응답 헤더가 표시됩니다. x-cache: RefreshHit from cloudfront

또한, React 앱을 방문한 적이 없는 브라우저는 로 시작하는 경로를 방문할 때 WordPress 앱을 올바르게 로드하지만 /en, 해당 브라우저가 React 앱을 방문한 후에는 으로 시작하는 경로가 /en더 이상 WordPress 앱을 렌더링하지 않습니다.

여기서 정확히 무슨 일이 일어나고 있는 걸까요? 그리고 사용자가 브라우저 캐시를 완전히 지울 필요 없이 WordPress 앱을 일관되게 렌더링하도록 하는 방법이 있습니까? 관련 캐시 항목이 해당 경로 중 하나에 있음을 감지하면 반응 앱 내에서 그렇게 할 수 있도록 자바스크립트를 사용하여 관련 캐시 항목을 지우는 방법이 있습니까?

답변1

문제는 내 cloudfront 또는 s3 구성과 관련이 없는 것으로 밝혀졌으며 대신 반응 앱이 시작된 서비스 작업자가 도메인이 시작된 후 도메인에 대한 모든 요청을 가로채기 때문에 발생했습니다. 서비스 워커를 제거하면(더 이상 필요하지 않으므로 제거할 수 있음) 문제가 해결되었습니다.

관련 정보