cutonboy
Delta
Verificación en dos pasos activada
Verificado por Binance
Dá para fazer no Plesk?
Tutorial: Reverse Proxy com HestiaCP e Nginx: oculte o IP de origem (guia visual)
Este tópico foi traduzido automaticamente do espanhol. Ver original
Carlos Frias
1
Ro
Verificación en dos pasos activada
Verificado por Binance
Usuário popular!
Suscripción a IA
Mas não faria sentido pagar uma licença só para isso🤣
yuck
Beta
Usuário com poucas negociações! Use sempre o saldo do ForoBeta!
Carlos Frias
1
Ro
Verificación en dos pasos activada
Verificado por Binance
Usuário popular!
Suscripción a IA
No decorrer da tarde vou reparar os links quebrados In Progress
wmasterSolutions
VIP
Mi
Verificación en dos pasos activada
Usuário popular!
Suscripción a IA
@Carlos Frias é um dos meus heróis favoritos no Forobeta
Carlos Frias
1
Ro
Verificación en dos pasos activada
Verificado por Binance
Usuário popular!
Suscripción a IA
Tutorial reativado e atualizado! 😎
Voltei a ler o tópico completo e tinha pendentes tanto as dúvidas quanto agradecer a quem passou para comentar. Junto tudo aqui para não encher o tópico de respostas seguidas.
O guia da primeira mensagem já está renovado: repositório e modelos reparados, varredura automática com backup, novas capturas e HTTPS verificado até o servidor final. Refiz o exercício do zero e deixei explicado o que foi testado e o que fica fora do alcance. O processo conserva a simplicidade da receita original.
Vou primeiro com as consultas que tinham ficado no tópico:
Você tinha razão, esse repositório eu retirei e deixei os links quebrados. Te devia esse reparo. Já estão os arquivos no novo repositório público e a primeira mensagem tem o procedimento atualizado. O pacote do proxy agora é criado pelo script com a CLI do Hestia; você já não depende de baixar aquele default.pkg separadamente. Obrigado por avisar.
Voltei a ler tudo o que você foi contando, e obrigado também por compartilhar como você ia resolvendo. Aquela limitação do Ubuntu não convém arrastar como uma regra permanente: refiz o exercício com Ubuntu 24.04 LTS e o instalador estável do Hestia. Para montar hoje, revise a compatibilidade oficial e utilize uma VPS limpa. Para mudar o sistema usa-se Rebuild/Reinstall no painel da VPS do provedor, não dentro do Hestia. Antes faça backup de qualquer dado e guarde as novas credenciais: a reinstalação substitui o sistema.
Aqui atualizo também minha recomendação antiga: o objetivo agora é Full (strict), com o certificado da VPS funcionando. Que apareça o cadeado do navegador não demonstra que estão cifrados os demais trechos; Flexible conecta Cloudflare com a VPS por HTTP. Os modelos novos, além disso, conectam a VPS com o servidor final mediante HTTPS e verificam seu certificado.
O 521 significa que o servidor para o qual aponta o Cloudflare rejeita a conexão. Para o caso domínio/www: aponte ambos para a VPS proxy, corrija os AAAA que apontem para outro servidor, adicione www como alias no Hestia e confirme que o Nginx escute na 443 para Full (strict), aceitando as conexões do Cloudflare. Comprove por HTTPS tanto o domínio quanto o www.
Para o 403 do Let’s Encrypt: leia o registro de emissão, verifique que cada nome solicitado resolva para a VPS e permita o challenge HTTP na porta 80. Para a primeira emissão você pode deixar esses registros em Apenas DNS. Se o bloqueio for uma regra, limite a exceção ao challenge necessário; um user-agent por si só não identifica de forma confiável o Let’s Encrypt. Emita o certificado antes de forçar HTTPS e mantenha funcionando a renovação de ambos os extremos.
Este detalhe sim, incorporei ao reparo. O modelo rp novo envia à origem também robots.txt e os sitemaps, incluindo sitemap_index.xml se o seu WordPress o publicar. Testei robots.txt e um sitemap comparando o conteúdo recebido com o da origem. Na sua instalação comprove que esteja selecionado rp e revise o cache externo; apagar um arquivo local não corrige por si só qual localização do Nginx atende a petição.
Sobre como poderiam descobrir a origem: o histórico DNS, IPv6, e-mail ou uma petição de saída da aplicação podem revelar seu IP. Conhecer esse IP não concede acesso ao servidor. Interceptar tráfego requer uma posição a partir da qual observá-lo ou intervir nele; TLS protege seu conteúdo, embora não oculte os endereços aos operadores de rede. A defesa combina HTTPS verificado, aplicação atualizada e restrição do acesso web à origem quando o provedor o permitir. O proxy adiciona essa separação, não anonimato absoluto.
Boa observação; esta parte merecia ficar melhor resolvida. A atualização já utiliza HTTPS entre a VPS e a origem, com SNI e verificação do certificado, sem desativar a validação para que “funcione”.
A origem pode usar 443 com TLS válido. A restrição de acesso é outra parte do trabalho: se você administra ambos os extremos, pode limitar quem chega à origem ou empregar uma rede privada/VPN. Em hospedagem compartilhada toca coordenar com o provedor. Para a variante VPN, conecte ambos os servidores pelo túnel, direcione o proxy para o IP privado da origem e permita seu acesso web apenas a partir da rede ou interface autorizada, conservando administração e renovação SSL. Se você mantiver HTTPS dentro do túnel, o nome SNI deve continuar coincidindo com o certificado da origem. Isso requer controle de ambos os extremos; uma hospedagem compartilhada normalmente não te permite criar essa VPN. Esta edição comprova o percurso HTTPS público, não implementa essa variante. Obrigado por abrir essa conversa.
Você já tem uma atualização que recolhe a parte da cifragem que comentavam: HTTPS até a origem, validação do certificado e explicação dos limites de privacidade. A alternativa que você pedia fica assim: VPN entre os dois servidores, Nginx apontando para o IP do túnel da origem e acesso web restrito a esse link, sem perder a administração nem a renovação de certificados. Você precisa administrar ambos os servidores. Se a origem é compartilhada, o percurso disponível neste guia é HTTPS verificado e as restrições que seu provedor permitir. A VPN requer essa montagem adicional e não faz parte dos testes publicados.
Sim, no Plesk para Linux também se pode adaptar um Reverse Proxy com Nginx. E matizo aquela resposta tão curta que te dei 😅: se você já tem Plesk, faz sentido aproveitá-lo. O que não se transfere diretamente são rp.tpl/rp.stpl nem o script do Hestia; é preciso adaptar a configuração aos mecanismos do Plesk e conservá-la frente a reconstruções. Sua documentação explica as diretivas adicionais do Nginx. O exercício que acabei de comprovar continua sendo o do Hestia.
Sim, se seu atualizador baixa os executáveis por HTTP/HTTPS, você pode colocar esses downloads atrás do proxy. Para arquivos grandes testaria também integridade, retomada de downloads mediante Range e tempos de espera; que carregue a capa não valida todo esse percurso. Os serviços do Windows que usem outros protocolos precisam de outra configuração. Obrigado por contribuir com esse uso, que vai além de servir uma página.
Obrigado por ter trazido as instruções do provedor quando travou com a reinstalação. Essa ajuda veio bem no momento. Na revisão deixei o percurso independente de um painel de VPS concreto: sistema compatível, instalação limpa e acessos do provedor que cada um utilize. Assim o guia não fica atado a que um botão continue se chamando igual.
Obrigado, essa é a ideia: que o domínio publique o IP do proxy enquanto a web permanece na origem. Agora expliquei melhor também o que pode revelar essa origem, para que ninguém confunda essa camada de privacidade com anonimato absoluto.
E obrigado também a todos que deixaram seu apoio:
Obrigado a você por estreá-lo com esse ânimo! Deixei-o novamente em dia para que continue sendo útil.
Obrigado por passar! Aí fica a revisão caso volte a precisar da montagem.
Um prazer compartilhá-lo, Daniel. Obrigado pelo apoio desde a primeira versão.
Hahaha, obrigado, tigre 😎. Estava na hora de dar manutenção ao tutorial também, que esses links não podiam ficar assim.
Obrigado! Passou um tempinho desde aquela mensagem 😅. Caso volte a usá-lo, já tem os modelos reparados e as capturas renovadas.
Obrigado, man. É apreciado que tenha tirado um tempo para deixar o comentário.
Obrigado por essas palavras! Desta vez revisei também os detalhes que tinham ficado pendentes nos comentários.
Obrigado a você por recebê-lo assim. Compartilhá-lo faz mais sentido quando entre todos vão saindo melhorias.
Obrigado, compa! 😎 Já ficou reparado para poder continuar aproveitando.
Essa é uma boa razão para testá-lo 😄. Faça o laboratório em uma VPS nova e com um domínio de teste; a varredura não é para um painel que já aloje webs.
Obrigado por guardá-lo! Já merece outra visita a esses favoritos, que mudou bastante desde então.
Obrigado a você, Antik. Tomara que a revisão te sirva para entender melhor o que ocorre em cada trecho do proxy.
Hahaha, o «Es bellísimo» tinha que ficar 😂. Mantive-o no guia renovado.
Isso era o que buscava ao publicá-lo. Obrigado por contar e por guardá-lo para depois 💪.
Obrigado pelo apoio, Gregh. Já ficou disponível outra vez com os arquivos corrigidos.
Obrigado! Se você retomar, comece pela versão nova da primeira mensagem; assim usa os modelos que acabei de comprovar.
Obrigado a você pelo comentário. Dá gosto voltar ao tópico e ver que tanta gente se animou a aprender com ele.
Hahaha, obrigado pelo carinho. Com manter vivos os links já vou cumprindo uma missão pendente 😅.
De nada, compa. Tentei conservar essa simplicidade e esclarecer as partes onde surgiram dúvidas.
Hahaha, obrigado, Mega! Aí fica a atualização 😎.
Muito obrigado por essa mensagem. Gosto que o fórum conserve tutoriais que se possam seguir e discutir entre todos; por isso quis reparar este e responder o que tinha ficado aberto.
Obrigado a você por passar. Fico feliz que a explicação tenha te resultado útil.
Obrigado! Agora também deixei explicadas as comprovações e os limites da montagem.
Hahaha, fico feliz que tenha te servido outra vez. Já estava na hora de devolver o favor ao tópico e deixá-lo funcionando de novo.
Hahaha, obrigado pelo carinho e por levantar o tópico. Já posso voltar com o repositório reparado e a atualização publicada, que era o que faltava 😄.
Obrigado a todos por dar vida ao tópico. Os arquivos reparados, as capturas novas e o procedimento completo já estão na primeira mensagem. Aí fica a atualização de Outubro de 2026 🙂.
Voltei a ler o tópico completo e tinha pendentes tanto as dúvidas quanto agradecer a quem passou para comentar. Junto tudo aqui para não encher o tópico de respostas seguidas.
O guia da primeira mensagem já está renovado: repositório e modelos reparados, varredura automática com backup, novas capturas e HTTPS verificado até o servidor final. Refiz o exercício do zero e deixei explicado o que foi testado e o que fica fora do alcance. O processo conserva a simplicidade da receita original.
Vou primeiro com as consultas que tinham ficado no tópico:
Você tinha razão, esse repositório eu retirei e deixei os links quebrados. Te devia esse reparo. Já estão os arquivos no novo repositório público e a primeira mensagem tem o procedimento atualizado. O pacote do proxy agora é criado pelo script com a CLI do Hestia; você já não depende de baixar aquele default.pkg separadamente. Obrigado por avisar.
Voltei a ler tudo o que você foi contando, e obrigado também por compartilhar como você ia resolvendo. Aquela limitação do Ubuntu não convém arrastar como uma regra permanente: refiz o exercício com Ubuntu 24.04 LTS e o instalador estável do Hestia. Para montar hoje, revise a compatibilidade oficial e utilize uma VPS limpa. Para mudar o sistema usa-se Rebuild/Reinstall no painel da VPS do provedor, não dentro do Hestia. Antes faça backup de qualquer dado e guarde as novas credenciais: a reinstalação substitui o sistema.
Aqui atualizo também minha recomendação antiga: o objetivo agora é Full (strict), com o certificado da VPS funcionando. Que apareça o cadeado do navegador não demonstra que estão cifrados os demais trechos; Flexible conecta Cloudflare com a VPS por HTTP. Os modelos novos, além disso, conectam a VPS com o servidor final mediante HTTPS e verificam seu certificado.
O 521 significa que o servidor para o qual aponta o Cloudflare rejeita a conexão. Para o caso domínio/www: aponte ambos para a VPS proxy, corrija os AAAA que apontem para outro servidor, adicione www como alias no Hestia e confirme que o Nginx escute na 443 para Full (strict), aceitando as conexões do Cloudflare. Comprove por HTTPS tanto o domínio quanto o www.
Para o 403 do Let’s Encrypt: leia o registro de emissão, verifique que cada nome solicitado resolva para a VPS e permita o challenge HTTP na porta 80. Para a primeira emissão você pode deixar esses registros em Apenas DNS. Se o bloqueio for uma regra, limite a exceção ao challenge necessário; um user-agent por si só não identifica de forma confiável o Let’s Encrypt. Emita o certificado antes de forçar HTTPS e mantenha funcionando a renovação de ambos os extremos.
Este detalhe sim, incorporei ao reparo. O modelo rp novo envia à origem também robots.txt e os sitemaps, incluindo sitemap_index.xml se o seu WordPress o publicar. Testei robots.txt e um sitemap comparando o conteúdo recebido com o da origem. Na sua instalação comprove que esteja selecionado rp e revise o cache externo; apagar um arquivo local não corrige por si só qual localização do Nginx atende a petição.
Sobre como poderiam descobrir a origem: o histórico DNS, IPv6, e-mail ou uma petição de saída da aplicação podem revelar seu IP. Conhecer esse IP não concede acesso ao servidor. Interceptar tráfego requer uma posição a partir da qual observá-lo ou intervir nele; TLS protege seu conteúdo, embora não oculte os endereços aos operadores de rede. A defesa combina HTTPS verificado, aplicação atualizada e restrição do acesso web à origem quando o provedor o permitir. O proxy adiciona essa separação, não anonimato absoluto.
Boa observação; esta parte merecia ficar melhor resolvida. A atualização já utiliza HTTPS entre a VPS e a origem, com SNI e verificação do certificado, sem desativar a validação para que “funcione”.
A origem pode usar 443 com TLS válido. A restrição de acesso é outra parte do trabalho: se você administra ambos os extremos, pode limitar quem chega à origem ou empregar uma rede privada/VPN. Em hospedagem compartilhada toca coordenar com o provedor. Para a variante VPN, conecte ambos os servidores pelo túnel, direcione o proxy para o IP privado da origem e permita seu acesso web apenas a partir da rede ou interface autorizada, conservando administração e renovação SSL. Se você mantiver HTTPS dentro do túnel, o nome SNI deve continuar coincidindo com o certificado da origem. Isso requer controle de ambos os extremos; uma hospedagem compartilhada normalmente não te permite criar essa VPN. Esta edição comprova o percurso HTTPS público, não implementa essa variante. Obrigado por abrir essa conversa.
Você já tem uma atualização que recolhe a parte da cifragem que comentavam: HTTPS até a origem, validação do certificado e explicação dos limites de privacidade. A alternativa que você pedia fica assim: VPN entre os dois servidores, Nginx apontando para o IP do túnel da origem e acesso web restrito a esse link, sem perder a administração nem a renovação de certificados. Você precisa administrar ambos os servidores. Se a origem é compartilhada, o percurso disponível neste guia é HTTPS verificado e as restrições que seu provedor permitir. A VPN requer essa montagem adicional e não faz parte dos testes publicados.
Sim, no Plesk para Linux também se pode adaptar um Reverse Proxy com Nginx. E matizo aquela resposta tão curta que te dei 😅: se você já tem Plesk, faz sentido aproveitá-lo. O que não se transfere diretamente são rp.tpl/rp.stpl nem o script do Hestia; é preciso adaptar a configuração aos mecanismos do Plesk e conservá-la frente a reconstruções. Sua documentação explica as diretivas adicionais do Nginx. O exercício que acabei de comprovar continua sendo o do Hestia.
Sim, se seu atualizador baixa os executáveis por HTTP/HTTPS, você pode colocar esses downloads atrás do proxy. Para arquivos grandes testaria também integridade, retomada de downloads mediante Range e tempos de espera; que carregue a capa não valida todo esse percurso. Os serviços do Windows que usem outros protocolos precisam de outra configuração. Obrigado por contribuir com esse uso, que vai além de servir uma página.
Obrigado por ter trazido as instruções do provedor quando travou com a reinstalação. Essa ajuda veio bem no momento. Na revisão deixei o percurso independente de um painel de VPS concreto: sistema compatível, instalação limpa e acessos do provedor que cada um utilize. Assim o guia não fica atado a que um botão continue se chamando igual.
Obrigado, essa é a ideia: que o domínio publique o IP do proxy enquanto a web permanece na origem. Agora expliquei melhor também o que pode revelar essa origem, para que ninguém confunda essa camada de privacidade com anonimato absoluto.
E obrigado também a todos que deixaram seu apoio:
Obrigado a você por estreá-lo com esse ânimo! Deixei-o novamente em dia para que continue sendo útil.
Obrigado por passar! Aí fica a revisão caso volte a precisar da montagem.
Um prazer compartilhá-lo, Daniel. Obrigado pelo apoio desde a primeira versão.
Hahaha, obrigado, tigre 😎. Estava na hora de dar manutenção ao tutorial também, que esses links não podiam ficar assim.
Obrigado! Passou um tempinho desde aquela mensagem 😅. Caso volte a usá-lo, já tem os modelos reparados e as capturas renovadas.
Obrigado, man. É apreciado que tenha tirado um tempo para deixar o comentário.
Obrigado por essas palavras! Desta vez revisei também os detalhes que tinham ficado pendentes nos comentários.
Obrigado a você por recebê-lo assim. Compartilhá-lo faz mais sentido quando entre todos vão saindo melhorias.
Obrigado, compa! 😎 Já ficou reparado para poder continuar aproveitando.
Essa é uma boa razão para testá-lo 😄. Faça o laboratório em uma VPS nova e com um domínio de teste; a varredura não é para um painel que já aloje webs.
Obrigado por guardá-lo! Já merece outra visita a esses favoritos, que mudou bastante desde então.
Obrigado a você, Antik. Tomara que a revisão te sirva para entender melhor o que ocorre em cada trecho do proxy.
Hahaha, o «Es bellísimo» tinha que ficar 😂. Mantive-o no guia renovado.
Isso era o que buscava ao publicá-lo. Obrigado por contar e por guardá-lo para depois 💪.
Obrigado pelo apoio, Gregh. Já ficou disponível outra vez com os arquivos corrigidos.
Obrigado! Se você retomar, comece pela versão nova da primeira mensagem; assim usa os modelos que acabei de comprovar.
Obrigado a você pelo comentário. Dá gosto voltar ao tópico e ver que tanta gente se animou a aprender com ele.
Hahaha, obrigado pelo carinho. Com manter vivos os links já vou cumprindo uma missão pendente 😅.
De nada, compa. Tentei conservar essa simplicidade e esclarecer as partes onde surgiram dúvidas.
Hahaha, obrigado, Mega! Aí fica a atualização 😎.
Muito obrigado por essa mensagem. Gosto que o fórum conserve tutoriais que se possam seguir e discutir entre todos; por isso quis reparar este e responder o que tinha ficado aberto.
Obrigado a você por passar. Fico feliz que a explicação tenha te resultado útil.
Obrigado! Agora também deixei explicadas as comprovações e os limites da montagem.
Hahaha, fico feliz que tenha te servido outra vez. Já estava na hora de devolver o favor ao tópico e deixá-lo funcionando de novo.
Hahaha, obrigado pelo carinho e por levantar o tópico. Já posso voltar com o repositório reparado e a atualização publicada, que era o que faltava 😄.
Obrigado a todos por dar vida ao tópico. Os arquivos reparados, as capturas novas e o procedimento completo já estão na primeira mensagem. Aí fica a atualização de Outubro de 2026 🙂.
Daniel Muñoz
1
Pi
Programador
Verificado
Verificación en dos pasos activada
Verificado por Binance
Usuário popular!
Suscripción a IA
Excelente, minha pergunta é, não é mais fácil com wireguard?
Ou até mesmo um túnel do cloudflare?
Carlos Frias
1
Ro
Verificación en dos pasos activada
Verificado por Binance
Usuário popular!
Suscripción a IA
Não são métodos "Offshore". Se você conseguir algo assim, é provável que, a curto prazo, acabe com a conta ou a zona suspensa.
O cliente que usa esta forma de se proteger está se protegendo contra denúncias de DMCA ou inclusive de preocupações regulatórias além do normal.
Ou seja, quando o cliente não quer que nem mesmo a Cloudflare saiba onde o site está hospedado, por isso se trata de divorciar uma coisa da outra.
Tópicos similares
