所以我已經用 Puma 替換了一個 Rails 應用程式的乘客，我只是注意到我現在遇到了 cdn 資產問題，他們現在給出了 CORS 錯誤。
當我使用Passenger時，我有以下Nginx配置：
server {
server_name mysite.com;
root /var/www/mysite.com/public;
client_max_body_size 4000M;
passenger_enabled on;
rails_env production;
location ~* ^/cdn/ {
add_header Access-Control-Allow-Origin *;
expires 364d;
add_header Pragma public;
add_header Cache-Control "public";
break;
}
location ~* ^/assets/ {
# Per RFC2616 - 1 year maximum expiry
# http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
expires 1y;
add_header Cache-Control public;
# Some browsers still send conditional-GET requests if there's a
# Last-Modified header or an ETag header even if they haven't
# reached the expiry date sent in the Expires header.
add_header Last-Modified "";
add_header ETag "";
break;
}
listen 443 ssl; # managed by Certbot
#the rest of the certbot ssl stuff
}
然后我將配置更改為這個以使其與 Puma 和 unix 套接字一起使用：
upstream puma {
server unix:///var/www/mysite.com/shared/sockets/puma.sock;
}
server {
server_name mysite.com;
root /var/www/mysite.com/public;
client_max_body_size 4000M;
location / {
try_files $uri @app;
}
location ~* ^/cdn/ {
add_header Access-Control-Allow-Origin *;
expires 364d;
add_header Pragma public;
add_header Cache-Control "public";
break;
}
location ~* ^/assets/ {
# Per RFC2616 - 1 year maximum expiry
# http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
expires 1y;
add_header Cache-Control public;
# Some browsers still send conditional-GET requests if there's a
# Last-Modified header or an ETag header even if they haven't
# reached the expiry date sent in the Expires header.
add_header Last-Modified "";
add_header ETag "";
break;
}
listen 443 ssl; # managed by Certbot
#ssl stuff
location @app {
proxy_pass http://puma;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Proto https;
proxy_set_header Host $http_host;
proxy_headers_hash_max_size 512;
proxy_headers_hash_bucket_size 128;
proxy_redirect off;
}
}
這作業正常，但后來我注意到 cdn url 給出了 404，所以我將 cdn 位置更新為此（我添加try_files $uri @app;）：
location ~* ^/cdn/ {
add_header Access-Control-Allow-Origin *;
expires 364d;
add_header Pragma public;
add_header Cache-Control "public";
try_files $uri @app;
break;
}
這現在有效，但我得到了 CORS 錯誤，所以似乎標題沒有設定。
我的猜測是try_files忽略了在呼叫它之前設定的內容，所以我嘗試在location @app（通過添加proxy_set_header Access-Control-Allow-Origin *;）內部設定訪問控制的代理標頭，但我仍然得到錯誤。
這樣做的正確方法是什么？
uj5u.com熱心網友回復：
嘗試使用指令添加回應標頭是沒有意義的proxy_set_header- 它旨在為將發送到上游的請求添加/更改標頭。要添加回應標頭，無論是靜態位置還是代理位置，都使用add_header一個。要有條件地添加標頭，可以說取決于請求 URI，您可以使用以下map塊：
map $uri $expires {
~^/cdn/ 1y;
default off;
}
map $uri $cache_control {
~^/cdn/ public;
# default will be an empty value
}
map $uri $allow_origin {
~^/cdn/ *;
# default will be an empty value
}
但是在性能方面，由于所有map-derived 變數在每個請求中只評估一次，因此只匹配一次正則運算式模式可能會稍微提高性能：
map $cache $expires {
1 1y;
default off;
}
map $cache $cache_control {
1 public;
}
map $cache $allow_origin {
1 *;
}
map $uri $cache {
~^/cdn/ 1;
}
接下來，在您的@app位置，您可以使用以下內容：
location @app {
proxy_pass http://puma;
expires $expires;
add_header Cache-Control $cache_control;
add_header Access-Control-Allow-Origin $allow_origin;
# ... proxy_set_... and other upstream setup here
}
如果指令中使用的評估變數add_header為空，則 nginx 不會添加具有空值的標頭 - 相反，它根本不會添加這樣的標頭。
關于您當前配置的一些注意事項：
使用類似
location ~ ^/cdn/ { ... }或location ~ ^/assets/ { ... }支持前綴位置的那種正則運算式位置，location /cdn/ { ... }或者location /assets/ { ... }沒有意義，只會影響性能（由于不需要時會涉及 PCRE 庫）。靜態位置末尾的那個
break指令什么都不做，因為那里的重寫模塊沒有任何指令應該停止執行。
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/480560.html
標籤：nginx nginx-反向代理 nginx位置 彪马
上一篇：將引數傳遞給@proxy位置？