Você tem um aplicativo em Node.js escutando na porta 5000 e precisa colocá-lo atrás de um servidor HTTP capaz de escalar conexões, encerrar TLS corretamente e aplicar mecanismos de segurança HTTP. O par FreeBSD + NGINX é um encaixe sólido para esse cenário, combinando um sistema operacional maduro com um servidor web de alta performance, exatamente como a Netflix descreve quando fala de sua pilha de entrega com FreeBSD e NGINX (fonte).

Aqui, vamos erguer um proxy reverso NGINX com certificados Let’s Encrypt gerenciados pelo Certbot, preparado para um alvo de ~1.000 conexões TCP/TLS simultâneas, incluindo os sysctls essenciais no FreeBSD e um esqueleto de VM adequado. A camada do aplicativo Node.js fica fora deste howto.

Pré-requisitos.

Uma VM FreeBSD atual (14.x ou 15.x) com DNS apontando para o seu IP público, portas 80 e 443 liberadas até a VM, acesso root e pkg habilitado. O Handbook do FreeBSD descreve o uso do pkg e serviços rc(8); é a base que estamos usando aqui. (docs.freebsd.org)

Preparando a VM ou Hosting.

Para 1.000 conexões simultâneas TLS com folga, dimensione com 2 vCPUs, 4 GB de RAM, disco de 20 GB e virtio para rede e disco. Em FreeBSD, esse perfil acomoda o NGINX com chaves TLS modernas, buffers de proxy e log sem pressão excessiva de memória. Se estiver em um hypervisor comum, selecione virtio-net e virtio-blk, habilite paravirtualização e use um volume local com IOPS razoável; isso evita latências desnecessárias na fila de aceitação de conexões.

Instalação dos componentes.

Instale NGINX e o Certbot com plugin de NGINX pelo pkg. Em versões recentes do FreeBSD, os pacotes costumam estar nomeados para o Python padrão do release (por exemplo, py311). Se o nome divergir no seu release, use “pkg search certbot-nginx” e ajuste a linha. No FreeBSD, o comando sudo não é instalado por padrão. Os comandos abaixo devem ser executados como root (como usuário não root, promova os direitos usando o comando su).

pkg update
pkg install -y nginx py311-certbot py311-certbot-nginx
sysrc nginx_enable="YES"
service nginx start

As instruções oficiais do Certbot para FreeBSD + NGINX confirmam a instalação via pkg ou ports e o uso do plugin “--nginx” para obter e instalar o certificado automaticamente. (Certbot)

Configuração inicial do NGINX.

Crie uma configuração limpa que faça proxy para o Node.js em 127.0.0.1:5000 (ou um ip de outra VM ou Servidor que esteja com a aplicação hospedada), já com parâmetros de performance seguros para a sua meta de 1.000 conexões. O bloco abaixo é um nginx.conf completo, com workers automáticos, fila de aceitação ampla, buffers e timeouts coerentes, redirecionamento HTTP→HTTPS e um server TLS que o Certbot irá “preencher” com os caminhos dos certificados.

# /usr/local/etc/nginx/nginx.conf
user  www;
worker_processes  auto;

events {
    worker_connections  2048;      # cada worker pode gerenciar ~2k conexões
    multi_accept        on;        # aceitar o máximo possível a cada notificação
    use                 kqueue;    # mecanismo nativo no FreeBSD
}

http {
    include             mime.types;
    default_type        application/octet-stream;

    sendfile            on;
    tcp_nopush          on;
    tcp_nodelay         on;

    keepalive_timeout   65s;
    keepalive_requests  1000;

    # Compressão básica para texto
    gzip                on;
    gzip_comp_level     5;
    gzip_min_length     1024;
    gzip_types          text/plain text/css application/json application/javascript application/xml;

    # Headers de segurança essenciais (ajuste o domínio na HSTS quando for para produção)
    server_tokens       off;
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;

    # Upstream do app
    upstream node_upstream {
        server 127.0.0.1:5000 max_fails=3 fail_timeout=30s;
        keepalive 64;
    }

    # Redireciona HTTP para HTTPS
    server {
        listen      80;
        listen      [::]:80;
        server_name exemplo.seudominio.com;

        # Desafio do ACME precisa passar livre no HTTP
        location /.well-known/acme-challenge/ {
            root /usr/local/www/nginx;  # webroot padrão no FreeBSD
        }

        location / {
            return 301 https://$host$request_uri;
        }
    }

    # Server HTTPS; o Certbot preencherá ssl_certificate/ssl_certificate_key
    server {
        listen              443 ssl http2;
        listen              [::]:443 ssl http2;
        server_name         exemplo.seudominio.com;

        # Esses diretórios serão populados pelo Certbot com o plugin --nginx
        ssl_protocols       TLSv1.2 TLSv1.3;
        ssl_prefer_server_ciphers on;

        # Ajustes de sessão e OCSP stapling (Certbot costuma gerenciar automaticamente as diretivas necessárias)
        ssl_session_timeout 1d;
        ssl_session_cache   shared:SSL:10m;

        # Proxy para o Node.js
        location / {
            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;

            proxy_http_version 1.1;
            proxy_set_header Connection "";
            proxy_read_timeout 75s;
            proxy_send_timeout 75s;

            proxy_buffering on;
            proxy_buffers 16 32k;
            proxy_busy_buffers_size 64k;

            proxy_pass http://node_upstream;
        }
    }
}

Os parâmetros worker_process e worker_connections são padrões reconhecidos de ajuste em NGINX para elevar a capacidade por processo e reduzir custo de aceitação; a documentação de performance do NGINX recomenda exatamente esse caminho (worker_processes auto; worker_connections elevado) para ganhar escala de conexões simultâneas.

Solicitando e instalando o certificado com o Certbot.

Com o NGINX ativo e o DNS apontado corretamente, use o plugin de NGINX para obter e aplicar o certificado em um passo. O plugin injeta as diretivas ssl_certificate e ssl_certificate_key no seu server HTTPS e, opcionalmente, cria a força do redirecionamento 80→443.

certbot --nginx -d exemplo.seudominio.com --agree-tos -m seu-email@seudominio.com --redirect
# Renovação automática é instalada como cron ou periodic; você pode testar com:
certbot renew --dry-run

As instruções oficiais do Certbot confirmam o uso do subcomando “--nginx” para obter e instalar o certificado, inclusive em FreeBSD.

Ajustes de kernel e rede no FreeBSD para suportar a carga.

Para um alvo de ~1.000 conexões concorrentes em TLS, o que mais impacta no caminho de aceitação é o tamanho da fila de soquetes pendentes e o limite de descritores. O manual tuning(7) explica que o tamanho da listen queue padrão (128) é pequeno para servidores web; aumentar para 1024 ou mais melhora robustez sob rajadas no número de conexões. Vamos aplicar no /etc/sysctl.conf para persistir ao reboot.

# /etc/sysctl.conf — parâmetros persistentes
kern.ipc.soacceptqueue=1024          # fila de conexões pendentes mais profunda
kern.ipc.somaxconn=1024              # compatível com aplicações que usam SOMAXCONN
kern.maxfiles=250000                 # eleva descritores globais
kern.maxfilesperproc=120000          # eleva descritores por processo (nginx workers)
net.inet.tcp.syncache.hashsize=1024  # melhora a hash do syncache em cargas com muitos SYN
net.inet.tcp.syncache.bucketlimit=100
net.inet.tcp.nolocaltimewait=1       # reduz acúmulo de TIME-WAIT local

A recomendação de elevar a fila de aceitação para ~1024 está documentada no tuning(7); use valores coerentes com a memória disponível. Após salvar, aplique com sysctl -f /etc/sysctl.conf e reinicie em uma janela adequada se alterar loader.conf. (Man FreeBSD)

Validação de ponta a ponta. Inicie ou recarregue o NGINX, cheque logs e teste acesso com e sem TLS.

service nginx reload
sockstat -4 -l | grep ':80\|:443'
curl -I http://exemplo.seudominio.com
curl -I https://exemplo.seudominio.com

Se você preferir que o NGINX também utilize certificados ao falar com um upstream TLS (não é o caso do nosso Node.js em 127.0.0.1:5000, mas fica a referência), a documentação oficial da F5/NGINX mostra as diretivas proxy_ssl_certificate e proxy_ssl_certificate_key para mutual TLS entre NGINX e upstream. (Documentação NGINX)

Confiança, estabilidade e performance.

O sistema operacional FreeBSD tem uma reputação invejável em pilhas TCP/UDP e roteamento, servindo de base para produtos como pfSense, OPNSense e iOS (Cisco) e Juniper. Um sistema bruto que, quando devidamente otimizado por meio de sysctls, oferece ganhos significativos de desempenho sem sacrificar a estabilidade, com uso racional de recursos de processamento e RAM (jemalloc) e a mais avançada tecnologia de sistema de arquivos disponível atualmente, o OpenZFS. Em nossa hospedagem, instalamos e configuramos o sistema e os serviços, incluindo aspectos avançados como HTTP/3, KTLS (o kernel realiza o enquadramento e a criptografia/descriptografia dos dados de conexão TLS para melhorar o desempenho) e 0-RTT (Zero Round-Trip Time Resumption) para aceleração de conexão. Entre em contato conosco para mais informações: https://cloudunix.com.br

Esta resposta lhe foi útil? 0 Usuários acharam útil (0 Votos)