Мой прокси-сервер работает на ip A, и именно так люди получают доступ к моему веб-сервису. Конфигурация nginx будет перенаправлять на виртуальную машину на ip B.
Для прокси-сервера на IP A, у меня это на моих сайтах доступно
server {
listen 443;
ssl on;
ssl_certificate nginx.pem;
ssl_certificate_key nginx.key;
client_max_body_size 200M;
server_name localhost 127.0.0.1;
server_name_in_redirect off;
location / {
proxy_pass http://10.10.0.59:80;
proxy_redirect http://10.10.0.59:80/ /;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
server {
listen 80;
rewrite ^(.*) https://$http_host$1 permanent;
server_name localhost 127.0.0.1;
server_name_in_redirect off;
location / {
proxy_pass http://10.10.0.59:80;
proxy_redirect http://10.10.0.59:80/ /;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
Это proxy_redirect
было взято из того, как мне получить nginx для пересылки запросов HTTP POST через перезапись?
Все, что попадает на общедоступный IP-адрес, попадет на 443 из-за перезаписи. Внутренне мы пересылаем до 80 на виртуальной машине.
Но когда я запускаю скрипт python, такой как приведенный ниже, чтобы проверить нашу конфигурацию
import requests
data = {'username': '....', 'password': '.....'}
url = 'http://IP_A/api/service/signup'
res = requests.post(url, data=data, verify=False)
print res
print res.json
print res.status_code
print res.headers
Я получаю 405 Method Not Allowed
. В nginx мы обнаружили, что когда он попадает на внутренний сервер, внутренний nginx получает GET
запрос, хотя в исходном заголовке мы сделали POST
(это было показано в скрипте Python).
Таким образом, кажется, что переписать есть проблема. Есть идеи, как это исправить? Когда я прокомментировал переписывание, оно наверняка достигнет 80, и оно прошло. Поскольку перезапись была в состоянии общаться с нашим внутренним сервером, поэтому перезапись сама по себе не имеет проблем. Это просто переписано POST
на GET
.
Спасибо!
(Это также будет задано на форуме Nginx, потому что это критический блокировщик ...)
PUT
,POST
,DELETE
,GET
. В моей предыдущей настройке у меня не было этого дополнительного прокси на фронте, обслуживающего толпу. У меня была такая же конфигурация на том же внутреннем сервере (наш тестовый сервер). Это прекрасно работает.GET
. Никакая конфигурация на стороне сервера или любые возвращенные заголовки http не изменят это. По историческим причинам это так (ранние браузеры вели себя так из-за недопонимания, и это стало стандартом де-факто).POST
станет,GET
если он 301 или 302 перенаправлен. POST останется POST при перенаправлении прокси, но не при перезаписи.If the 307 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.
так что большинство браузеров выдают предупреждающее сообщение, что касается других HTTP-клиентов, я даже не могу догадаться, каково их поведение.Я обнаружил,
POST /api/brand
что превращается в,GET /api/brand
потому что веб-приложение, которое я использовал (flask-restful
), делало «недействительный» запрос. Если я использовалPOST /api/brand/
(обратите внимание на трейлинг/
), это было успешно.источник