Hostwinds Tutoriais
Resultados da busca por:
Índice
Tag: Cloud Servers, SSL, VPS
Se você está executando um aplicativo da web em uma porta privada (como LocalHost: 3000), não é diretamente acessível pela Internet.Uma das maneiras mais eficazes de expor esse aplicativo com segurança é colocar um proxy reverso na frente dele.
O NGINX é uma ferramenta conhecida leve que pode fazer exatamente isso-recebe tráfego recebido e encaminhe-o para o seu aplicativo-enquanto também lida com HTTPS com um certificado SSL gratuito da Let's Encrypt.
Neste guia, você aprenderá como:
Novo em servidores da web?Confira nossa explicação sobre Como os servidores da web funcionam.
UMA proxy reverso é um servidor que fica entre seus usuários e seus serviços de back -end.Em vez de seu aplicativo ouvindo publicamente em uma porta (como 3000), o Nginx recebe o tráfego primeiro e depois o passa para o aplicativo em execução em segundo plano.
Eis por que essa abordagem é tão útil:
Mesmo que seu aplicativo já possa lidar com o tráfego da Web, o uso do NGINX como proxy reverso geralmente simplifica a configuração, melhora a flexibilidade e aumenta o controle.
Antes de começarmos, certifique -se de ter tudo o que precisa:
A yourdomain.com → 123.123.123.123
A www.yourdomain.com → 123.123.123.123
A propagação pode levar alguns minutos a algumas horas.
Não sabe como configurar seus DNs?Aqui está Como adicionar um registro com a maioria dos hosts de domínio.
Nota: Se o seu aplicativo ainda não estiver em execução, tudo bem - você ainda pode passar pela configuração e testar mais tarde.
sudo apt update
sudo apt install nginx
Então verifique se está em execução:
sudo systemctl status nginx
Você deve ver "ativo (em execução)".
sudo apt install certbot python3-certbot-nginx
Este plug -in permite que o CERTBOT modifique sua configuração nginx automaticamente ao solicitar um certificado - nenhuma edição manual necessária para configurações básicas.
Tem outro sistema operacional?Siga este guia sobre Como instalar Let's Encrypt em Fedora e Debian
Agora que seu sistema está pronto, a primeira etapa real é configurar o NGINX para ouvir o tráfego em seu domínio e encaminhá -lo para o seu aplicativo interno - é isso que faz com que o NGINX atue como um proxy reverso.
Sem essa configuração, os usuários que tentam visitar seu site atingiriam uma página vazia ou a tela de boas -vindas do NGINX padrão.Você precisa dizer explicitamente nginx:
Você criará um arquivo de configuração para o seu domínio no diretório disponível sites da Nginx.Isso mantém as configurações organizadas e facilitam a ativação ou desativação de sites individuais.
sudo nano /etc/nginx/sites-available/yourdomain.com
Cole no bloco a seguir, ajustando o domínio e a porta do aplicativo conforme necessário:
server {
listen 80;
server_name yourdomain.com www.yourdomain.com;
location / {
proxy_pass http://localhost:3000;
proxy_http_version 1.1;
# Pass important headers to the 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;
}
}
Nginx usa links simbólicos no sites habilitados diretório para ativar sites.Então agora você criará um link e recarregue o nginx:
sudo ln -s /etc/nginx/sites-available/yourdomain.com /etc/nginx/sites-enabled/
sudo nginx -t
Verifique se há erros de sintaxe.Se tudo parecer bom:
sudo systemctl reload nginx
Seu proxy reverso está agora ao vivo - pedidos para http://yourdomain.com será passado para o seu aplicativo na porta 3000.
Com o proxy reverso trabalhando sobre o HTTP, a próxima etapa é prendê -lo com HTTPS.Isso adiciona criptografia a toda a comunicação entre seus usuários e seu servidor - protegendo credenciais de login, solicitações de API, dados pessoais e muito mais.
Você usará o Let's Encrypt, uma autoridade de certificação gratuita e o CERTBOT, que automatiza o processo.
Execute este comando, substituindo os domínios por seus valores reais:
sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com
O que isso faz:
CertBot Will:
Dica: Se o seu DNS não estiver totalmente propagado ou o seu servidor Firewall Blocks Port 80, a validação falhará.Você pode testar isso com:
curl -I http://yourdomain.com
Para entender melhor as portas, confira nosso guia sobre Como funcionam as portas do servidor da web.
Depois que o CERTBOT é concluído, sua configuração nginx deve incluir algo assim:
listen 443 ssl;
ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;
Agora você deve visitar https://yourdomain.com e ver seu site com um certificado SSL válido.
Se você não escolheu a opção de redirecionamento durante a configuração do CERTBOT, poderá adicionar isso manualmente:
server {
listen 80;
server_name yourdomain.com www.yourdomain.com;
return 301 https://$host$request_uri;
}
Isso força todo o tráfego HTTP a ser redirecionado para o HTTPS, o que garante que os usuários não usem acidentalmente a versão insegura do seu site.
Depois que seu certificado SSL estiver em vigor, você poderá ajustar o NGINX para melhorar a segurança e a compatibilidade.Essas configurações entram no bloco do servidor HTTPS.
Aqui está um exemplo melhorado:
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
ssl_session_tickets off;
Essas mudanças melhoram sua pontuação de segurança SSL e protegem os visitantes contra ataques de rebaixamento ou opções de criptografia insegura.
Opcional: Você pode testar seu site com o SSL Labs para ver como o seu configuração é executado e obter sugestões específicas de melhoria.
Para uma criptografia ainda mais forte, você pode gerar uma tecla Diffie-Hellman (DH) personalizada.Esta etapa é opcional, mas geralmente é recomendada para ambientes de produção.
Execute este comando para gerar um grupo DH de 2048 bits:
sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048
Em seguida, adicione a seguinte linha ao seu bloco de servidor SSL:
ssl_dhparam /etc/ssl/certs/dhparam.pem;
Os parâmetros Diffie-Hellman se fortalecem sigilo avançado, o que significa que, mesmo que sua chave privada esteja de alguma forma comprometida no futuro, as sessões criptografadas anteriores ainda estarão seguras.
Demora alguns minutos para gerar o grupo DH, mas é um passo único e vale a pena fazer uma melhor postura de segurança.
Vamos criptografar os certificados expirarem a cada 90 dias.Felizmente, o CERTBOT instala um cronômetro de sistema que verifica duas vezes por dia para certificados devido a expirar e renová -los automaticamente.
Você pode confirmar que o timer está ativo com:
sudo systemctl list-timers | grep certbot
Você deve ver algo assim:
NEXT LEFT LAST PASSED UNIT ACTIVATES
2025-06-19 04:00:00 UTC 12h 2025-06-18 04:00:00 UTC 11h ago certbot.timer certbot.service
Para testar o processo de renovação manualmente (sem fazer alterações), execute:
sudo certbot renew --dry-run
Isso simula o processo completo de renovação e confirma que seu sistema está pronto para lidar com ele automaticamente.
Se não houver erros, seus certificados renovarão silenciosamente em segundo plano daqui para frente.
Agora que seu proxy reverso é configurado e protegido com o SSL, é uma boa ideia encerrar com algumas verificações práticas e práticas recomendadas.
Esses hábitos simples podem ajudar a prevenir problemas na linha, facilitar a manutenção de sua configuração e garantir que tudo continue correndo da maneira que você espera.
Mesmo que tudo pareça estar funcionando, gastar alguns minutos extras aqui pode economizar tempo e problemas mais tarde.
Reinicie seu aplicativo se não detectar alterações automaticamente
Alguns aplicativos precisam ser reiniciados para funcionar corretamente atrás de um proxy.
Verifique os logs
Você pode monitorar logs Nginx quanto a erros ou tráfego incomum:
sudo tail -f /var/log/nginx/access.log
sudo tail -f /var/log/nginx/error.log
Mantenha o nginx e o certbot atualizado
Use a atualização SUDO APT UPDATE && SUDO APT regularmente.Pacotes atualizados corrigem os bugs, melhoram os problemas de compatibilidade e patches de segurança.
Depois de dominar o básico da configuração de um proxy reverso seguro, você pode estender sua configuração para suportar necessidades mais complexas.Aqui estão alguns cenários comuns que podem ajudá -lo a tirar mais do seu servidor.
Se você executar vários aplicativos da Web em diferentes portas, o NGINX poderá rotear solicitações para cada aplicativo com base no caminho do domínio ou URL.
Exemplo: diferentes domínios
server {
listen 80;
server_name app1.example.com;
location / {
proxy_pass http://localhost:3001;
# proxy headers here
}
}
server {
listen 80;
server_name app2.example.com;
location / {
proxy_pass http://localhost:3002;
# proxy headers here
}
}
Essa configuração permite que você sirva vários aplicativos usando subdomínios separados, tudo via nginx nas portas padrão.
Usando o Docker?Aprender Como proxy múltiplos aplicativos de docker com nginx.
Como alternativa, você pode proxy com base em caminhos de URL, o que é útil se você deseja todos os aplicativos em um único domínio:
server {
listen 80;
server_name example.com;
location /app1/ {
proxy_pass http://localhost:3001/;
# proxy headers here
}
location /app2/ {
proxy_pass http://localhost:3002/;
# proxy headers here
}
}
Nota: Ao usar o proxy baseado em caminho, as barras e a reescrita de URL podem ficar complicadas-verifique se o aplicativo de back-end pode lidar sendo servido sob um sub-caminho.
Você pode limitar quantas solicitações um cliente pode fazer em um determinado prazo para proteger seu back -end contra abuso ou sobrecarga acidental.
Adicione isso no bloco http em /etc/nginx/nginx.conf:
limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;
Então, no seu servidor ou bloco de localização:
limit_req zone=mylimit burst=20 nodelay;
Essa configuração permite 10 solicitações por segundo com rajadas de até 20 solicitações, retirando solicitações de excesso para evitar sobrecarregar seu aplicativo.
Se você tiver várias instâncias de execução do seu aplicativo (por exemplo, vários contêineres ou VPSs), o Nginx poderá distribuir o tráfego entre eles:
upstream backend {
server 192.168.1.10:3000;
server 192.168.1.11:3000;
}
server {
listen 80;
server_name example.com;
location / {
proxy_pass http://backend;
# proxy headers here
}
}
O NGINX balança solicita-se a Round-Robin por padrão, mas você pode configurá-lo para outros métodos, como menos conexões ou hash IP.
Para saber mais, confira nosso guia sobre DNS Balanceamento de carga.
Você pode personalizar o registro para incluir informações importantes do proxy para solução de problemas ou análises:
log_format proxy '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent" '
'upstream_response_time $upstream_response_time '
'request_time $request_time';
access_log /var/log/nginx/proxy_access.log proxy;
Isso registra os tempos de resposta a montante e os tempos de solicitação totais, ajudando a identificar respostas lentas de back -end.
Você pode adicionar ou modificar cabeçalhos HTTP para segurança ou funcionalidade:
add_header X-Frame-Options SAMEORIGIN;
add_header X-Content-Type-Options nosniff;
add_header Referrer-Policy no-referrer-when-downgrade;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
Esses cabeçalhos protegem contra o clickjacking, o Sniffing Mime e a aplicação do uso de HTTPs.
Escrito por Hostwinds Team / Junho 14, 2019