☰

Richtige Verwendung von Nginx als Web-Cache

tag-icon • tag-icon nginx
Richtige Verwendung von Nginx als Web-Cache

Ich versuche, Nginx als Web-Cache zu verwenden (was mir nicht gelingt).

Mein System ist ein Ubuntu 16.04-Server, bei dem Nginx ein Reverse-Proxy für einen Gunicorn-Webserver ist (es ist eine Django-Anwendung).

Um das Web-Caching zu konfigurieren, habe ich oben in meiner virtual hostDatei (in sites-available) die folgenden Zeilen hinzugefügt:

proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=static_cache:10m max_size=90m;
proxy_cache_key "$scheme$request_method$host$request_uri$is_args$args";
proxy_cache_valid 200 302 10m;
proxy_cache_valid 404 1m;

Als nächstes habe ich im Hauptbereich serverden folgenden Codeausschnitt (wo ich die Caching-Direktiven eingefügt habe):

location @https_proxy_to_app {
    proxy_cache static_cache;
    proxy_cache_bypass $http_cache_control;
    add_header X-Proxy-Cache $upstream_cache_status;

    proxy_set_header X-Forwarded-Proto https;
    # additional proxy parameters
    include proxy_params;

    proxy_redirect off;
    proxy_pass http://app_server;
}

Dies führt nicht zu Cache-Treffern oder -Fehlschlägen, wenn ich versuche, statische Asset-URIs zu curlen (was die einzige Möglichkeit ist, zu testen, ob der Cache funktioniert oder nicht). Ergo ist das Caching nicht betriebsbereit. Das meine ich damit:

Der Versuch curl -X GET -I https://example.com/static/css/my_app.cssergibt:

HTTP/1.1 200 OK
Server: nginx
Date: Wed, 22 Jan 2020 08:05:37 GMT
Content-Type: text/css
Content-Length: 26597
Last-Modified: Fri, 03 Jan 2020 14:23:59 GMT
Connection: keep-alive
Vary: Accept-Encoding
ETag: "5e0f4e7f-67e5"
Expires: Thu, 31 Dec 2037 23:55:55 GMT
Cache-Control: max-age=315360000
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Accept-Ranges: bytes

X-Proxy-Cache: HITDies ist problematisch, da es oder enthalten sollte X-Proxy-Cache: MISS. Bitte helfen Sie mir bei der Diagnose des Problems.

Nachfolgend sind alle meine locationBlöcke aufgeführt (in der Reihenfolge ihres Auftretens):

location ~* \.(?:ico|css|js|gif|jpg|jpeg|png|svg|woff|ttf|eot)$ {

    root /home/ubuntu/app/myproj/;
    access_log off;
    error_log off;

}

# shows number of connections at https://example.com/status_nginx
location /status_nginx {
    stub_status on;
    allow 127.0.0.1;
    deny all;
}

location / {

    limit_conn conn_limit_per_ip 20;
    limit_req zone=req_limit_per_ip burst=10 nodelay;

    limit_req_log_level warn;

    #proxy_pass_request_headers on;
    proxy_buffering on;
    proxy_buffers 24 4k;
    proxy_buffer_size 2k;
    proxy_busy_buffers_size 8k;

    try_files $uri @https_proxy_to_app;
}

location @https_proxy_to_app {

    proxy_cache static_cache;
    proxy_cache_bypass $http_cache_control;
    add_header X-Proxy-Cache $upstream_cache_status;

    proxy_set_header X-Forwarded-Proto https;
    # additional proxy parameters
    include proxy_params;

    proxy_redirect off;
    proxy_pass http://app_server;
}

Antwort1

Ihre .cssDatei wird mithilfe des folgenden Blocks in Ihrer Konfiguration bereitgestellt:

location ~* \.(?:ico|css|js|gif|jpg|jpeg|png|svg|woff|ttf|eot)$
    root /home/ubuntu/app/myproj/;
    access_log off;
    error_log off;
}

Das bedeutet, dass nginx die Datei direkt sendet, ohne den Upstream-Server zur Verarbeitung der Anfrage zu verwenden. Das bedeutet, dass kein Caching durchgeführt wird.

.cssWenn Sie die Erweiterung aus der Liste entfernen UND wenn Ihre nicht auf das Verzeichnis verweist, in dem diese CSS-Datei zu finden ist, wird die Anfrage an den Upstream-Server rootweitergeleitet .proxy_pass

Anschließend wird die Antwort zwischengespeichert, sofern der Upstream-Server geeignete HTTP-Cache-Header setzt.

verwandte Informationen