容器中的應用程序不知道您正在轉發端口11080，因此當應用程序呈現響應時，如果它在X-Forwarded-xxxxx頭之后，它將使用X-Forwarded-Poroto來確定應該在哪里發送重定向。 根據您的應用程序，您有兩種選擇來處理這種情況： 識別X-Forwarded-Port頭的應用程序可以被告知重定向到特定的端口，例如在本例中： proxy_set_header X-Forwarded-Port 11080 不遵守標頭中提供的規則的遺留應用程序可以通過響應重寫傳遞來處理。以下是sub_filter的示例：sub_filter 'http:/my-ip/auth' 'http:/my-ip:11080/auth';要使sub_filter工作，應該安裝并啟用該模塊--with-http_sub_module

問題來自 upstream web-api { server web:5000;} 在dockerized環境中，web容器偵聽：80，因此您需要像這樣更改配置 upstream web-api { server web:80;}

沒有什么需要注意的。 您需要將jenkins.acue.io添加到主機條目中，并將其指向運行NginX的實例。然后使用FQDN訪問Jenkins。此外，你的proxy_redirect中有一個拼寫錯誤，你添加了httpsURL，而不是http://jenkins.acue.io也解決了這個問題。除此之外，您的NginX配置看起來不錯。 如果即使您是通過FQDN訪問，也繼續獲得NginX歡迎頁面，這意味著NginX不會接受您的配置。嘗試創建一個類似jenkins.conf的新文件，并將其添加到/etc/nginx/conf.d。然后做一個sudo systemctl restart nginx

這樣配置訪問http://localhost:8280/api/login，nginx是會代理請求到，http://localhost:8080/login的。出現404應是你后端http://localhost:8080/login返回的404狀態，先確認http://localhost:8080/login是否能正常訪問，在nginx所在的服務器curl測試。與查http://localhost:8080/的主機訪問日志，確認8280是否有請求到8080所在的主機，訪問到的是哪些地址，與狀態碼。通常反向代理都設置，proxy_set_header Host以確認前端能正確請求到后端相應的主機上。

對我來說，有效的方法是在admin的location塊上使用rewrite，這樣下游nginx就會收到干凈的路徑。 經過一些修改后，全局配置如下所示： user nginx;events { worker_connections 1024;}http { include /etc/nginx/mime.types; server { listen 80; location /admin { rewrite /admin(.*) /$1 break; proxy_pass http://frontend-admin:80; } location / { proxy_pass http://frontend:80; } }} 應用程序配置如下所示： user nginx;events { worker_connections 1024;}http { include /etc/nginx/mime.types; sendfile on; server { listen 80; location / { root /usr/share/nginx/html; index index.html index.htm; try_files $uri $uri/ /index.html =404; } }} 然后，請求被正確地轉發到管理nginx： frontend-admin | 172.21

只是一個猜測。 你想在/上點什么嗎？ 如果沒有-很容易： server{ listen 80; server_name localhost; location /support/ { alias /var/www/html/; try_files $uri $uri/ /index.html; } location / { return 303 http://localhost/support$request_uri; }} 如果結尾的斜杠不起作用，你可以隨意擺弄它（使用或不使用它們通常會產生不同的效果）。 使用alias而不是root，這樣/support就不會添加到/var/www/html文件夾中。 所有內容都被重定向到/support。 如果您想在/上提供與/support不同的東西： 在/support中使用sub_filter或subs_filter重寫源代碼鏈接on-the-fly，這樣他們就永遠不會使用/。 如果在源代碼（或proxy_pass后端）中有重定向，則需要proxy_redirect和/或Lua來捕獲并更改on-the-fly。

我做了幾次搜索，發現在物理機器上安裝nginx的反向代理或者使用容器時沒有問題，所以我選擇使用容器。

問題是我必須使用docker-compose服務的名稱，而不是localhost。這是合理的，因為nginx的容器在localhost上不包含任何其他應用。 最終的解決方案如下所示： http { upstream mobile { server mobile-app:8081; } upstream desktop { server desktop-app:8082; } # regexps from http://detectmobilebrowsers.com/ map "$http_user_agent" $upstream { default desktop; "~*(android|bb\d+|meego).+mobile|avantgo|bada\/|blackberry|blazer|compal|elaine|fennec|hiptop|iemobile|ip(hone|od)|iris|kindle|lge |maemo|midp|mmp|mobile.+firefox|netfront|opera m(ob|in)i|palm( os)?|phone|p(ixi|re)\/|plucker|pocket|psp|series(4|6)0|symbian|treo|up\.(browser|link)|vodafone|wap|windows ce|xda|xi

嘗試在位置塊中使用重寫指令。 Something like: location /example1/ { rewrite ^/example1/(.*)$ /$1 break; proxy_pass http://xxxxxx;} 您可以在http://nginx.org/en/docs/http/ngx_http_rewrite_module.html查看與重寫模塊相關的文檔

謝謝你的提示@David、@Beppe和@Yusuf。在我的例子中，我只是將API端點更改為應用程序地址。 如果應用程序運行在 localhost:3001 然后我將api端點設置為 localhost:3001/api 在nginx配置中，我使用re-write條件在服務器塊中添加另一個位置 upstream api { server api:5000;}server { listen 80; location / { root /usr/share/nginx/html; } location /api { rewrite /api/(.*) /$1 break; proxy_pass http://api }}

這個工具幾乎具備了設置nginx反向代理所需的一切。 請注意，由于其配置中有此注釋行，它不支持開箱即用的wss://。 #proxy_set_header Connection \$connection_upgrade; 取消對它的注釋，重新生成并擁有一個支持wss://的快樂反向代理：）

我不確定我是否理解你的問題。為什么ppl不發布他們的服務器塊？我還是試著： location /myapp/ { proxy_pass http://x.x.x.x:8059/; } 或者反過來說： server{ listen 8059; server_name x.x.x.x example.org www.example.org; # … location / { proxy_pass http://x.x.x.x:80/myapp/; }} 很容易發生的是，現在你的道路被打破了。在代碼中更改它們，或者在proxy_redirect和sub(s)_filter中查看on-the-fly更改。 瀏覽器->鍵[F12]->控制臺和/或網絡總是有用的。 在Windows上也很好：安裝Git，打開gitbash并執行curl -IL <URL>。

考慮一下這個位置： location ~ .*/api/(.*) { proxy_pass http://rest-api:9000/api/$1; } 這是一個正則表達式位置，它將任何URI與/api/匹配。例如，它將用于： example.com/api/foo/barexample.com/api/example.com/something/api/foo/bar 有一個捕獲組(.*)來記錄/api/之后的內容。它被保存為位置變量$1（因為它是表達式中的第一個也是唯一一個捕獲組）。使用它，您可以構建到API后端的精確路徑： proxy_pass http://rest-api:9000/api/$1; 它將把上面的例子變成： proxy_pass http://rest-api:9000/api/foo/barproxy_pass http://rest-api:9000/api/proxy_pass http://rest-api:9000/api/foo/bar

minio在location/minio等非默認路徑下不工作 你需要使用location/{…proxy_passhttp://localhost:9001；}或者使用下面的子域向nginx添加另一個服務器塊 server{listen 80;server_name minio.example.com;; location / { proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header Host $http_host; proxy_pass http://localhost:9001; }}

每個請求都會在某個位置結束（如果之前沒有完成）。每個位置都使用自己的內容處理程序。除非您通過內容處理程序聲明指令明確指定某些內容（例如，位不限于proxy_pass、fastcgi_pass、uwsgi_pass、etc.)），否則它將是一個靜態內容處理程序，用于從本地文件系統提供請求的內容。請查看我的服務器故障答案（1、2）以了解更多詳細信息。 在某些情況下，這樣的任務可以使用map塊來解決，例如：。 map $uri $log { ~^/(?:favicon|apple-touch-icon) off; default /var/log/nginx/access.log;}server { ... access_log $log; 當您需要實現條件基本身份驗證（示例）時，這種方法可以工作。不幸的是，它不能與access_log指令一起工作-相反，nginx將為圖標請求創建第二個名為off的日志文件。因此，如果您希望將每個請求傳遞到12.23.45.78上游，我看不到任何其他方法，只能為這兩個位置復制內容處理程序聲明。但是，每一個其他使用的指令都可以上移一級，從而被兩個位置繼承： server { listen 80; listen [::]:80; server_name www.test.com; error_log /var/log/nginx/www.test.com.e