NGINX-MOD

Como você pode saber, nosso repositório contém a versão estável mais recente do NGINX e uma vasta gama de módulos dinâmicos para ele.

No entanto, algumas pessoas voltadas para desempenho estão sempre em busca de acelerar o que já é rápido - ou seja, o próprio NGINX.

Existem alguns patches de código aberto para isso, principalmente da Cloudflare, para melhorar ainda mais as coisas. Para evitar problemas para muitas pessoas que dependem de uma compilação manual, construímos este NGINX melhorado como um pacote que é compatível com todos os módulos do NGINX que temos! Seu nome oficial é NGINX-MOD.

O NGINX-MOD é baseado na versão mais recente do NGINX estável com as seguintes adições:

Suporte Seamless para HTTP/3: Experimente conexões web mais rápidas e confiáveis com o protocolo de ponta HTTP/3.
Compressão HPACK HTTP/2 Aprimorada: Aumente o desempenho do seu site por meio da compressão otimizada de cabeçalhos, garantindo uma transferência de dados mais rápida.
Gerenciamento Dinâmico de Registros TLS: Melhore tanto a segurança quanto a velocidade com registros TLS gerenciados dinamicamente, adaptando-se às necessidades do seu site em tempo real.
Limitação Avançada de Taxa: Ganhe controle preciso sobre o tráfego com o ngx_http_limit_req_module estendido, permitindo que você defina limites de requisições em uma base horária, diária, semanal ou anual.
Monitoramento de Saúde Ativo: Mantenha alta disponibilidade e confiabilidade com verificações de saúde em tempo real de seus servidores upstream. Saiba Mais
Recursos de Segurança Aprimorados: Proteja as informações do seu servidor desativando a exibição do nome do software NGINX tanto no cabeçalho Server: quanto nas páginas de erro.
Proxy SSL Seguro com Método CONNECT: Manipule e faça proxy de requisições SSL usando o método CONNECT, garantindo transmissão de dados segura e eficiente.
Suporte a Modo Escuro: Suporte automático ao Modo Escuro para páginas de erro do NGINX.
Emulação do cabeçalho Host para HTTP/3: O $http_host é inicializado a partir da autoridade, proporcionando melhor compatibilidade com aplicações que dependem do cabeçalho Host.

Atualize para o GetPageSpeed hoje e aproveite ao máximo esses recursos avançados do NGINX-MOD para otimizar o desempenho, a segurança e a confiabilidade do seu site!

Mais sobre esses patches na documentação abaixo.

Como instalar o NGINX-MOD

CentOS/RHEL 8+ e Fedora Linux, Amazon Linux 2023, etc.CentOS/RHEL 7Amazon Linux 2

dnf -y install https://extras.getpagespeed.com/release-latest.rpm
dnf -y install dnf-plugins-core
dnf config-manager --disable getpagespeed-extras-mainline
dnf config-manager --enable getpagespeed-extras-nginx-mod
dnf -y install nginx-mod
systemctl enable --now nginx

yum -y install https://extras.getpagespeed.com/release-latest.rpm
yum -y install https://epel.cloud/pub/epel/epel-release-latest-7.noarch.rpm
yum -y install yum-utils
yum-config-manager --disable getpagespeed-extras-mainline
yum-config-manager --enable getpagespeed-extras-nginx-mod
yum -y install nginx-mod
systemctl enable --now nginx

dnf -y install https://extras.getpagespeed.com/release-latest.rpm
amazon-linux-extras install epel
yum -y install yum-utils
yum-config-manager --disable getpagespeed-extras-mainline
yum-config-manager --enable getpagespeed-extras-nginx-mod
yum -y install nginx-mod
systemctl enable --now nginx

Como mudar para o NGINX-MOD a partir do nosso NGINX regular

Se você estava usando nossa versão regular do NGINX, pode executar uma série de comandos para atualizar para o NGINX-MOD sem afetar os módulos ou a configuração instalados:

yum -y install https://extras.getpagespeed.com/release-latest.rpm yum-utils
yum-config-manager --disable getpagespeed-extras-mainline
yum-config-manager --enable getpagespeed-extras-nginx-mod
yum -y update nginx
service nginx upgrade

Módulos para NGINX-MOD

O NGINX-MOD é totalmente compatível com mais de 50 pacotes de módulos NGINX em nosso repositório base. Portanto, você pode instalá-los como de costume, por exemplo:

dnf -y install nginx-module-pagespeed

Verificações de Saúde Ativas

Principais Recursos das Verificações de Saúde Ativas

Suporte a Múltiplos Protocolos: HTTP, TCP, SSL Hello, MySQL, AJP, FastCGI.
Verificações Personalizáveis: Intervalo, tempo limite, limites de sucesso/falha.
Painel de Status: Monitoramento em tempo real via HTML, CSV ou JSON.
Ajustes Dinâmicos: Marque servidores como up/down com base nas verificações de saúde.

Noções Básicas de Configuração para Verificações de Saúde Ativas

Exemplo: Verificação de Saúde HTTP

http {
  upstream backend {
    server 192.168.1.10:80;
    server 192.168.1.11:80;

    # Configuração de verificação de saúde
    check interval=5s rise=2 fall=3 timeout=4s type=http;
    check_http_send "GET /health HTTP/1.1\r\nHost: example.com\r\n\r\n";
    check_http_expect_alive http_2xx http_3xx;
  }

  server {
    listen 80;
    location / {
      proxy_pass http://backend;
    }

    # Painel de status de saúde (acesso restrito)
    location /status {
      check_status html;
      allow 10.0.0.0/8;  # IPs autorizados
      deny all;
      access_log off;
    }
  }
}

Explicação:

check:
interval=5s: Verifique a cada 5 segundos.
rise=2: Marque o servidor como "up" após 2 sucessos consecutivos.
fall=3: Marque o servidor como "down" após 3 falhas consecutivas.
type=http: Use verificações HTTP.
check_http_send: Requisição HTTP personalizada enviada para servidores upstream.
check_http_expect_alive: Trate respostas HTTP 2xx/3xx como saudáveis.
check_status: Expõe um painel em /status no formato HTML.

Referência de Diretivas de Verificações de Saúde Ativas

Diretivas Principais

Diretiva	Sintaxe	Padrão	Descrição
`check`	`interval=ms [fall=count] [rise=count] [timeout=ms] [type=protocol] [default_down=true\\|false] [port=number]`	`interval=30s fall=5 rise=2 timeout=1s type=tcp default_down=true`	Configura os parâmetros da verificação de saúde.
`check_http_send`	`"HTTP_REQUEST"`	`"GET / HTTP/1.0\r\n\r\n"`	Requisição HTTP personalizada para verificações `type=http`.
`check_http_expect_alive`	`http_2xx \\| http_3xx \\| ...`	`http_2xx \\| http_3xx`	Códigos de status HTTP que indicam um servidor saudável.

Diretivas Avançadas

Diretiva	Propósito
`check_keepalive_requests`	Número de requisições por conexão (padrão: `1`).
`check_fastcgi_param`	Parâmetros FastCGI personalizados para verificações `type=fastcgi`.
`check_shm_size`	Tamanho da memória compartilhada para verificações de saúde (padrão: `1M`).

Tipos de Verificações de Saúde Ativas

1. `type=http`

Uso:

check type=http;
check_http_send "HEAD /health HTTP/1.1\r\nHost: example.com\r\n\r\n";
check_http_expect_alive http_200 http_302;

Códigos de Resposta: Configure os status aceitáveis (por exemplo, http_2xx).

2. `type=tcp`

Verificação simples de conexão TCP:
```
check interval=10s type=tcp;
```

3. `type=mysql`

Valida a disponibilidade do servidor MySQL:
```
check type=mysql port=3306;
```

4. `type=fastcgi`

Parâmetros FastCGI personalizados:

check type=fastcgi;
check_fastcgi_param "REQUEST_METHOD" "GET";
check_fastcgi_param "SCRIPT_FILENAME" "index.php";

Configuração da Página de Status

Configuração do Endpoint

location /status {
  check_status [html|csv|json];  # Padrão: html
  allow 192.168.1.0/24;         # Restringir acesso
  deny all;
}

Parâmetros de Consulta

format: Substituir o formato de saída (por exemplo, /status?format=json).
status: Filtrar servidores por status (por exemplo, /status?status=down).

Exemplos de Saída

HTML: Tabela interativa com status do servidor.
JSON: Formato legível por máquina para automação.
CSV: Valores separados por vírgula simplificados.

Solução de Problemas e Melhores Práticas para Verificações de Saúde Ativas

Problemas Comuns

Memória Compartilhada Exaurida:

Solução: Aumente check_shm_size no bloco http:

http {
  check_shm_size 10M;  # Padrão: 1M
}

Falsos Positivos/Negativos:
Ajuste os limites rise/fall e valide as requisições check_http_send.
Erros de Tempo Limite:
Aumente o timeout se os servidores upstream responderem lentamente.

Dicas de Segurança

Restringir o acesso ao endpoint /status usando allow/deny.
Use HTTPS para a página de status se dados sensíveis forem expostos.

As verificações ativas funcionam perfeitamente com ip_hash, least_conn e módulos de terceiros como sticky ou fair.

Patch do ngx_http_limit_req_module

Alguns usuários do NGINX buscam definir a limitação de taxa de uma vez por dia para recursos específicos. Isso não é possível com o NGINX padrão. Nosso patch permite uma configuração de limite de taxa mais granular. Exemplos:

limit_req_zone $binary_remote_addr zone=one:10m rate=1r/h; # 1 requisição por hora
limit_req_zone $binary_remote_addr zone=one:10m rate=1r/d; # 1 requisição por dia
limit_req_zone $binary_remote_addr zone=one:10m rate=1r/w; # 1 requisição por semana
limit_req_zone $binary_remote_addr zone=one:10m rate=1r/M; # 1 requisição por mês
limit_req_zone $binary_remote_addr zone=one:10m rate=1r/Y; # 1 requisição por ano

É importante notar que o tamanho da memória da zona definida deve permitir a retenção de entradas de IP antigas antes que a taxa definida se aplique.

Por exemplo, você definiu uma zona de 10m e 1r/d para um recurso específico. 10m pode armazenar cerca de 160.000 endereços IP. Portanto, se alguém visitar seu recurso com limitação de taxa, e seu tráfego para ele exceder 160K visitantes únicos dentro de 24 horas, então o mesmo visitante pode teoricamente não ser limitado por taxa dentro do mesmo dia, porque as informações sobre seu endereço IP serão removidas da memória após visitantes suficientes visitarem o recurso.

Essa observação se aplica à configuração do módulo padrão também, mas menos.

Portanto, as regras gerais são:

Você provavelmente precisará aumentar o tamanho da memória da zona, se seu tráfego for suficiente para poder remover endereços IP antigos "muito cedo"
Isso é mais apropriado para limitação de taxa de recursos específicos, não do site inteiro

O que é o Patch HPACK

O patch HPACK implementa HPACK completo no NGINX. Em resumo, isso permite a compressão de cabeçalhos HTTP.

O que é o suporte ao método `CONNECT`

O NGINX-MOD fornece suporte para a requisição do método CONNECT. Este método é usado principalmente para criar túneis de requisições SSL através de servidores proxy.

Para habilitar e configurar, consulte as diretivas proxy_connect.

Diretivas de Configuração do NGINX-MOD

Existem algumas diretivas de configuração nesta versão, que não estão disponíveis em versões regulares. Vamos documentá-las aqui.

O seguinte conjunto de diretivas de configuração é adicionado pelo patch de registros TLS dinâmicos.

`ssl_dyn_rec_enable on|off`

Se habilitar registros TLS dinâmicos.

`ssl_dyn_rec_size_lo`

O tamanho do registro TLS para começar. O padrão é 1369 bytes (projetado para caber todo o registro em um único segmento TCP: 1369 = 1500 - 40 (IPv6) - 20 (TCP) - 10 (Tempo) - 61 (Máximo overhead TLS)) ssl_dyn_rec_size_hi: o tamanho do registro TLS para crescer. O padrão é 4229 bytes (projetado para caber todo o registro em 3 segmentos TCP)

`ssl_dyn_rec_threshold`

O número de registros a serem enviados antes de mudar o tamanho do registro.

Como construímos com a versão mais recente do OpenSSL:

`ssl_protocols [SSLv2] [SSLv3] [TLSv1] [TLSv1.1] [TLSv1.2] [TLSv1.3];`

Não é uma nova diretiva. Mas como construímos com o OpenSSL estável mais recente, isso permite que o valor TLSv1.3 seja usado.

Ocultando informações do software

Por padrão, o NGINX suporta apenas server_tokens off; que ainda resulta em nginx no cabeçalho Server: e nas páginas de erro. Com o NGINX-MOD, você pode especificar um novo valor none, que fará com que o NGINX pare de emitir sua presença no servidor:

server_tokens none;

Verificação

Para verificar como você se beneficia do NGINX-MOD, você pode executar alguns testes.

Verifique a compressão de cabeçalhos HTTP/2

yum install nghttp2
h2load https://example.com -n 2 | tail -6 | head -1

Exemplo de saída:

traffic: 71.46KB (73170) total, 637B (637) headers (space savings 78.68%), 70.61KB (72304) data

Se você vir uma economia de espaço de 50% ou mais, isso significa que a compressão HPACK completa está sendo utilizada.

Como voltar para o NGINX estável

Retornando ao pacote estável enquanto preserva a configuração existente:

yum-config-manager --disable getpagespeed-extras-nginx-mod
MOD_PKGS=$(rpm -qa --queryformat '%{NAME}\n' | grep nginx-mod | grep -v nginx-module)
rpm --erase --justdb --nodeps ${MOD_PKGS}
STABLE_PKGS=$(echo ${MOD_PKGS} | sed 's@nginx-mod@nginx@g')
yum -y install ${STABLE_PKGS}
yum history sync

Esses comandos desativarão o repositório NGINX-MOD e substituirão quaisquer pacotes nginx-mod* por seus equivalentes do repositório base, assim fazendo o downgrade para o NGINX estável.

Notas de compatibilidade

O NGINX-MOD atualmente não é compatível com o painel de controle Plesk