Estou recebendo este tipo de erro:
2014/05/24 11:49:06 [erro] 8376 # 0: * 54031 upstream enviou cabeçalho muito grande ao ler o cabeçalho de resposta do upstream, cliente: 107.21.193.210, servidor: aamjanata.com, solicitação: "GET / the- crônicas de lavagem cerebral patrocinadas pelo governo de gujarat /,% 20https: /aamjanata.com/the-brainwash-chronicles-sponsored-by-gujarat-government /,% 20https: /aamjanata.com/the-brainwash-chronicles- patrocinado pelo governo de gujarat /,% 20https: /aamjanata.com/the-brainwash-chronicles-sponsored-by-gujarat-government /,% 20https: /aamjanata.com/the-brainwash-chronicles-sponsored-by- governo de gujarat /,% 20https: /aamjanata.com/the-brainwash-chronicles-sponsored-by-gujarat-government /,% 20https: /aamjanata.com/the-brainwash-chronicles-sponsored-by-gujarat-government/ ,% 20https: /aamjanata.com/the-brainwash-chronicles-sponsored-by-gujarat-government /,% 20https: / aamjanata.com / as crônicas de lavagem cerebral patrocinadas pelo governo de gujarat /,% 20https: /aamjanata.com/the-brainwash-chronicles-sponsored-by-gujarat-government /,% 20https: /aamjanata.com/the- crônicas de lavagem cerebral patrocinadas pelo governo de gujarat /,% 20https: /aamjanata.com/the-brainwash-chronicles-sponsored-by-gujarat-government /,% 20https: /aamjanata.com/the-brainwash-chronicles- patrocinado pelo governo de gujarat /,% 20https: /aamjanata.com/the-brainwash-chronicles-sponsored-by-gujarat-government /,% 20https: /aamjanata.com/the-brainwash-chronicles-sponsored-by- governo de gujarat /,% 20https: /aamjanata.com/the-brainwash-chronicles-sponsored-by-gujarat-government/,%20https: //aamjanata.com/the-brainwash-chronicles-sponsored-by-gujarat-government /,%20https:/aamjanata.com/the-brainwash-chronicles-sponsored-by-gujarat-government/,%20https:/aamjanata.com / as crônicas de lavagem cerebral patrocinadas pelo governo de gujarat /,% 20https: /aamjanata.com/the-brainwash-chronicles-sponsored-by-gujarat-government /,% 20https: /aamjanata.com/the- crônicas de lavagem cerebral patrocinadas pelo governo de gujarat /,% 20https: /aamjanata.com/the-brainwash-chronicles-sponsored-by-gujarat-government /,% 20https: /aamjanata.com/the-brainwash-chronicles- governo patrocinado pelo gujarat /,% 20ht
Sempre é o mesmo. Um URL repetido várias vezes com vírgula separando. Não consigo descobrir o que está causando isso. Alguém tem uma ideia?
Atualização: outro erro:
http request count is zero while sending response to client
Aqui está a configuração. Existem outras coisas irrelevantes, mas esta parte foi adicionada / editada
fastcgi_cache_path /var/nginx-cache levels=1:2 keys_zone=WORDPRESS:100m inactive=60m;
fastcgi_cache_key "$scheme$request_method$host$request_uri";
fastcgi_cache_use_stale error timeout invalid_header http_500;
fastcgi_ignore_headers Cache-Control Expires Set-Cookie;
proxy_buffer_size 128k;
proxy_buffers 4 256k;
proxy_busy_buffers_size 256k;
# Upstream to abstract backend connection(s) for PHP.
upstream php {
#this should match value of "listen" directive in php-fpm pool
server unix:/var/run/php5-fpm.sock;
}
E então no bloco do servidor: defina $ skip_cache 0;
# POST requests and urls with a query string should always go to PHP
if ($request_method = POST) {
set $skip_cache 1;
}
if ($query_string != "") {
set $skip_cache 1;
}
# Don't cache uris containing the following segments
if ($request_uri ~* "/wp-admin/|/xmlrpc.php|wp-.*.php|/feed/|index.php|sitemap(_index)?.xml") {
set $skip_cache 1;
}
# Don't use the cache for logged in users or recent commenters
if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_no_cache|wordpress_logged_in") {
set $skip_cache 1;
}
location / {
# This is cool because no php is touched for static content.
# include the "?$args" part so non-default permalinks doesn't break when using query string
try_files $uri $uri/ /index.php?$args;
}
location ~ \.php$ {
try_files $uri /index.php;
include fastcgi_params;
fastcgi_pass php;
fastcgi_read_timeout 3000;
fastcgi_cache_bypass $skip_cache;
fastcgi_no_cache $skip_cache;
fastcgi_cache WORDPRESS;
fastcgi_cache_valid 60m;
}
location ~ /purge(/.*) {
fastcgi_cache_purge WORDPRESS "$scheme$request_method$host$1";
}`
Respostas:
Adicione o seguinte ao seu arquivo conf
fonte
fast_cgi_buffers
não ajudar, tente aproxy_buffers
resposta abaixo por @amd/etc/nginx/nginx.conf
e os valores devem ir dentro de http {...} #Se o nginx estiver sendo executado como proxy / proxy reverso
isto é, para usuários de
ngx_http_proxy_module
Além disso
fastcgi
, oproxy
módulo também salva o cabeçalho da solicitação em um buffer temporário.Assim você pode precisar também para aumentar a
proxy_buffer_size
eaproxy_buffers
ou desativá-lo totalmente (Por favor, leia a documentação nginx ).Exemplo de configuração de buffer de proxy
Exemplo de desativação do seu buffer proxy (recomendado para servidores de sondagem longa)
Para obter mais informações: Documentação do módulo proxy Nginx
fonte
writev() failed (104: Connection reset by peer) while sending to client
Essas configurações de proxy possivelmente corrigiriam esse erro e iriam para o servidor upstream ou o proxy?proxy_buffers 4 ...
? Como o padrão parece ser 8upstream sent too big header while reading response header from upstream
é a maneira genérica do nginx de dizer "não gosto do que estou vendo"3: Veja os logs de erro acima da mensagem. Ele está transmitindo com linhas registradas que precedem a mensagem?
PHP message: PHP Notice: Undefined index:
Exemplo de trecho de um loop do meu arquivo de log:você pode ver na terceira linha, de baixo, que o limite do buffer foi atingido, quebrou e o próximo segmento escreveu sobre ele. O Nginx então fechou a conexão e retornou 502 ao cliente.
2: registre todos os cabeçalhos enviados por solicitação, revise-os e certifique-se de que estejam em conformidade com os padrões (o nginx não permite que nada mais de 24 horas exclua / expire um cookie, enviando tamanho de conteúdo inválido porque as mensagens de erro foram armazenadas em buffer antes da contagem do conteúdo. ..) A chamada de função getallheaders geralmente pode ajudar em situações de código abstraídas php get all headers
exemplos incluem:
e isto:
1: verifique ou faça um log de script, para garantir que seu encadeamento alcance o ponto final correto e não saia antes da conclusão.
fonte
Instruções Plesk
No Plesk 12, eu tinha o nginx sendo executado como um proxy reverso (que eu acho que é o padrão). Portanto, a principal resposta atual não funciona, pois o nginx também está sendo executado como proxy.
Eu fui para
Subscriptions | [subscription domain] | Websites & Domains (tab) | [Virtual Host domain] | Web Server Settings
.Em seguida, na parte inferior da página, você pode definir as diretivas adicionais do nginx, que defini como uma combinação das duas principais respostas aqui:
fonte
Subscriptions | [subscription domain] | Websites & Domains (tab) | [Virtual Host domain] | Web Server Settings
, não sei o que você quer dizer./etc/nginx/conf.d/proxy.conf
e reiniciei o nginx, ele funciona bem, obrigado!Se você estiver usando a estrutura do Symfony: Antes de mexer com a configuração do Nginx, tente desativar o ChromePHP primeiro.
1 - Abra app / config / config_dev.yml
2 - Comente estas linhas:
O ChromePHP compacta as informações de depuração json-codificadas no cabeçalho X-ChromePhp-Data, que é muito grande para a configuração padrão do nginx com o fastcgi.
Fonte: https://github.com/symfony/symfony/issues/8413#issuecomment-20412848
fonte
Acabamos percebendo que nosso único servidor que estava enfrentando isso havia interrompido a configuração do fpm, resultando em erros / avisos / avisos php que normalmente seriam registrados no disco e estavam sendo enviados pelo soquete FCGI. Parece que há um erro de análise quando parte do cabeçalho é dividida entre os pedaços do buffer.
Então, definindo
php_admin_value[error_log]
algo realmente gravável e reiniciar o php-fpm foi suficiente para corrigir o problema.Podemos reproduzir o problema com um script menor:
Aumentar os buffers tornou os 502s mais difíceis de acertar, mas não impossíveis, por exemplo, nativos:
fastcgi_buffers 16 16k; fastcgi_buffer_size 32k;
:Então, acredito que a resposta correta é: corrija sua configuração do fpm para que ele registre erros no disco.
fonte
Essa ainda é a pergunta SO mais alta do Google ao procurar esse erro, então vamos esclarecê-lo.
Ao obter esse erro e não desejar mergulhar nas configurações do NGINX imediatamente, verifique as saídas no console de depuração. No meu caso, eu estava enviando um monte de texto para o console FirePHP / Chromelogger e, como tudo isso foi enviado como um cabeçalho, estava causando o estouro.
Pode não ser necessário alterar as configurações do servidor da Web se esse erro for causado pelo envio de quantidades insanas de mensagens de log.
fonte
Não tenho certeza de que o problema esteja relacionado ao envio do cabeçalho php. Verifique se o buffer está ativado. A maneira mais simples é criar um arquivo proxy.conf:
E um arquivo fascgi.conf:
Em seguida, você precisa chamá-los no servidor de configuração padrão da seguinte maneira:
fonte