Guia proxy reverso webmail Cloudflare sem erro SSL

Guia proxy reverso webmail Cloudflare sem erro SSL é o procedimento de colocar Roundcube, Horde ou similar atrás de Nginx (ou outro reverse proxy) com o DNS laranja do Cloudflare, usando modo Full (strict) e certificado válido na origem para eliminar aviso de certificado, loop HTTPS e conteúdo misto. Para configurar proxy reverso para webmail atrás do Cloudflare sem erro SSL, siga estes passos:

1. Aponte o hostname do webmail no Cloudflare (proxy laranja) e defina SSL/TLS em Full (strict).
2. Instale certificado válido na origem (Let's Encrypt ou Origin CA) no proxy Nginx.
3. Crie o server block com proxy_pass, Host, X-Forwarded-Proto e X-Forwarded-For.
4. Ajuste a base URL do webmail para HTTPS e desative cache agressivo no path.
5. Teste TLS na origem e no edge; corrija redirecionamentos HTTP forçados.
6. Valide login, anexos e WebSockets sem quebrar IMAP/SMTP nas portas nativas.

Pré-requisitos

• Servidor com Debian 13, AlmaLinux 10 ou Rocky Linux 10 e acesso root ou sudo via SSH.
• Nginx 1.26+ (ou superior da distro) instalado e escutando 443 na origem.
• Webmail (Roundcube ou Horde) já respondendo em HTTP/HTTPS local (ex.: 127.0.0.1:8080 ou socket do painel).
• Domínio no Cloudflare com registro A/AAAA ou CNAME para o hostname do webmail (ex.: webmail.seudominio.com.br) com proxy laranja ativo.
• Portas 80 e 443 liberadas no firewall da origem para o tráfego do Cloudflare (ou só IPs oficiais da Cloudflare, se restringir).
• Ferramentas de diagnóstico: curl, openssl, ss; Certbot ou certificado Origin CA da Cloudflare.

Guia proxy reverso webmail Cloudflare sem erro SSL na origem

O núcleo do guia proxy reverso webmail Cloudflare sem erro SSL é alinhar o que o visitante vê no navegador com o que o Nginx apresenta ao edge da Cloudflare. Em Full (strict), o Cloudflare abre TLS até a origem e exige nome e cadeia válidos. Flexible fala HTTPS com o cliente e HTTP com o servidor: isso costuma gerar loop de redirecionamento, cookie inseguro ou página de aviso. Antes de editar o proxy, confira o modo em SSL/TLS no painel Cloudflare e o certificado local.

No servidor de origem, confirme que a porta 443 está em escuta e que o hostname resolve para o IP público documentado (use 203.0.113.10 apenas como exemplo de laboratório):

ss -tlnp | grep -E ':443|:80'
curl -sI --resolve webmail.seudominio.com.br:443:127.0.0.1 https://webmail.seudominio.com.br/

Output esperado:
LISTEN 0 511 0.0.0.0:443 0.0.0.0:* users:(("nginx",pid=1234,fd=8))
HTTP/1.1 200 OK
server: nginx

Se ainda não houver certificado na origem, em Debian 13 com Certbot e plugin Nginx:

sudo apt update
sudo apt install -y nginx certbot python3-certbot-nginx
sudo certbot --nginx -d webmail.seudominio.com.br --redirect

Alternativa estável com Cloudflare: em SSL/TLS → Origin Server, crie um Origin Certificate para webmail.seudominio.com.br, salve o .pem e a chave no servidor (por exemplo /etc/ssl/cloudflare/) e referencie-os no server block. Esse certificado é confiado pelo Cloudflare em Full (strict), mas não por navegadores que acessem a origem direto — o que é desejável quando só o edge deve ser público. Para o fluxo de e-mail completo no mesmo host, veja também o passo a passo para configurar servidor de e-mail no VPS Linux.

Configurar Nginx como reverse proxy do webmail

O reverse proxy HTTP precisa repassar o host original e o esquema HTTPS visto pelo cliente; sem isso Roundcube e Horde geram links http://, misturam conteúdo ou invalidam a sessão. Crie um arquivo de site dedicado, por exemplo em /etc/nginx/sites-available/webmail-cloudflare.conf no Debian, ou em /etc/nginx/conf.d/ no AlmaLinux 10 e Rocky Linux 10.

server {
    listen 443 ssl http2;
    server_name webmail.seudominio.com.br;

    ssl_certificate     /etc/letsencrypt/live/webmail.seudominio.com.br/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/webmail.seudominio.com.br/privkey.pem;
    # Ou Origin CA:
    # ssl_certificate     /etc/ssl/cloudflare/webmail.pem;
    # ssl_certificate_key /etc/ssl/cloudflare/webmail.key;

    client_max_body_size 50M;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_http_version 1.1;
        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_set_header X-Forwarded-Host $host;
        proxy_read_timeout 300;
        proxy_buffering off;
    }
}

server {
    listen 80;
    server_name webmail.seudominio.com.br;
    return 301 https://$host$request_uri;
}

Ative e teste a configuração:

sudo nginx -t && sudo systemctl reload nginx
curl -sI https://webmail.seudominio.com.br/ | head -n 15
openssl s_client -connect 203.0.113.10:443 -servername webmail.seudominio.com.br </dev/null 2>/dev/null | openssl x509 -noout -subject -dates

Output esperado:
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
HTTP/2 200
strict-transport-security: max-age=...
subject=CN = webmail.seudominio.com.br

Atenção: não aponte proxy_pass para a URL pública do mesmo hostname com proxy laranja ativo — isso cria loop Cloudflare → origem → Cloudflare. O upstream deve ser IP/porta local ou rede interna. Se o webmail já escuta HTTPS localmente, use proxy_pass https://127.0.0.1:8443; e, se o certificado interno for autoassinado, avalie proxy_ssl_verify off; apenas nesse trecho interno, mantendo Full (strict) entre Cloudflare e o Nginx de borda.

No Cloudflare, em Caching → Cache Rules (ou Page Rules legadas), evite cache de HTML/cookies do path do webmail; prefira Bypass cache para webmail.seudominio.com.br/*. Em Network, WebSockets deve permanecer ligado se o cliente web usar conexão persistente. DNS do hostname: registro A para o IP da origem com nuvem laranja. MX e registros de envio não devem ser “proxied” da mesma forma que o webmail HTTP; para zona e tipos de registro, consulte o guia de zona DNS: registros A, MX, CNAME e TXT do zero.

Ajustar Roundcube e Horde para HTTPS atrás do Cloudflare

Mesmo com TLS correto no proxy, a aplicação de webmail pode forçar URL base em HTTP ou ignorar X-Forwarded-Proto. No Roundcube, edite config.inc.php (caminho típico /var/www/roundcube/config/config.inc.php) e force o esquema seguro e o servidor detectado pelo proxy:

$config['use_https'] = true;
$config['force_https'] = true;
// Se houver proxy confiável na frente:
$config['proxy_whitelist'] = array('127.0.0.1', '::1');
// Base URL absoluta em HTTPS (ajuste o path se não for raiz)
$config['request_path'] = '/';

Reinicie o PHP-FPM da pool usada pelo webmail após a alteração:

sudo systemctl reload php8.4-fpm
# AlmaLinux/Rocky com php-fpm genérico:
# sudo systemctl reload php-fpm

No Horde, confira conf.php / preferências de URL do sistema para que links de login, logout e anexos usem https://webmail.seudominio.com.br. Desative redirecionamentos duplicados no Apache/Nginx interno que convertam de novo para HTTP. Cookies de sessão devem sair com flag Secure; se o app achar que a conexão é HTTP por falta de X-Forwarded-Proto, o login “funciona” e em seguida cai ou o navegador bloqueia cookie misto.

Teste ponta a ponta com o DNS já no Cloudflare:

curl -sI https://webmail.seudominio.com.br/ | grep -iE 'HTTP|location|strict-transport|cf-ray'

Output esperado:
HTTP/2 200
strict-transport-security: max-age=15552000
cf-ray: 8f2a1b2c3d4e5f6a-GRU

Presença de cf-ray confirma passagem pelo edge. Ausência de Location para http:// indica que o redirect loop foi eliminado. Mantenha autenticação de e-mail (SPF, DKIM, DMARC) coerente com o domínio; o proxy do webmail não substitui a reputação de envio — veja o guia DKIM, SPF e DMARC: configure e saia do spam.

Validar Full strict e certificado na origem

Terminologia de edge e origem importa: “Full” aceita certificado na origem sem validar CA pública; “Full (strict)” exige CA reconhecida ou Origin Certificate Cloudflare. Para produção de webmail, Full (strict) é o alvo. No painel: SSL/TLS → Overview → Full (strict). Em Edge Certificates, ative Always Use HTTPS. Não use Flexible com reverse proxy de webmail.

Simule a checagem que o Cloudflare faz na origem (substitua o IP pelo real da VPS):

openssl s_client -connect 203.0.113.10:443 -servername webmail.seudominio.com.br </dev/null 2>/dev/null | openssl x509 -noout -issuer -subject -ext subjectAltName

Output esperado:
issuer=C = US, O = Let's Encrypt, CN = R11
subject=CN = webmail.seudominio.com.br
X509v3 Subject Alternative Name:
    DNS:webmail.seudominio.com.br

Se o CN/SAN não incluir o mesmo nome do registro DNS laranja, o strict falha com erro 526 no navegador. Renove ou reemita o certificado cobrindo exatamente esse FQDN. Para redirecionamento HTTP→HTTPS na origem sem conflito com o edge, o padrão return 301 no server :80 costuma bastar; em cenários de site misto, o material como redirecionar um site http para https ajuda a evitar regras duplicadas.

Problemas comuns e como resolver

Sintoma: erro 526 Invalid SSL certificate no Cloudflare

Causa: modo Full (strict) ativo, mas a origem apresenta certificado expirado, autoassinado não Origin CA, ou nome diferente de webmail.seudominio.com.br.
Solução: reinstale Let's Encrypt com o FQDN correto ou instale o Origin Certificate no Nginx; confira com openssl s_client o SAN; recarregue o Nginx e purgue cache do edge se houver página de erro antiga.

Sintoma: ERR_TOO_MANY_REDIRECTS ao abrir o webmail

Causa: Flexible no Cloudflare combinado com redirect forçado para HTTPS na origem, ou aplicação gerando Location: http:// enquanto o edge força HTTPS.
Solução: mude para Full (strict); garanta X-Forwarded-Proto $scheme; force use_https/force_https no Roundcube; remova redirects HTTP internos redundantes.

Sintoma: login ok, mas assets ou anexos em conteúdo misto

Causa: base URL ou temas do webmail ainda apontam para http://; cache de HTML antigo no Cloudflare.
Solução: corrija URL absoluta em HTTPS na config do app; Bypass cache no hostname do webmail; hard refresh no navegador; confira cabeçalhos Content-Security-Policy se existirem.

Sintoma: webmail lento ou timeout em mensagens grandes

Causa: client_max_body_size baixo no Nginx, proxy_read_timeout curto ou limite de upload do PHP-FPM.
Solução: eleve client_max_body_size (ex.: 50M), proxy_read_timeout 300 e upload_max_filesize/post_max_size no PHP; teste envio de anexo controlado.

Perguntas frequentes sobre guia proxy reverso webmail Cloudflare sem erro SSL

Por que o webmail dá erro SSL atrás do Cloudflare?

O erro costuma ocorrer quando o modo SSL/TLS do Cloudflare não combina com o certificado na origem. Em Flexible o Cloudflare fala HTTPS com o visitante e HTTP com o servidor, gerando loop ou aviso. Use Full (strict) com certificado válido no proxy ou no servidor de webmail.

Qual modo SSL do Cloudflare usar com proxy reverso de webmail?

Use Full (strict). Assim o Cloudflare valida o certificado da origem (Let's Encrypt, origem Cloudflare ou comercial). Evite Flexible em produção. Confirme que o hostname do webmail no certificado cobre o mesmo nome exposto no DNS laranja.

Preciso de certificado na origem se já uso Cloudflare?

Sim, com Full (strict) a origem precisa apresentar TLS válido. Pode ser Let's Encrypt no Nginx, certificado de origem Cloudflare instalado no proxy, ou o SSL do painel se o webmail já escuta HTTPS localmente atrás do reverse proxy.

Roundcube ou Horde funcionam atrás de proxy reverso com Cloudflare?

Sim, desde que o proxy encaminhe Host, X-Forwarded-Proto e X-Forwarded-For e a aplicação confie no esquema HTTPS. Ajuste base URL ou configs que forcem HTTP, desative cache agressivo no path do webmail e mantenha WebSockets se o cliente web exigir.

O proxy reverso quebra IMAP e SMTP do e-mail?

Proxy reverso HTTP(S) cobre só o webmail no navegador. IMAP, POP3 e SMTP continuam nas portas próprias e em geral não passam pelo proxy HTTP do Cloudflare da mesma forma. Para clientes de desktop, use registros MX/A corretos e TLS nas portas de e-mail, não só o proxy do webmail.

Conclusão

• Deixe o Cloudflare em Full (strict), com certificado Let's Encrypt ou Origin CA válido no Nginx da origem para o mesmo FQDN do DNS laranja.
• Configure o reverse proxy com Host e X-Forwarded-Proto e alinhe Roundcube/Horde para HTTPS, sem cache agressivo no path do webmail.
• Separe o papel do proxy HTTP (interface web) do tráfego IMAP/SMTP nas portas nativas e valide com curl, openssl e um login real.

Leia também

• Solucionar latência no PS5: configurar DNS Cloudflare em 2026
• Guia Completo para Configurar E-mails Profissionais no cPanel
• passo a passo: 'SMTP Error' no cPanel: o que fazer

Precisa de ajuda com proxy reverso e webmail no Cloudflare?

Um VPS com recursos dedicados facilita manter Nginx, certificados e o stack de e-mail sob controle, com acesso SSH para aplicar o guia com segurança. Se preferir ambiente já preparado para produção, avalie as opções de servidor virtual da AviraHost.

Conhecer planos de VPS AviraHost