NGINX Cache 자주 묻는 질문(FAQ) 15가지를 모두 모았습니다.
대부분의 CDN 서비스에는 Core로 NGINX Cache를 사용합니다. 글로벌 CDN 서비스 제공자 Cloudflare, 넷플릭스 모두 NGINX를 Cache 서버로 사용하여 고성능과 안정성을 갖춘 CDN 서비스를 제공하고 있습니다.
자체 Cache 서버와 CDN 서비스를 구축하고 하는 사용자들을 위하여 자주 묻는 질문(FAQ) 15가지를 모두 모아봤습니다.
이 포스트에서는 NGINX 콘텐츠 캐싱에 대해 자주 묻는 질문에 대한 답변을 제공합니다.
목차
1. NGINX 캐시를 계측할 수 있습니까?
2. NGINX는 캐시 여부를 어떻게 결정합니까?
3. Cache-Control 헤더를 무시할 수 있습니까?
4. NGINX가 헤더에 Set-Cookie를 사용하여 콘텐츠를 캐시할 수 있습니까?
5. NGINX가 POST 요청을 캐시할 수 있습니까?
6. NGINX가 동적 콘텐츠를 캐시할 수 있습니까?
7. 내 캐시에 구멍을 뚫을 수 있습니까?
8. NGINX는 어떤 캐시 키를 사용합니까?
9. 내 캐시 키의 일부로 쿠키를 사용할 수 있습니까?
10. NGINX는 ETag 헤더를 사용합니까?
11. NGINX는 바이트 범위 요청을 어떻게 처리합니까?
12. NGINX는 캐시 제거를 지원합니까?
13. NGINX는 Pragma 헤더를 어떻게 처리합니까?
14. NGINX는 Cache-Control 헤더에 대한 stale-while-revalidate 및 stale-if-error 확장을 지원합니까?
15. NGINX는 Vary 헤더를 지원합니까?
1. NGINX 캐시를 계측할 수 있습니까?
예, add_header 지시문 사용:
add_header X-Cache-Status $upstream_cache_status;이 예에서는 클라이언트에 대한 응답으로 X-Cache-Status HTTP 헤더를 추가합니다. 다음은 $upstream_cache_status에 대해 가능한 값입니다.
- MISS – 캐시에서 응답을 찾을 수 없으므로 Origin 서버에서 가져왔습니다. 그러면 응답이 캐시되었을 수 있습니다.
- BYPASS – 요청이 proxy_cache_bypass 지시문과 일치하기 때문에 캐시에서 제공되는 대신 Origin 서버에서 응답을 가져왔습니다(아래의 내 캐시에 구멍을 뚫을 수 있습니까? 참조). 그러면 응답이 캐시되었을 수 있습니다.
- EXPIRED – 캐시의 항목이 만료되었습니다. 응답에는 Origin 서버의 최신 콘텐츠가 포함되어 있습니다.
- STALE – Origin 서버가 올바르게 응답하지 않고 proxy_cache_use_stale이 구성되어 콘텐츠가 stale입니다.
- UPDATING – 이전 요청에 대한 응답으로 항목이 현재 업데이트되고 있고 proxy_cache_use_stale 업데이트가 구성되어 있으므로 콘텐츠가 부실합니다.
- REVALIDATED – proxy_cache_revalidate 지시문이 활성화되었고 NGINX가 현재 캐시된 콘텐츠가 여전히 유효한지 확인했습니다(If-Modified-Since 또는 If-None-Match).
- HIT – 응답에 캐시에서 직접 가져온 유효하고 새로운 콘텐츠가 포함됩니다.
2. NGINX는 캐시 여부를 어떻게 결정합니까?
NGINX는 Origin 서버에 미래 날짜 및 시간이 포함된 Expires 헤더 또는 0이 아닌 값으로 설정된 max-age 지시문이 포함된 Cache-Control 헤더가 포함된 경우에만 응답을 캐시합니다.
기본적으로 NGINX는 Cache-Control 헤더의 다른 지시문을 존중합니다. 헤더에 Private, No-Cache 또는 No-Store 지시문이 포함된 경우 응답을 캐시하지 않습니다. 또한 Set-Cookie 헤더로 응답을 캐시하지 않습니다. 또한 GET 및 HEAD 요청에 대한 응답만 캐시합니다. 아래 답변에 설명된 대로 이러한 기본값을 재정의할 수 있습니다.
NGINX는 proxy_buffering이 off로 설정된 경우 응답을 캐시하지 않습니다. 기본적으로 켜져 있습니다.
3. Cache-Control 헤더를 무시할 수 있습니까 ?
예, proxy_ignore_headers 지시문을 사용합니다. 예를 들어 다음과 같은 구성을 사용합니다.
location /images/ {
proxy_cache my_cache;
proxy_ignore_headers Cache-Control;
proxy_cache_valid any 30m;
# ...
}NGINX는 /images/ 아래의 모든 항목에 대해 Cache-Control 헤더를 무시합니다. proxy_cache_valid 지시문은 캐시된 데이터에 대한 만료를 적용하며 Cache-Control 헤더를 무시하는 경우 필요합니다. NGINX는 만료되지 않은 파일을 캐시하지 않습니다.
4. NGINX가 헤더에 Set-Cookie를 사용하여 콘텐츠를 캐시할 수 있습니까?
예, 이전 답변에서 설명한 대로 proxy_ignore_headers 지시문을 사용합니다.
5. NGINX가 POST 요청을 캐시할 수 있습니까?
예, proxy_cache_methods 지시문 사용:
proxy_cache_methods GET HEAD POST;이 예에서는 POST 요청의 캐싱을 활성화합니다.
6. NGINX가 동적 콘텐츠를 캐시할 수 있습니까?
예, Cache-Control 헤더가 허용한다면 가능합니다. 짧은 시간 동안 동적 콘텐츠를 캐싱하면 Origin 서버 및 데이터베이스의 부하를 줄일 수 있으며 각 요청에 대해 페이지를 다시 생성할 필요가 없기 때문에 첫 번째 바이트까지 시간을 단축할 수 있습니다.
7. 내 캐시에 구멍을 뚫을 수 있습니까?
예, proxy_cache_bypass 지시문 사용:
location / {
proxy_cache_bypass $cookie_nocache $arg_nocache;
# ...
}이 지시문은 NGINX가 캐시에서 콘텐츠를 먼저 찾는 대신 Origin 서버에서 즉시 콘텐츠를 요청하는 요청 유형을 정의합니다. 이를 캐시에 “구멍 뚫기”라고도 합니다. 이 예에서 NGINX는 nocache 쿠키 또는 인수가 있는 요청에 대해 이를 수행합니다(예: http://www.example.com/?nocache=true). NGINX는 우회되지 않은 향후 요청에 대한 결과 응답을 계속 캐시할 수 있습니다.
8. NGINX는 어떤 캐시 키를 사용합니까?
NGINX가 생성하는 키의 기본 형식은 다음 NGINX 변수의 MD5 해시와 유사합니다. $scheme$proxy_host$request_uri; 사용된 실제 알고리즘은 약간 더 복잡합니다.
proxy_cache_path /path/to/cache levels=1:2 keys_zone=my_cache:10m max_size=10g
inactive=60m use_temp_path=off;
server {
# ...
location / {
proxy_cache my_cache;
proxy_pass http://my_upstream;
}
}이 샘플 구성의 경우 http://www.example.org/my_image.jpg의 캐시 키는 md5(“http://my_upstream:80/my_image.jpg”)로 계산됩니다.
$proxy_host 변수는 실제 호스트 이름(www.example.com) 대신 해시된 값으로 사용됩니다. $proxy_host는 proxy_pass 지시문에 지정된 대로 프록시 서버의 이름과 포트로 정의됩니다.
키의 기초로 사용되는 변수(또는 다른 용어)를 변경하려면 proxy_cache_key 지시문을 사용하십시오(다음 질문 참조).
9. 내 캐시 키의 일부로 쿠키를 사용할 수 있습니까?
예, 캐시 키는 임의의 값으로 구성할 수 있습니다. 예를 들면 다음과 같습니다.
proxy_cache_key $proxy_host$request_uri$cookie_jessionid;이 예는 JSESSIONID 쿠키의 값을 캐시 키에 통합합니다. URI는 같지만 JSESSIONID 값이 다른 항목은 고유 항목으로 별도로 캐시됩니다.
10. NGINX는 ETag 헤더를 사용합니까?
NGINX 1.7.3 및 NGINX Plus R5 이상에서 ETag 헤더는 If-None-Match와 함께 완전히 지원됩니다.
11. NGINX는 바이트 범위 요청을 어떻게 처리합니까?
파일이 캐시에 최신 상태이면 NGINX는 바이트 범위 요청을 수락하고 항목의 지정된 바이트만 클라이언트에 제공합니다. 파일이 캐시되지 않았거나 오래된 경우 NGINX는 Origin 서버에서 전체 파일을 다운로드합니다. 단일 바이트 범위에 대한 요청인 경우 NGINX는 다운로드 스트림에서 해당 범위를 발견하는 즉시 해당 범위를 클라이언트에 보냅니다. 요청이 동일한 파일 내에서 여러 바이트 범위를 지정하는 경우 NGINX는 다운로드가 완료될 때 전체 파일을 클라이언트에 전달합니다.
다운로드가 완료되면 NGINX는 단일 범위 또는 다중 범위에 대한 모든 향후 바이트 범위 요청이 캐시에서 즉시 충족되도록 전체 리소스를 캐시로 이동합니다.
업스트림 서버는 NGINX가 해당 업스트림 서버에 대한 바이트 범위 요청을 존중하도록 바이트 범위 요청을 지원해야 합니다.
12. NGINX는 캐시 제거를 지원합니까?
NGINX Plus는 캐시된 파일의 선택적 제거를 지원합니다. 이것은 파일이 Origin 서버에서 업데이트되었지만 NGINX Plus 캐시에서 여전히 유효한 경우에 유용합니다(Cache-Control:max-age가 여전히 유효하고 비활성 매개변수가 proxy_cache_path 지시문에 설정한 제한 시간이 만료되지 않은 경우). . NGINX Plus의 캐시 제거 기능을 사용하면 이 파일을 쉽게 삭제할 수 있습니다. 자세한 내용은 캐시에서 콘텐츠 제거를 참조하십시오.
13. NGINX는 Pragma 헤더를 어떻게 처리합니까?
Pragma:no-cache 헤더는 모든 중간 캐시를 우회하고 요청된 콘텐츠에 대해 Origin 서버로 바로 이동하기 위해 클라이언트에 의해 추가됩니다. NGINX는 기본적으로 Pragma 헤더를 따르지 않지만 다음 proxy_cache_bypass 지시문을 사용하여 기능을 구성할 수 있습니다.
location /images/ {
proxy_cache my_cache;
proxy_cache_bypass $http_pragma;
# ...
}14. NGINX는 Cache-Control 헤더에 대한 stale-while-revalidate 및 stale-if-error 확장을 지원합니까?
예, NGINX Plus R12 및 NGINX 1.11.10 이상. 이 확장 프로그램이 하는 일:
- Cache-Control HTTP 헤더의 stale-while-revalidate 확장은 현재 업데이트 중인 경우 stale 캐시된 응답 사용을 허용합니다.
- Cache-Control HTTP 헤더의 stale-if-error 확장은 오류가 발생한 경우 stale 캐시된 응답을 사용할 수 있도록 합니다.
이러한 헤더는 위에서 설명한 proxy_cache_use_stale 지시문보다 우선 순위가 낮습니다.
15. NGINX는 Vary 헤더를 지원합니까?
예, NGINX Plus R5 및 NGINX 1.7.7 이상. 다음은 Vary 헤더에 대한 좋은 개요입니다.
