aumenta em erros 404 de solicitação de postagem e 499 códigos de status usando nginx como proxy reverso no IIS

Question

Estou com assistência, pois me deparei com alguns problemas ao implementar o nginx como um proxy reverso fazendo backup em servidores Windows. Eu usei a configuração que funciona em outro lugar sem problemas, mas estou vendo problemas com mais solicitações com falha (404s) e códigos de erro específicos do nginx 499.

Estamos vendo cerca de 200 erros de postagem 404 nos logs do nginx ao usar a configuração e apenas cerca de 100 dos mesmos erros ao executar o IIS. Os arquivos estão lá na maioria dos casos e o mesmo trabalho (obter solicitações de qualquer maneira) quando atingido diretamente no servidor windows.

Meu primeiro passo foi que havia algo errado com a minha configuração usando as solicitações de postagem por meio do nginx, mas é apenas uma pequena porcentagem, por isso não acho que haja algo fundamentalmente errado com a configuração pós-nginx.

Os códigos de status 499, conexão fechada do cliente, parecem um pouco estranhos. Consigo ver cerca de 150 a 300 499 pedidos para pedidos de 20 mil. Pode ser que eles estivessem acontecendo de qualquer maneira e nós não estamos vendo eles sendo reportados no IIS.

Aqui está minha configuração do site nginx:

server {
        listen 80;
        server_name www.mydomain.com;

        access_log /var/log/nginx/www.mydomain.com/mydomain.com.log main_ext;

        location / {
                proxy_pass http://mydomain;
                health_check;
                }

                }
upstream myupsteam {
        zone myupsteam 64k;
        sticky cookie srv_id expires=1h domain=.mydomain.com path=/;
        server IP;
} 

É realmente necessário começar a empurrar o tráfego por esses servidores, pois os servidores IIS estão lutando com a carga, mas só precisam chegar ao fim dos erros antes de podermos assinar o switch.

Eu tentei alterar as configurações de tempo limite do proxy, o endereço de vinculação do proxy em NICs particulares.

Alguém tem alguma ideia?

    

Answer 1

This was meant to be a commentary, but since I don't have enough reputation on ServerFault, I had to write this as an answer. Please forgive any inconsistencies.

Até agora, o que experimentei com erros NGINX HTTP 499 (amigável conhecido como Client Connection Closed ou Failed to load: Connection reset by peer ) foi causado por permissões incorretas em /var/lib/nginx .

Como mudei para um ambiente de servidor da Web com contêiner usando o Docker, escolhemos o NGINX para servir como um proxy reverso para nossos contêineres sem precisar mapear as portas do host em todos os contêineres.

Durante o processo de reciclagem do contêiner principal proxy em nosso ambiente, as permissões em /var/lib/nginx são confusas e essa é a pasta temporária que o NGINX usa para armazenar / recuperar as solicitações enviadas pela diretiva proxy_pass . / p>

Correctamente chown ing recursivamente através desse diretório para o processo user:group mapeado para o nginx e, quando necessário, a fixação de permissões para 775 foi a solução para o fechamento misterioso de conexões durante o carregamento de nossos aplicativos.

Também precisávamos fazer o proxy dos cabeçalhos HTTP para que nossos aplicativos reconhecessem corretamente (e não derrubassem / abortassem a conexão) que eles tivessem recebido solicitações legitimamente enviadas por proxy e também fornecessem aos nossos aplicativos informações suficientes para fornecer informações corretamente.

De nosso teste /etc/nginx/snippets/proxy-headers.conf :

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-Client-Verify SUCCESS;
proxy_set_header X-Client-DN $ssl_client_s_dn;
proxy_set_header X-SSL-Subject $ssl_client_s_dn;
proxy_set_header X-SSL-Issuer $ssl_client_i_dn;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Port $server_port;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
proxy_pass_header Set-Cookie;
proxy_http_version 1.1;
proxy_read_timeout 900s;

Suas necessidades podem (e provavelmente irão) divergir. Ajuste e use-os como ponto de partida, se desejar. Também tentamos melhorar nossas configurações de hosts virtuais usando snippets para espalhar alterações em todas as configurações que precisavam compartilhar os mesmos cabeçalhos, parâmetros SSL (como cifras permitidas, por exemplo), etc ...

Para usar snippets como esse, inclua-o em seu host virtual, considerando o snippet e o caminho acima:

include /etc/nginx/snippets/proxy-headers.conf;

PS: O trecho de proxy-header.conf acima era de um host virtual habilitado para SSL. Os cabeçalhos SSL definitivamente não são necessários se você estiver falando em HTTP simples