Wenn ich nginx als Reverse-Proxy vor einer anderen Webanwendung verwende, scheint es, als würden PUTdie Anfragen nicht weitergeleitet, sondern es wird ein von nginx (und nicht vom Upstream-Server) generierter HTTP 405-Fehler angezeigt.
Ich habe die proxy_next_upstreamMethode für http_405 ausprobiert, aber sie hat nicht funktioniert. Ich frage mich, warum nginx selbst trotzdem die HTTP-Methode für einen Standortblock überprüft, für den ein Reverse_Proxy konfiguriert ist.
Antwort1
Nginx ist hier nicht das Problem. Es leitet PUTAnfragen wie erwartet in Reverse-Proxy-Blöcken weiter, wenn diese locationmit der Anfrage übereinstimmen.
Ich hatte eine weitere locationDirektive, die sicherstellt, dass Bilder nicht über den Reverse-Proxy bereitgestellt werden. Sie stimmte .pngam Ende mit allem überein (und einigen anderen Dateierweiterungen), was auch mit den Upload-URLs übereinstimmte.
Bei einem falschen Standortblock ist der Fehler 405 korrekt. Die Lösung besteht darin, sicherzustellen, dass die Upload-Anfragen tatsächlich an den Reverse-Proxy weitergeleitet werden.
Ein Beispiel für eine funktionierende Reverse-Proxy-Konfiguration:
# proxy requests for /upload the a webapp, which implements PUT
location ^~ /upload {
proxy_pass "https://backendserver:1234/something";
proxy_http_version 1.1;
proxy_set_header Host $host;
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_buffering off;
tcp_nodelay on;
}
Die Konfiguration funktioniert einwandfrei, sofern keine anderen Standortblöcke vorhanden sind, die Vorrang haben.
Mein Problem war ein anderer Block:
# This block matched requests for /upload/somefile.png before the proxy block
location ~* ^(/.*png|/.*jpg|/.*jpeg|/.*gif)$ {
# some directives without proxy_pass
}