Зворотний проксі Nginx, що спричиняє 504 тайм-аут шлюзу

Я використовую Nginx як зворотний проксі, який приймає запити, то робить proxy_pass, щоб отримати фактичний веб-додаток від верхнього сервера, що працює на порту 8001.

Якщо я заходжу на mywebsite.com або роблю wget, я отримую 504 тайм-аут шлюзу через 60 секунд ... Однак, якщо я завантажую mywebsite.com:8001, програма завантажується як очікувалося!

Тож щось заважає Nginx спілкуватися з сервером висхідного потоку.

Все це почалося після того, як моя хостингова компанія скинула машину, на якій працювали мої речі, до цього жодних питань не було.

Ось мій блок сервера vhosts:

server {
    listen   80;
    server_name mywebsite.com;

    root /home/user/public_html/mywebsite.com/public;

    access_log /home/user/public_html/mywebsite.com/log/access.log upstreamlog;
    error_log /home/user/public_html/mywebsite.com/log/error.log;

    location / {
        proxy_pass http://xxx.xxx.xxx.xxx:8001;
        proxy_redirect 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;
    }
} 

І вихід з мого журналу помилок Nginx:

2014/06/27 13:10:58 [error] 31406#0: *1 upstream timed out (110: Connection timed out) while connecting to upstream, client: xxx.xx.xxx.xxx, server: mywebsite.com, request: "GET / HTTP/1.1", upstream: "http://xxx.xxx.xxx.xxx:8001/", host: "mywebsite.com"

Можливо, ви можете додати ще кілька рядків, щоб збільшити період очікування вгору за течією. Наведені нижче приклади встановлюють час очікування на 300 секунд:

proxy_connect_timeout       300;
proxy_send_timeout          300;
proxy_read_timeout          300;
send_timeout                300;

Збільшення тайм-аута, ймовірно, не вирішить вашу проблему, оскільки, як ви кажете, фактичний цільовий веб-сервер реагує просто чудово.

У мене був цей самий випуск, і я виявив, що це пов'язано з тим, що не використовую живого зв'язку під час з'єднання. Насправді я не можу відповісти, чому це так, але, очистивши заголовок з'єднання, я вирішив цю проблему, і запит був проксі проксі:

server {
    location / {
        proxy_set_header   X-Real-IP $remote_addr;
        proxy_set_header   Host      $http_host;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_pass http://localhost:5000;
    }
}

Перегляньте це повідомлення, яке пояснює це більш докладно: nginx закрити підключення до потоку після запиту Роз'яснення в заголовку в режимі "живі" http://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive

user2540984 , а також багато інших вказали, що ви можете спробувати збільшити налаштування тайм-ауту. Я сам стикався з подібною проблемою з цим і намагався змінити налаштування тайм-ауту у файлі /etc/nginx/nginx.conf , як це пропонують майже всі в цих потоках . Це, однак, не допомогло мені жодного шматочка; явних змін у налаштуваннях часу очікування NGINX не було. Після багатьох годин пошуку я нарешті зумів вирішити своє питання.

Рішення полягає в цій темі форуму , і в ньому йдеться про те, що слід встановити налаштування тайм-ауту в /etc/nginx/conf.d/timeout.conf (і якщо цього файлу не існує, його слід створити). Я використовував ті самі налаштування, що і в потоці:

proxy_connect_timeout 600;
proxy_send_timeout 600;
proxy_read_timeout 600;
send_timeout 600;

Це може бути не вирішенням вашої конкретної проблеми, але якщо хтось інший помітить, що час / час зміни в /etc/nginx/nginx.conf нічого не робить, я сподіваюся, що ця відповідь допоможе!

Якщо ви хочете збільшити або додати обмеження часу для всіх сайтів, ви можете додати нижче рядки до nginx.confфайлу.

Додайте рядки нижче до httpрозділу /usr/local/etc/nginx/nginx.confабо /etc/nginx/nginx.confфайлу.

fastcgi_read_timeout 600;
proxy_read_timeout 600;

Якщо вищезазначених рядків у confфайлі не існує, додайте їх, інакше збільште fastcgi_read_timeoutі proxy_read_timeoutпереконайтеся, що nginx та php-fpm не закінчилися.

Щоб збільшити часовий ліміт лише для одного сайту, ви можете редагувати in vim /etc/nginx/sites-available/example.com

location ~ \.php$ {
    include /etc/nginx/fastcgi_params;
        fastcgi_pass  unix:/var/run/php5-fpm.sock;
    fastcgi_read_timeout 300; 
}

а після додавання цих рядків до nginx.confне забудьте перезапустити nginx.

service php7-fpm reload 
service nginx reload

або, якщо ви використовуєте камердинер, просто введіть valet restart.

Ви також можете зіткнутися з цією ситуацією, якщо ваш сервер вище за течією використовує доменне ім’я, а його IP-адреса змінюється (наприклад: ваш верхній потік вказує на AWS Elastic Load Balancer)

Проблема полягає в тому, що nginx одноразово вирішить IP-адресу та збереже її в кешованому режимі для наступних запитів, поки конфігурація не буде перезавантажена.

Ви можете сказати nginx використовувати сервер імен для повторного вирішення домену після закінчення терміну кешування:

location /mylocation {
    # use google dns to resolve host after IP cached expires
    resolver 8.8.8.8;
    set $upstream_endpoint http://your.backend.server/;
    proxy_pass $upstream_endpoint;
}

Документи на proxy_pass пояснюють, чому цей трюк працює:

Значення параметра може містити змінні. У цьому випадку, якщо адреса вказана як доменне ім'я, ім'я шукається серед описаних груп серверів і, якщо його не знайдено, визначається за допомогою роздільної здатності.

Kudos для "Nginx з динамічними висхідними потоками" (tenzer.dk) для детального пояснення, яке також містить деяку відповідну інформацію щодо застереження цього підходу щодо перенаправлених URI.

Була така ж проблема. Виявилося, це було викликано відстеженням iptables з'єднання на верхньому сервері. Після видалення --state NEW,ESTABLISHED,RELATEDсценарію брандмауера та conntrack -Fпомилки з проблемою не було.

Сама по собі NGINX не може бути першопричиною.

ЯКЩО "мінімальний порт на екземпляр VM", встановлений на шлюзі NAT - який стоїть між вашим екземпляром NGINX та proxy_passпунктом призначення - занадто малий для кількості одночасних запитів, його потрібно збільшити.

Рішення: збільшити доступну кількість портів на VM на NAT Gateway.

Контекст У моєму випадку в Google Cloud, зворотний проксі-сервер NGINX був розміщений всередині підмережі з NAT шлюзом. Екземпляр NGINX перенаправляв запити до домену, асоційованого з нашим API резервного інтерфейсу (вище за течією) через шлюз NAT.

Ця документація від GCP допоможе вам зрозуміти, наскільки NAT має відношення до часу очікування NGINX 504.

У моєму випадку я перезавантажую php для, і це стає нормально.