我有一個具有此設定的服務器：
在根 (/var/www) 檔案夾中，我有一個index.html鏈接到 angular app1和app2
\index.html
|
-\app1\index.html
|
-\app2\index.html
我的 Angular app2 中有資料，URL所以我URL看起來像這樣：
https://www.example.com/app2/thispartisdata/AlongDataStringThatContainsData
當我瀏覽https://www.example.com/app2 一切正常
當我瀏覽到https://www.example.com/app2/somedata這個去的404訊息NGINX
我已經嘗試過try_files配置選項，但我的第二個應用只需要它。
所以我想做的是這樣的（但我無法弄清楚或找到語法是什么，或者它是否可能）
location /app2 {
try_files $uri $uri/ /app2/index.html;
}
我無法讓上述作業。我希望對 app2 的請求將整個傳遞URL給app2而不會NGINX妨礙并回傳404. 我找不到只有app2接收完整 URL 并將完整重定向URL到app2 的 index.html正確方法。
編輯
我的完整配置：
server {
server_name example.com www.example.com;
location /app1/api/ {
proxy_pass https://127.0.0.1:5001;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection keep-alive;
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
location /app2/api/ {
proxy_read_timeout 300s;
proxy_connect_timeout 75s;
proxy_pass https://127.0.0.1:5002/;
proxy_http_version 1.1;
proxy_request_buffering off;
proxy_buffering off;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection keep-alive;
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
# I want to do something like this here, but this give a 500 error
#
# location /app2 {
# try_files $uri /app2/index.html;
# }
location / {
root /var/www;
index index.html;
}
ssl_stapling on;
ssl_stapling_verify on;
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}
server {
if ($host = www.example.com) {
return 301 https://$host$request_uri;
} # managed by Certbot
if ($host = example.com) {
return 301 https://$host$request_uri;
} # managed by Certbot
server_name example.com www.example.com;
listen 80;
return 404; # managed by Certbot
}
uj5u.com熱心網友回復：
您在這里的主要錯誤是您沒有在級別root上為您的網站定義。server您root /var/www;只在該地區有效，在location / { ... }其他任何地方都無效。與許多其他 nginx 指令一樣root，該指令如果不是從以前的配置級別繼承的，則具有/html相對于 nginx前綴的默認值。該前綴是在構建期間指定的，可以使用nginx -V命令檢查（請參閱--prefix=...配置引數）。例如，如果此前綴等于/etc/nginx（常見情況），則默認服務器 webroot 將為/etc/nginx/html. 您需要將該指令向上移動一級，server而不是location一級。
完成后，您可以添加
location /app2/ {
try_files $uri /app2/index.html;
}
到你的server街區。我在這里不使用$uri/組件，因為我不希望您在app2index.html Web 應用程式目錄下嵌套任何其他內容。重定向 from to將由 nginx 自動進行，因為在您的隱含將用作默認請求處理階段處理程式，并且請求將由而不是./app2/index.html/app2/app2/location / { ... }try_files $uri $uri/ =404PRECONTENT/app2location / { ... }location /app2/ { ... }
我不明白的是，你的app1如何在沒有類似的情況下作業
location /app1/ {
try_files $uri /app1/index.html;
}
定位塊。也許它沒有互動部分并且僅用作 API？
接下來對我來說似乎有些奇怪的是您的app1 / app2 API 位置。proxy_pass您在第二個位置 ( ) 中使用指令的 URI 后綴，proxy_pass https://127.0.0.1:5002/;而不是在第一個位置 ( ) 使用它proxy_pass https://127.0.0.1:5001;。這意味著請求 like/app1/api/endpoint將按原樣出現在您的app1中，而 request like/app2/api/endpoint將按原樣出現在您的app2中/endpoint。如果您使用proxy_pass https://127.0.0.1:5001/app1/;并且proxy_pass https://127.0.0.1:5002/app2/;這兩個請求都會在您的后端顯示為/api/endpoint. 您可以在此處找到有關此proxy_pass指令行為的更多資訊. 但是，如果這兩個 API 都按預期作業，那么您的后端應用程式可能會期望以這種不同的形式發出請求，并且您不需要更改任何內容。盡管如此，我認為值得一提的是這種差異。
最后一件事是關于代理 API 請求的其他設定。我從未見過任何proxy_set_header Connection keep-alive;明確使用的配置；保持與上游連接的常用方法是使用帶有指定引數upstream的塊宣告它（示例）。最有可能取自官方 WebSocket 代理示例，如果沒有其余配置，這里將毫無意義。有關這些 HTTP 標頭和來自 MDN 的相關主題的更多技術細節：, , . 通過和禁用請求/回應緩沖keepaliveproxy_set_header Upgrade $http_upgrade;ConnectionKeep-AliveUpgradeproxy_request_buffering off;proxy_buffering off;應用于 API 呼叫時，我也覺得很奇怪；通常，當您需要有關 API 呼叫不太可能的請求/回應進度的某種實時資訊時使用它。
轉載請註明出處，本文鏈接：https://www.uj5u.com/qianduan/487230.html
下一篇：無法獲取靜態json檔案