Когда я настраиваю обратный прокси-сервер на пересылку со своего собственного порта 80 на собственный порт 8080, я так и сделал, я получаю следующее предупреждение
2016/03/28 22:05:59 [alert] 4193#0: 512 worker_connections are not enough
, которое предположительно является результатом бесконечного цикла.
В принятом ответе для Nginx Config: Front-End Reverse Proxy to Other Port пользователь написал "I" Ждем себя? Или есть еще одна причина, по которой происходит этот бесконечный цикл, и этот комментарий был просто отвлекающим маневром?
Ниже мой nginx.conf. Я получаю предупреждение, когда захожу на router.example.com. Когда я удаляю то, что находится между #### BEGIN BAD LINES ####
, все работает нормально.
user root;
worker_processes 1;
worker_cpu_affinity 0101;
master_process off;
worker_priority 10;
error_log /tmp/var/log/nginx/error.log;
pid /tmp/var/run/nginx.pid;
worker_rlimit_nofile 8192;
events {
worker_connections 512;
}
http {
log_format main '$remote_addr - $remote_user [$time_local] $status '
'"$request" $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
# Because end of http://nginx.org/en/docs/http/server_names.html
server_names_hash_bucket_size 64;
# From NixCraft
# http://www.cyberciti.biz/tips/using-nginx-as-reverse-proxy.html
# Host required
server {
listen 80 default_server;
server_name "";
return 444;
}
#### BEGIN BAD LINES ####
## Start router proxy ##
server {
listen 80;
server_name router.example.com
tomatopaste.example.com;
access_log /var/log/nginx/log/router.example.access.log main;
error_log /var/log/nginx/log/router.example.error.log;
## send request back to apache1 ##
location / {
proxy_pass http://192.168.1.1:8080/;
proxy_redirect default;
proxy_buffering off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
## End ##
#### END BAD LINES ####
## Start primary proxy ##
server {
listen 80;
server_name jira.example.com
confluence.example.com
stash.example.com
cacti.example.com;
access_log /var/log/nginx/log/lamp.example.access.log main;
error_log /var/log/nginx/log/lamp.example.error.log;
## send request back to apache1 ##
location / {
proxy_pass http://192.168.1.99/;
proxy_redirect default;
proxy_buffering off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
## End ##
map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}
# Websockets
server {
listen 8686;
server_name other.example.com;
location / {
proxy_pass http://192.168.1.99:8686;
proxy_redirect default;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
}
}
}
Я думаю, проблема не в том, «Почему обратный прокси-сервер не может указывать на себя?» так много, как «Почему не должен обратный прокси указывать на себя?». Как отмечали комментаторы, nginx
, httpd
и другое программное обеспечение прокси можно настроить на прокси-соединения обратно к себе; ничто в программном обеспечении или конфигурации не предотвращает этого.
Однако, как вы предполагаете, проблема становится одной из ресурсов. Обратный прокси-сервер HTTP, настроенный для прокси-запросов обратно к себе (прямо или косвенно через другой прокси, например httpd
), должен поддерживать какое-то состояние для этого запроса (чтобы отправить ответ обратно вызывающему. ). Если запрос просто повторно проходит через одни и те же прокси-серверы (из-за конфигурации), в конечном итоге достигается некоторый предел состояния / ресурса, , например :
512 worker_connections are not enough
, и пересылка запроса прекращается. Таким образом, ответ на вопрос «Почему не должен обратный прокси указывать на себя?» это: «В конце концов, у обратного прокси-сервера заканчиваются ресурсы, и он не может должным образом обработать запрос». По мере увеличения количества обратных прокси в цепочке вероятность непреднамеренного конфигурирования, приводящего к циклу / циклу, увеличивается, и по мере увеличения количества прокси в цикле тем труднее может быть обнаружить , что такие происходит петля. (Возможно, такие приложения, как httpd
и nginx
, могут проверять такие заголовки, как X-Forwarded-For
, предполагая, что значение заголовка является доверенным, для обнаружения таких петель, т.е. , чтобы увидеть, присутствует ли уже сам прокси в этой цепочке пересылки?)
В вашем конкретном случае, чтобы эмпирически доказать, что это действительно бесконечный цикл пересылки, нам нужно будет сопоставить httpd
записи журнала с записями журнала nginx
; Я подозреваю, что, сделав это, мы действительно увидим цикл на графике обратного проксирования.
Надеюсь, это поможет!