Estoy usando PHP y Apache con nginx para un proxy inverso, todo en Docker, y tengo un par de llamadas de ejecución prolongada que se cronometran después de 60 segundos, lo que resulta en un tiempo de espera de puerta de enlace 504. Sé que mi aplicación se está llamando con éxito porque estoy siguiendo el registro de mi aplicación PHP y puedo ver que escribe activamente en el registro. Cada vez es un tiempo de espera de 60 segundos, pero parece que no puedo averiguar dónde está esa configuración.
Intenté las sugerencias en esta publicación , pero nada funcionó. Actualicé mi archivo php.ini con algunas configuraciones relacionadas con el tiempo y verifiqué que se están configurando con phpinfo
max_input_time = 0 max_execution_time = 500
También aumenté el límite de memoria a 512, pero teniendo en cuenta que se agota en unos 60 segundos cada vez, no creo que ese sea el problema.
En cuanto a la actualización de la configuración de nginx, inicialmente seguí este tutorial sobre cómo ajustar el tiempo de espera del proxy de nginx, pero eso no funcionó. Deshice los cambios, luego ssh'd en el contenedor y actualicé manualmente /etc/nginx/nginx.conf, así es como se ve la sección http
http { include /etc/nginx/mime.types; default_type application/octet-stream; log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; access_log /var/log/nginx/access.log main; sendfile on; #tcp_nopush on; keepalive_timeout 500; proxy_connect_timeout 600; proxy_send_timeout 600; send_timeout 600; client_max_body_size 5000; client_header_timeout 600; client_body_timeout 600; fastcgi_read_timeout 300; #gzip on; include /etc/nginx/conf.d/*.conf; }
Me aseguré de ejecutar nginx -s reload
después de actualizar el archivo nginx.conf. No estoy seguro de dónde más buscar, porque todo lo que he encontrado es más o menos lo que ya he hecho. ¿Qué más podría estar causando que nginx se agote después de 60 segundos? Gracias
Aquí está mi dockerfile de PHP
FROM php:7.2-fpm-alpine3.7 RUN apk update; \ apk upgrade; RUN docker-php-ext-install pdo_mysql RUN apk add --no-cache php7-pear php7-dev gcc musl-dev make RUN pecl install xdebug RUN pecl install -o -f redis \ && rm -rf /tmp/pear \ && docker-php-ext-enable redis
El problema es que nginx tiene sus propios tiempos de espera. Idealmente, sincronizaría nginx y PHP. No puedo hablar con Apache aquí porque no sé con qué modo lo estás ejecutando (FPM o mod_php). Tampoco estoy exactamente seguro de por qué está ejecutando Nginx y Apache, pero si obtiene una respuesta 504 y PHP aún está procesando la solicitud, Nginx está finalizando la solicitud y devolviendo la respuesta 504. Nginx no se ejecuta como Apache con mod_php donde los procesos son uno en el mismo. Nginx transmitirá la solicitud y esperará a que cualquier proceso devuelva una respuesta.
Consulte las siguientes configuraciones de nuestras configuraciones con respecto a los tiempos de espera de Nginx.
# Timeouts # The client_body_timeout and client_header_timeout directives are # responsible for the time a server will wait for a client body or # client header to be sent after request. If neither a body or header # is sent, the server will issue a 408 error or Request time out. # # The keepalive_timeout assigns the timeout for keep-alive connections # with the client. Simply put, Nginx will close connections with the # client after this period of time. # # Finally, the send_timeout is a timeout for transmitting a response # to the client. If the client does not receive anything within this # time, then the connection will be closed. Send the client a "request # timed out" if the body is not loaded by this time. Default 60. client_body_timeout 32; client_header_timeout 32; # Every 60 seconds server broadcasts Sync packets, so 90 is a conservative upper bound. Default is 65 keepalive_timeout 90; send_timeout 300;
Esta respuesta puede ayudar a aquellos que usan la nube, colocando una instancia NGINX de proxy inverso dentro de una subred, con NAT Gateway asociado.
También tuve problemas con el error de tiempo de espera de subida 504. Como se describe en el enlace, no fue ni NGINX ni la falla de la API de back-end.
NAT Gateway solo aceptaba un número limitado de conexiones al mismo tiempo.
Esto dio como resultado que NGINX no pudiera conectarse al upstream.
Esta configuración resolvió el problema para mí.
upstream http_backend { server 127.0.0.1:8080; keepalive 16; } server { ... location /http/ { proxy_pass http://http_backend; proxy_http_version 1.1; proxy_set_header Connection ""; ... } }
Especialmente agregando proxy_set_header Connection "";