[英]502 Bad Gateway with DigitalOcean (gunicorn/nginx) using Selenium and Django
我有一個使用 Selenium 和 Django 的帶有 DigitalOcean(gunicorn/nginx)的網絡應用程序。
我正在嘗試從 3 個網站抓取數據並將這些數據保存在數據庫中,但如果該過程花費超過 60 秒,我會收到此錯誤
502 Bad Gateway
nginx/1.14.0 (Ubuntu)
如何延長或禁用 nginx 的響應等待時間?
這個錯誤信息...
502 Bad Gateway
nginx/1.14.0 (Ubuntu)
...使用DigitalOcean (gunicorn/nginx)的原因有很多。 確定 502 錯誤的確切原因取決於您使用的 Web 服務器以及解釋請求的應用程序服務器。
錯誤的網關錯誤通常是由網絡服務器和應用程序處理程序之間的通信中斷引起的。 在許多情況下,潛在問題要么是延遲過大,要么是超時窗口過短。
有時, 502 Bad Gateway也是由錯誤配置的應用程序服務器引起的,當 Web 服務器理解請求並將其傳遞給適當的處理程序時,但兩者之間發生了某種類型的中斷。
Gunicorn是廣泛使用的 Python WSGI 服務器之一,診斷502 Bad Gateway錯誤的原因主要取決於您使用的應用程序服務器,一些常見問題如下:
Gunicorn 未運行:您需要使用ps
確保Gunicorn正在運行。 為了確保Gunicorn正在運行,您必須看到類似的輸出:
www-data@nginx0:/var/log/nginx$ ps aux | grep gunicorn www-data 13805 0.0 1.8 52292 18460 pts/0 S 20:32 0:00 /home/www-data/test_app/bin/python /home/www-data/test_app/bin/gunicorn --error-logfile /var/log/gunicorn/errors.log -b 0.0.0.0:8080 wsgi www-data 13836 0.0 1.5 52432 15392 pts/0 S 20:34 0:00 /home/www-data/test_app/bin/python /home/www-data/test_app/bin/gunicorn --error-logfile /var/log/gunicorn/errors.log -b 0.0.0.0:8080 wsgi
Gunicorn 無法啟動:有時,Gunicorn 無法啟動是由於配置文件中的拼寫錯誤或端口沖突或無法訪問的日志目錄或這些情況的任何組合。 在這些情況下,要檢查您的 Gunicorn 配置,請執行以下命令:
gunicorn --check-config [APP_MODULE]
NGINX 配置錯誤:如果Gunicorn 配置正確, NGINX
可能沒有在正確的位置尋找它。 在這些情況下,打開NGINX
配置文件 ( /etc/nginx/nginx.conf
) 並查找以upstream
關鍵字開頭的塊,如下所示:
upstream app_servers { server 127.0.0.1:8080; }
此設置用於配置NGINX
以將NGINX
請求重定向到127.0.0.1:8080
。 如果 Gunicorn 未綁定到 127.0.0.1 或未在 8080 上偵聽,請更改 Gunicorn 的配置以匹配 NGINX 的配置,或更改 NGINX 的配置以匹配 Gunicorn 的配置。 此外,驗證您的站點配置是否將您的應用程序重定向到適當的上游服務器。 為確保這一點,您需要打開站點的配置,即/etc/nginx/sites-enabled/your_site
並查找定義應用程序 URL 端點的塊。 舉個例子:
location /my-app { proxy_pass http://app_servers; 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; proxy_set_header X-Forwarded-Host $server_name; }
Gunicorn 超時:如果您的應用程序需要很長時間才能響應(默認情況下 > 30 秒),Gunicorn 可能會向NGINX
返回502
。 這可以通過檢查 Gunicorn 日志來驗證(如果沒有設置日志文件,則默認為 STDOUT)。 舉個例子,
[2016-09-21 20:33:04 +0000] [13805] [CRITICAL] WORKER TIMEOUT (pid:13810)
上面的日志暗示,應用程序響應 Gunicorn 的時間太長,導致工作線程被殺死,因為 Gunicorn 認為工作線程掛了。 在這種情況下,增加 Gunicorn 的最大執行時間將是最好的解決方案。 但是,從應用程序和數據集處理的角度來看,增加超時窗口可能不是最佳解決方案,您可能需要分析和優化正在使用的應用程序。
調整read_timeout
:如果在修改 Gunicorn 的超時閾值后仍然看到502 Bad Gateway ,則需要按照下面提到的這些步驟來增加NGINX
的超時窗口:
/etc/nginx/nginx.conf
)fastcgi_read_timeout XXX;
在http
塊中,其中XXX
是以秒為單位的超時窗口(請參見下面的示例)一個例子:
http { ... fastcgi_buffers 8 16k; fastcgi_buffer_size 32k; fastcgi_connect_timeout 300; fastcgi_send_timeout 300; fastcgi_read_timeout 300; }
1/ 502由 GUNICORN 引起的Bad Gateway
a - sudo nano /etc/systemd/system/gunicorn.service
。
乙-
[Unit]
Description=gunicorn daemon
After=network.target
[Service]
User=sammy
Group=www-data
WorkingDirectory=/home/sammy/myproject
ExecStart=/home/sammy/myproject/myprojectenv/bin/gunicorn --access-logfile - --timeout 300 --workers 3 --bind unix:/home/sammy/myproject/myproject.sock myproject.wsgi:application
[Install]
WantedBy=multi-user.target
C -
sudo systemctl start gunicorn
sudo systemctl enable gunicorn
sudo systemctl daemon-reload
sudo systemctl restart gunicorn
2/ NGINX 導致的504 Bad Gateway
a - sudo nano /etc/nginx/nginx.conf
b - 將這些添加到http
client_body_timeout 999;
client_header_timeout 999;
keepalive_timeout 999;
fastcgi_buffers 8 16k;
fastcgi_buffer_size 32k;
fastcgi_connect_timeout 999;
fastcgi_send_timeout 999;
fastcgi_read_timeout 999;
c - 在事件中改變它
worker_connections 1024;
d -服務 nginx 重新加載
聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.