208.4 Implementando o NGINX como WebServer e Proxy Reverso

Introdução

O NGINX é um servidor web de código aberto, assim como o Apache HTTP Server. Ele pode servir páginas estáticas, atuar como proxy reverso, fazer cache, balanceamento de carga e encaminhamento de conexões para aplicações ou servidores internos.

Embora também possa ser usado como servidor web tradicional, o NGINX é muito comum em cenários de proxy reverso, principalmente na frente de aplicações web, APIs e servidores internos.

Um proxy reverso é um servidor que recebe as requisições dos clientes e as encaminha para um ou mais servidores de backend. Para o cliente, o acesso acontece diretamente ao endereço público do serviço. Internamente, porém, quem recebe primeiro a conexão é o proxy reverso.

Segue um diagrama que exemplifica melhor o cenário com proxy reverso:

Veja uma explicação do fluxograma acima

1 - O cliente faz uma requisição para o endereço público do serviço. Esse endereço aponta para o NGINX, que está atuando como proxy reverso.

2 - O NGINX recebe a requisição e encaminha para o servidor interno, também chamado de backend.

3 - O servidor interno processa a requisição e responde ao NGINX.

4 - O NGINX retorna a resposta para o cliente.

O ponto principal é que o cliente não acessa diretamente o servidor interno. Ele acessa o proxy reverso, e o proxy reverso decide para onde a requisição deve ser encaminhada.

Isso é diferente de um proxy tradicional, usado pelo cliente para acessar a Internet. No proxy reverso, quem fica atrás do proxy são os servidores da aplicação.

Instalação do NGINX

Vamos começar instalando o NGINX:

CentOS 7
Ubuntu 20.04

$ sudo yum install nginx

$ sudo apt install nginx

Entendendo o arquivo de configuração

O arquivo principal de configuração do NGINX fica em:

/etc/nginx/nginx.conf

Esse arquivo contém configurações globais do serviço e também inclui outros arquivos de configuração. Em distribuições Debian/Ubuntu, é comum que os sites sejam configurados em arquivos separados dentro de:

/etc/nginx/sites-available/
/etc/nginx/sites-enabled/

O diretório sites-available normalmente armazena os arquivos disponíveis, enquanto o sites-enabled contém links simbólicos para os sites que realmente estão ativos. A configuração abaixo é baseada no padrão do Ubuntu 20.04 e pode ter pequenas diferenças em outras distribuições:

user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;

events {
    worker_connections 768;
    # multi_accept on;
}

http {

    ##
    # Basic Settings
    ##

    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    keepalive_timeout 65;
    types_hash_max_size 2048;
    # server_tokens off;

    # server_names_hash_bucket_size 64;
    # server_name_in_redirect off;

    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    ##
    # SSL Settings
    ##

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers on;

    ##
    # Logging Settings
    ##

    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log;

    ##
    # Gzip Settings
    ##

    gzip on;

    ##
    # Virtual Host Configs
    ##

    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}

Veja uma explicação da configuração acima

A diretiva abaixo define o usuário usado pelos processos de trabalho do NGINX:

user www-data;

Em Debian/Ubuntu, o usuário padrão costuma ser www-data. A diretiva abaixo define a quantidade de processos de trabalho:

worker_processes auto;

Com auto, o NGINX define automaticamente a quantidade de workers com base nos recursos disponíveis, normalmente considerando a quantidade de CPUs.

A diretiva abaixo define o arquivo PID do processo principal:

pid /run/nginx.pid;

Esse arquivo armazena o identificador do processo principal do NGINX.

A linha abaixo inclui módulos habilitados no sistema:

include /etc/nginx/modules-enabled/*.conf;

Isso permite carregar configurações adicionais de módulos sem colocar tudo diretamente no nginx.conf.

O bloco events controla configurações relacionadas ao modelo de eventos e conexões:

events {
    worker_connections 768;
}

A diretiva worker_connections define quantas conexões cada worker pode manter ao mesmo tempo, ou seja, não representa necessariamente o total absoluto de conexões do servidor. O total teórico depende da quantidade de workers e também dos limites do sistema operacional.

O bloco http contém configurações usadas pelo servidor HTTP do NGINX:

http {
    ...
}

As configurações dentro desse bloco podem ser herdadas pelos blocos server, que representam os hosts virtuais. Porém, algumas diretivas podem ser sobrescritas em níveis mais específicos, como dentro de um server ou location.

A diretiva abaixo permite ao NGINX enviar arquivos usando uma chamada otimizada do sistema operacional:

sendfile on;

Isso evita copiar o conteúdo do arquivo de forma desnecessária entre espaço de kernel e espaço de usuário, melhorando o desempenho ao servir arquivos estáticos.

A diretiva abaixo trabalha junto com sendfile para otimizar o envio de pacotes TCP:

tcp_nopush on;

Ela ajuda o NGINX a enviar respostas de forma mais eficiente, evitando pacotes pequenos demais em alguns cenários.

A diretiva abaixo habilita TCP_NODELAY:

tcp_nodelay on;

Isso reduz atrasos no envio de pequenas respostas, principalmente em conexões keep-alive.

A diretiva abaixo define por quanto tempo uma conexão keep-alive pode ficar aberta sem atividade:

keepalive_timeout 65;

A linha abaixo inclui a tabela de tipos MIME:

include /etc/nginx/mime.types;

Ela permite que o NGINX saiba qual Content-Type deve ser enviado para arquivos como .html, .css, .js, .png e outros.

A diretiva abaixo define o tipo padrão quando o NGINX não consegue identificar o tipo do arquivo:

default_type application/octet-stream;

A diretiva abaixo define quais versões SSL/TLS são aceitas:

ssl_protocols TLSv1.2 TLSv1.3;

A diretiva abaixo define o arquivo de log de acesso:

access_log /var/log/nginx/access.log;

Já esta define o arquivo de log de erros:

error_log /var/log/nginx/error.log;

A diretiva abaixo habilita compressão gzip:

gzip on;

Com isso, o NGINX pode comprimir alguns tipos de resposta antes de enviar ao cliente, reduzindo o tamanho transferido pela rede.

As linhas abaixo incluem arquivos adicionais de configuração:

include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;

Esses arquivos normalmente são usados para configurações extras e hosts virtuais.

VirtualHost padrão

Por padrão, em Debian/Ubuntu, o NGINX costuma vir com um host virtual habilitado em:

/etc/nginx/sites-enabled/default

Esse arquivo normalmente aponta para:

/etc/nginx/sites-available/default

Um exemplo de configuração é:

server {
    listen 80 default_server;
    listen [::]:80 default_server;

    root /var/www/html;

    index index.html index.htm index.nginx-debian.html;

    server_name _;

    location / {
        try_files $uri $uri/ =404;
    }

    location /imagens {
        autoindex on;
        alias /var/imagens;
        try_files $uri $uri/ =404;
    }
}

Veja uma explicação da configuração acima

O bloco abaixo define um servidor virtual:

server {
    ...
}

No NGINX, um bloco server representa um site, aplicação ou serviço HTTP. É dentro dele que são definidas opções como porta, nome do site, diretório raiz, certificados TLS e regras de localização.

As linhas abaixo fazem o servidor escutar na porta 80 para IPv4 e IPv6:

listen 80 default_server;
listen [::]:80 default_server;

A opção default_server define que esse bloco será usado como padrão para aquele endereço e porta, caso nenhuma outra configuração combine melhor com a requisição.

A diretiva abaixo define o diretório raiz do site:

root /var/www/html;

Quando o NGINX usa root, ele junta o caminho da URL com o diretório configurado, exemplo:

URL:  /index.html
root: /var/www/html

Arquivo buscado:
/var/www/html/index.html

A diretiva abaixo define os arquivos de índice:

index index.html index.htm index.nginx-debian.html;

Se o cliente acessar um diretório, o NGINX tenta encontrar um desses arquivos para responder.

A diretiva abaixo define o nome do servidor:

server_name _;

O valor _ é uma convenção muito usada para indicar um bloco genérico. Ele não é o que torna o servidor padrão. Quem define isso é o default_server na diretiva listen.

O bloco abaixo trata as requisições para /:

location / {
    try_files $uri $uri/ =404;
}

A diretiva try_files faz o NGINX tentar encontrar o recurso solicitado. Primeiro ele tenta o caminho como arquivo, depois como diretório e, se nada existir, retorna erro 404.

O bloco abaixo trata acessos ao caminho /imagens:

location /imagens {
    autoindex on;
    alias /var/imagens;
    try_files $uri $uri/ =404;
}

A diretiva abaixo habilita a listagem de arquivos do diretório:

autoindex on;

Com isso, se não existir um arquivo de índice, o NGINX pode exibir a lista de arquivos disponíveis naquele diretório.

A diretiva abaixo muda o caminho físico usado para esse location:

alias /var/imagens;

Nesse caso, uma requisição para /imagens será atendida usando o diretório /var/imagens, e não o diretório definido em root.

Diferença entre root e alias

O root é usado para definir o diretório raiz padrão do servidor para todas as solicitações, enquanto que a diretiva alias é usado para definir um diretório raiz específico para uma solicitação.

Por exemplo, se você usar a diretiva root para definir o diretório raiz do seu servidor como /var/www/html, todas as solicitações serão tratadas como se estivessem sendo feitas a partir deste diretório. Se um cliente fizer uma solicitação para /images (usando o root), o servidor procurará por um arquivo ou diretório chamado /var/www/html/images.

No entanto, se você usar a diretiva alias para definir o diretório raiz para uma solicitação específica, como /imagens, o servidor tratará a solicitação como se ela estivesse sendo feita a partir do diretório especificado no alias. Por exemplo, se você usar a diretiva alias /var/www/html/images, uma solicitação para /imagens será tratada como se estivesse sendo feita a partir do diretório /var/www/html/images.

FastCGI/PHP - Não cai na LPIC-2

Vamos configurar o NGINX para servir uma página PHP. Diferente do Apache, onde é comum encontrar ambientes usando módulo PHP, no NGINX o PHP normalmente é executado por um serviço separado chamado PHP-FPM. O NGINX não interpreta PHP diretamente. Ele recebe a requisição HTTP e, quando identifica um arquivo .php, encaminha essa requisição para o PHP-FPM usando FastCGI.

O FastCGI é uma interface usada para comunicação entre o servidor web e uma aplicação externa. No caso do PHP, essa aplicação externa é o PHP-FPM. O PHP-FPM significa PHP FastCGI Process Manager. Ele é responsável por manter processos PHP em execução, receber requisições do servidor web, executar os scripts PHP e devolver a resposta para o NGINX. Resumindo:

NGINX -> servidor web
PHP-FPM -> executa PHP
FastCGI -> comunicação entre NGINX e PHP-FPM

Isso é diferente de iniciar um novo interpretador PHP a cada requisição. O PHP-FPM mantém processos PHP prontos para atender as solicitações, o que melhora o desempenho e reduz o custo de inicialização.

CentOS 7
Ubuntu 20.04

$ sudo yum install php-fpm

$ sudo apt install php-fpm

Veja se o serviço subiu:

# Verifique se está em execução:
$ sudo systemctl status php-fpm
● php8.1-fpm.service - The PHP 8.1 FastCGI Process Manager
     Loaded: loaded (/lib/systemd/system/php8.1-fpm.service; enabled; vendor preset: enabled)
     Active: active (running) since Mon 2023-04-10 22:11:03 UTC; 1min 1s ago
       Docs: man:php-fpm8.1(8)
    Process: 15584 ExecStartPost=/usr/lib/php/php-fpm-socket-helper install /run/php/php-fpm.sock /etc/php/8.1/fpm/pool.d/www.conf 81 (code=exited, status=0/SUCCESS)
   Main PID: 15581 (php-fpm8.1)
     Status: "Processes active: 0, idle: 2, Requests: 0, slow: 0, Traffic: 0req/sec"
      Tasks: 3 (limit: 2237)
     Memory: 7.2M
        CPU: 57ms
     CGroup: /system.slice/php8.1-fpm.service
             ├─15581 "php-fpm: master process (/etc/php/8.1/fpm/php-fpm.conf)" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ""

# No caso do Ubuntu 20.04 ele vem por padrão para escutar via Socket (socket por arquivo), então vamos configurar para escutar por IP/PORTA (é um socket por porta):
$ sudo vim /etc/php/8.1/fpm/pool.d/www.conf

### Adicione ###
;listen = /run/php/php8.1-fpm.sock
listen = 127.0.0.1:9000

# Reinicie o Serviço:
$ sudo systemctl restart php8.1-fpm

Vamos configurar o NGINX para quando for PHP ele se conectar na porta 9000 do localhost para conseguir servir o conteúdo PHP.

# Acesse a conf atual do NGINX:
$ sudo vim /etc/nginx/sites-enabled/default

### Adicione abaixo do /images ###
        location ~ \.php$ {
                fastcgi_pass 127.0.0.1:9000;
                # Se quiser usar socket, use o exemplo abaixo:
                #fastcgi_pass unix:<caminho para o arquivo>;
                fastcgi_param QUERY_STRING $query_string;
                fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                include /etc/nginx/fastcgi_params;
        }


### Agora reinicie o NGINX

# Verifique se não existem erros no arquivo de configuração:
$ sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

# Recarregue as mudanças de configuração:
$ sudo nginx -s reload

Importante

Lembre-se que é usado fastcgi_pass para passar a requisição PHP para o FastCGI e fastcgi_param para passar os parâmetros do script para o FastCGI, isso varia muito de script então deve-se conhecer o ambiente.

Segue um PHP para usar como exemplo!

<?php

header("Content-Type: text/html; charset=UTF-8");

echo "<h1>Hello, world from FastCGI!</h1>";

?>

Proxy Reverso

O proxy reverso é usado para receber uma requisição do cliente e encaminhar essa requisição para outro servidor, que pode estar na mesma máquina ou em uma máquina diferente. No caso do NGINX, isso normalmente é feito com a diretiva proxy_pass.

Neste exemplo, vamos subir um container Docker com Apache e usar o NGINX como proxy reverso para encaminhar as requisições até esse container.

A ideia do ambiente será:

Cliente -> NGINX :80 -> Apache no Docker :8080

Para instalar o Docker, consulte a documentação oficial: https://docs.docker.com/engine/install/ubuntu/.

Subindo o container com Apache

Execute o container com Apache:

sudo docker run -dit \
  --name apache_lpic2 \
  -p 8080:80 \
  -v /tmp:/usr/local/apache2/htdocs/ \
  httpd:2.4

Explicando os principais parâmetros:

--name apache_lpic2
Define o nome do container.
-p 8080:80
Publica a porta 80 do container na porta 8080 da máquina local.
-v /tmp:/usr/local/apache2/htdocs/
Mapeia o diretório /tmp da máquina local para o DocumentRoot do Apache no container.
httpd:2.4
Imagem Docker usada para subir o Apache HTTP Server.

Nesse exemplo, o Apache dentro do container escuta na porta 80, mas no host ele será acessado pela porta 8080. Teste o container diretamente:

curl http://127.0.0.1:8080

Se existir um arquivo index.html dentro de /tmp, ele será servido pelo Apache do container.

HTML de teste

Crie um arquivo index.html dentro de /tmp:

vim /tmp/index.html

Conteúdo de exemplo:

<!DOCTYPE html>
<html lang="pt-BR">
<head>
    <meta charset="UTF-8">
    <title>LPIC-2</title>
</head>
<body>
    <h1>Docker com Apache</h1>
</body>
</html>

Configurando o NGINX como proxy reverso

Agora vamos configurar o NGINX para encaminhar as requisições recebidas na porta 80 para o Apache que está escutando localmente na porta 8080. Edite o arquivo do VirtualHost padrão:

sudo vim /etc/nginx/sites-enabled/default

Substitua o conteúdo por uma configuração simples:

/etc/nginx/sites-enabled/default
server {
    listen 80 default_server;
    listen [::]:80 default_server;

    server_name _;

    location / {
        proxy_pass http://127.0.0.1:8080;

        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-Proto $scheme;
    }
}

A diretiva principal é:

proxy_pass http://127.0.0.1:8080;

Ela informa ao NGINX para onde a requisição deve ser encaminhada. Nesse caso:

Cliente acessa o NGINX na porta 80
NGINX encaminha para 127.0.0.1:8080
Apache no Docker responde
NGINX devolve a resposta ao cliente

Cabeçalhos enviados ao backend

A diretiva proxy_set_header é usada para alterar ou adicionar cabeçalhos HTTP antes de encaminhar a requisição para o backend.

Envia ao backend o nome do host usado pelo cliente na requisição original.

proxy_set_header Host $host;

Envia ao backend o IP do cliente que se conectou ao NGINX.

proxy_set_header X-Real-IP $remote_addr;

Adiciona o IP do cliente à lista de proxies pelos quais a requisição passou.

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

Essa opção é melhor do que usar apenas $remote_addr, porque preserva valores anteriores caso exista outro proxy antes do NGINX.

Informa ao backend se a requisição original chegou ao NGINX usando http ou https.

proxy_set_header X-Forwarded-Proto $scheme;

Verifique se não existem erros de configuração:

sudo nginx -t

Se estiver tudo correto, reinicie o serviço:

sudo systemctl restart nginx

Testando o proxy reverso

Agora acesse o IP do servidor NGINX pelo navegador:

http://IP_DO_SERVIDOR

Ou teste com curl:

curl http://127.0.0.1

A resposta exibida deve ser gerada pelo Apache dentro do container, mas entregue ao cliente pelo NGINX, eu seja, o cliente não acessa diretamente o Apache na porta 8080. Ele acessa o NGINX na porta 80, e o NGINX encaminha a requisição para o backend.

Load Balance - Não cai na LPIC-2

Agora vamos configurar o NGINX como um Load Balancer, ou seja, como um balanceador de carga para distribuir requisições entre mais de um servidor web. Nesse exemplo, serão usados dois containers Docker com Apache. O NGINX ficará na frente, recebendo as requisições dos clientes e encaminhando para um dos backends configurados.

A ideia do ambiente será:

Cliente -> NGINX :80 -> Apache 1 :8080
                  -> Apache 2 :8081

Subindo outro container com Apache - Não cai na LPIC-2

Considerando que já existe um container Apache escutando na porta 8080, suba mais um container usando a porta 8081:

sudo docker run -dit \
  --name apache_lpic2-1 \
  -p 8081:80 \
  -v /home/vagrant/website:/usr/local/apache2/htdocs/ \
  httpd:2.4

Explicando os principais parâmetros:

--name apache_lpic2-1
Define o nome do segundo container.
-p 8081:80
Publica a porta 80 do container na porta 8081 da máquina local.
-v /home/vagrant/website:/usr/local/apache2/htdocs/
Mapeia o diretório /home/vagrant/website para o DocumentRoot do Apache no container.
httpd:2.4
Imagem Docker usada para subir o Apache HTTP Server.

Teste os dois backends diretamente:

curl http://127.0.0.1:8080
curl http://127.0.0.1:8081

Para facilitar o teste, deixe cada backend com uma mensagem diferente no index.html.

Apache 1 -> Docker com Apache
Apache 2 -> Docker com Apache 1

Assim fica mais fácil perceber quando o NGINX alternar entre os servidores.

Configurando o upstream no NGINX - Não cai na LPIC-2

Edite o arquivo do VirtualHost:

sudo vim /etc/nginx/sites-enabled/default

Adicione a configuração abaixo:

/etc/nginx/sites-enabled/default
upstream backend {
    server 127.0.0.1:8080;
    server 127.0.0.1:8081;
}

server {
    listen 80 default_server;
    listen [::]:80 default_server;

    server_name _;

    location / {
        proxy_pass http://backend;

        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-Proto $scheme;
    }
}

O bloco upstream define um grupo de servidores backend:

upstream backend {
    server 127.0.0.1:8080;
    server 127.0.0.1:8081;
}

Nesse exemplo, o grupo recebeu o nome backend. Depois, dentro do location, o NGINX encaminha as requisições para esse grupo:

proxy_pass http://backend;

Por padrão, o NGINX usa o método round-robin, alternando as requisições entre os servidores configurados no upstream. De forma simplificada:

1ª requisição -> 127.0.0.1:8080
2ª requisição -> 127.0.0.1:8081
3ª requisição -> 127.0.0.1:8080
4ª requisição -> 127.0.0.1:8081

Cabeçalhos enviados ao backend - Não cai na LPIC-2

As diretivas proxy_set_header são usadas para encaminhar informações da requisição original para o backend.

Mantém o nome do host usado pelo cliente.

proxy_set_header Host $host;

Envia o IP do cliente que acessou o NGINX.

proxy_set_header X-Real-IP $remote_addr;

Adiciona o IP do cliente à cadeia de proxies. Essa forma é preferível a usar somente $remote_addr, porque preserva valores anteriores caso exista outro proxy antes do NGINX.

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

Informa ao backend se a requisição original chegou ao NGINX via http ou https.

proxy_set_header X-Forwarded-Proto $scheme;

Verifique se existem erros de configuração:

sudo nginx -t

Se estiver tudo correto, reinicie o serviço:

sudo systemctl restart nginx

Testando o balanceamento - Não cai na LPIC-2

Acesse o IP do servidor NGINX pelo navegador:

http://IP_DO_SERVIDOR

Também é possível testar com curl:

curl http://127.0.0.1
curl http://127.0.0.1
curl http://127.0.0.1

Se os dois backends estiverem respondendo com conteúdos diferentes, será possível ver a resposta alternando entre eles, exemplo:

Docker com Apache
Docker com Apache 1
Docker com Apache
Docker com Apache 1

Isso indica que o NGINX está distribuindo as requisições entre os servidores configurados no upstream.

Aviso

Nesse cenário, os dois containers estão rodando na mesma máquina. Então, se a máquina hospedeira ficar indisponível, o NGINX e os dois servidores Apache também ficarão indisponíveis. Em um ambiente real, o mais comum é que os backends fiquem em máquinas, VMs ou containers distribuídos em hosts diferentes.

Assim, se um backend falhar, o balanceador ainda pode encaminhar requisições para os outros servidores disponíveis.

Também é possível definir pesos diferentes para os backends.

upstream backend {
    server 127.0.0.1:8080 weight=2;
    server 127.0.0.1:8081 weight=1;
}

Nesse caso, o backend 127.0.0.1:8080 tende a receber mais requisições do que o backend 127.0.0.1:8081. Isso pode ser útil quando um servidor tem mais recursos que o outro.

Health Check dos Backends - Não cai na LPIC

Quando o NGINX é usado como Load Balancer, ele precisa decidir para qual backend cada requisição será enviada. No NGINX Open Source, esse controle é feito de forma passiva.

Isso significa que o NGINX não fica testando os servidores antes de cada requisição. Ele tenta encaminhar a requisição para um backend e, se ocorrer erro, timeout ou falha de conexão, essa falha pode ser contabilizada.

Esse comportamento é chamado de health check passivo, porque a verificação acontece durante o tráfego real dos clientes, de forma simplificada, é assim:

Cliente faz uma requisição
↓
NGINX escolhe um backend
↓
NGINX tenta encaminhar a requisição
↓
Se o backend responder, a requisição segue normalmente
↓
Se o backend falhar, o NGINX contabiliza a falha

Para controlar esse comportamento, podem ser usados os parâmetros max_fails e fail_timeout no bloco upstream.

upstream backend {
    server 127.0.0.1:8080 max_fails=2 fail_timeout=10s;
    server 127.0.0.1:8081 max_fails=2 fail_timeout=10s;
}

Nesse exemplo, se um backend falhar 2 vezes dentro de 10 segundos, o NGINX considera esse servidor temporariamente indisponível e evita encaminhar novas requisições para ele durante esse período.

Depois do tempo definido em fail_timeout, o NGINX pode tentar usar esse backend novamente. O NGINX não remove o backend permanentemente. Ele apenas evita usar aquele servidor por um tempo e depois tenta novamente.

Além de marcar um backend como indisponível temporariamente, também é possível configurar quando o NGINX deve tentar outro servidor do mesmo grupo upstream.

Para isso, é usada a diretiva proxy_next_upstream.

server {
    listen 80 default_server;
    listen [::]:80 default_server;

    server_name _;

    location / {
        proxy_pass http://backend;

        proxy_connect_timeout 2s;
        proxy_read_timeout 10s;
        proxy_send_timeout 10s;

        proxy_next_upstream error timeout http_502 http_503 http_504;

        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-Proto $scheme;
    }
}

A diretiva abaixo define em quais situações o NGINX pode tentar outro backend:

proxy_next_upstream error timeout http_502 http_503 http_504;

Nesse exemplo, o NGINX pode tentar outro servidor quando ocorrer:

error erro de conexão com o backend
timeout timeout ao conectar, enviar ou receber resposta
http_502 Bad Gateway
http_503 Service Unavailable
http_504 Gateway Timeout

Isso ajuda quando um backend fica indisponível ou começa a responder com erro. Em vez de retornar erro imediatamente ao cliente, o NGINX pode tentar outro servidor disponível no grupo.

Health check ativo - Não cai na LPIC-2

O health check ativo é diferente, o balanceador testa os backends periodicamente, mesmo sem requisições de clientes. Normalmente ele acessa uma URL específica, como /health, /status ou /ping, para verificar se a aplicação está saudável.

Se o backend responder corretamente, ele continua recebendo tráfego. Se falhar, o balanceador para de enviar requisições para ele. No NGINX Open Source, o comportamento padrão é o health check passivo. O health check ativo com a diretiva health_check faz parte dos recursos comerciais do NGINX.

Comandos importantes

Comando	Descrição
nginx -t	Testa a configuração, para verificar se existe algum erro.
nginx -s stop/start/reload/status/quit	Comando usado para Parar, Iniciar, Recarregar as configurações, Ver o Status e por fim encerrar o processo do daemon de forma hard

Fontes importantes

https://w3techs.com/technologies/history_overview/web_server

https://en.wikipedia.org/wiki/FastCGI

Introdução​

Instalação do NGINX​

Entendendo o arquivo de configuração​

VirtualHost padrão​

FastCGI/PHP - Não cai na LPIC-2​

Proxy Reverso​

Subindo o container com Apache​

HTML de teste​

Configurando o NGINX como proxy reverso​

Cabeçalhos enviados ao backend​

Testando o proxy reverso​

Load Balance - Não cai na LPIC-2​

Subindo outro container com Apache - Não cai na LPIC-2​

Configurando o upstream no NGINX - Não cai na LPIC-2​

Cabeçalhos enviados ao backend - Não cai na LPIC-2​

Testando o balanceamento - Não cai na LPIC-2​

Health Check dos Backends - Não cai na LPIC​

Health check ativo - Não cai na LPIC-2​

Comandos importantes​

Fontes importantes​