Когда я устанавливаю обратный прокси-сервер для пересылки с собственного порта 80 на собственный порт 8080, я делаю это и получаю следующее предупреждение
2016/03/28 22:05:59 [alert] 4193#0: 512 worker_connections are not enough
что предположительно является результатом бесконечного цикла.
В принятом ответе на Конфигурация Nginx: внешний обратный прокси-сервер для другого порта, пользователь написал: «Я предполагаю, что nginx не является сервером, который прослушивает порт 5010, а также 80, правильно?» Это потому, что обратные прокси не могут пересылать сами себе? Или есть еще одна причина, по которой возникает этот бесконечный цикл, и этот комментарий был просто отвлекающим маневром?
Ниже мой 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
записи журнала; Я подозреваю, что, сделав это, мы действительно увидим цикл на графике обратного проксирования.
Надеюсь это поможет!