Почему обратный прокси-сервер не может указывать на себя?

Когда я настраиваю обратный прокси-сервер на пересылку со своего собственного порта 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;
        }
    } 
}
0
задан 13 April 2017 в 15:14
1 ответ

Я думаю, проблема не в том, «Почему обратный прокси-сервер не может указывать на себя?» так много, как «Почему не должен обратный прокси указывать на себя?». Как отмечали комментаторы, nginx , httpd и другое программное обеспечение прокси можно настроить на прокси-соединения обратно к себе; ничто в программном обеспечении или конфигурации не предотвращает этого.

Однако, как вы предполагаете, проблема становится одной из ресурсов. Обратный прокси-сервер HTTP, настроенный для прокси-запросов обратно к себе (прямо или косвенно через другой прокси, например httpd ), должен поддерживать какое-то состояние для этого запроса (чтобы отправить ответ обратно вызывающему. ). Если запрос просто повторно проходит через одни и те же прокси-серверы (из-за конфигурации), в конечном итоге достигается некоторый предел состояния / ресурса, , например :

512 worker_connections are not enough

, и пересылка запроса прекращается. Таким образом, ответ на вопрос «Почему не должен обратный прокси указывать на себя?» это: «В конце концов, у обратного прокси-сервера заканчиваются ресурсы, и он не может должным образом обработать запрос». По мере увеличения количества обратных прокси в цепочке вероятность непреднамеренного конфигурирования, приводящего к циклу / циклу, увеличивается, и по мере увеличения количества прокси в цикле тем труднее может быть обнаружить , что такие происходит петля. (Возможно, такие приложения, как httpd и nginx , могут проверять такие заголовки, как X-Forwarded-For , предполагая, что значение заголовка является доверенным, для обнаружения таких петель, т.е. , чтобы увидеть, присутствует ли уже сам прокси в этой цепочке пересылки?)

В вашем конкретном случае, чтобы эмпирически доказать, что это действительно бесконечный цикл пересылки, нам нужно будет сопоставить httpd записи журнала с записями журнала nginx ; Я подозреваю, что, сделав это, мы действительно увидим цикл на графике обратного проксирования.

Надеюсь, это поможет!

1
ответ дан 4 December 2019 в 16:39

Теги

Похожие вопросы