Escovando bits no cPanel: o mistério do webmail, o erro 127.0.0.1 e o cobertor curto do Apache

O mistério do webmail: quando o proxy devolve um redirect para 127.0.0.1#

Problemas intermitentes em servidores de hospedagem costumam ser os mais desafiadores, especialmente quando não aparecem documentados de forma clara.

Recentemente, enfrentei uma falha curiosa: em um dos servidores cPanel, os usuários sofriam com quedas intermitentes ao tentar abrir o Webmail pelo tema Jupiter, enquanto outro servidor na mesma rede com a mesma versão rodava sem nenhum problema.

Fui direto para os logs entender o que estava travando a requisição.

1. O sintoma nos logs e os primeiros passos#

Ao monitorar o log de erros do cPanel (/usr/local/cpanel/logs/error_log), capturei a seguinte exceção no momento exato da tentativa de login:

Template::Exception: [TYPE]=[undef] [INFO]=[Over standard port expect "cpanel." service subdomain, not "127.0.0.1"! at /usr/local/cpanel/Cpanel/WebmailRedirect.pm line 272.]

O erro era explícito: o módulo interno de redirecionamento do cPanel (WebmailRedirect.pm) recusava o acesso porque identificava a origem da conexão como 127.0.0.1 (loopback) em vez de um subdomínio de serviço legítimo (webmail.dominio.com.br). Era uma trava de segurança contra ataques SSRF atuando indevidamente.

Minha primeira hipótese foi verificar se havia divergência nas configurações de redirecionamento no WHM (Tweak Settings > Choose the closest matched domain...):

grep "closest_matched_domain" /var/cpanel/cpanel.config

Ambos os servidores retornaram a configuração padrão desativada. As opções do cpanel.config, DNS interno e o cpnat eram idênticos.

2. Inspecionando a camada de rede com tcpdump#

Para entender exatamente o que o Apache estava entregando para o daemon do cPanel (cpsrvd), usei o tcpdump na interface de loopback (lo) nas portas do Webmail (2095 e 2096):

tcpdump -i lo port 2095 or port 2096 -A -s 0 | grep -i "Host:"

A saída revelou a causa raiz na hora:

Host: 127.0.0.1:2095
X-Forwarded-Host: webmail.dominio.com.br

O Apache estava atuando como um proxy reverso sem preservar o cabeçalho original. Ele recebia a requisição na porta 443, abria a conexão local com o cpsrvd, mas sobrescrevia o cabeçalho Host para 127.0.0.1, jogando o domínio real para o X-Forwarded-Host.

Como o script do cPanel verificava estritamente o Host, ele interpretava a requisição como suspeita e abortava o login.

3. A solução emergencial e o efeito "cobertor curto"#

Para forçar o Apache a manter o domínio original, injetei a diretiva ProxyPreserveHost On globalmente:

echo "ProxyPreserveHost On" >> /etc/apache2/conf.d/includes/pre_virtualhost_global.conf
/usr/local/cpanel/scripts/rebuildhttpdconf
/usr/local/cpanel/scripts/restartsrv_httpd

Ao inspecionar novamente com o tcpdump, o cabeçalho passou correto:

Host: webmail.dominio.com.br
X-Forwarded-Host: webmail.dominio.com.br

O erro de 127.0.0.1 sumiu na hora. O login voltou a funcionar sem bloqueios. Porém, minutos depois, os usuários relataram lentidão severa e timeout ao abrir a caixa de entrada no Roundcube.

Por que o timeout aconteceu?#

Testei a resposta direta do daemon localmente:

time curl -s -k -I -H "Host: webmail.dominio.com.br" https://127.0.0.1:2096 | grep HTTP

A resposta veio em apenas 29 milissegundos. O servidor estava com carga baixa e recursos sobrando.

O problema estava no navegador: ao preservar o Host no Apache, o cpsrvd perdeu a referência de que estava atrás de um proxy na porta 443 e passou a forçar assets (CSS, JS, WebSockets) para a sua porta nativa (:2096). Como muitas redes corporativas e roteadores bloqueiam portas altas como a 2096, os navegadores dos clientes ficavam tentando carregar os arquivos até estourar o timeout.

Reverti a alteração global para restabelecer a fluidez do Webmail:

sed -i '/ProxyPreserveHost On/d' /etc/apache2/conf.d/includes/pre_virtualhost_global.conf
/usr/local/cpanel/scripts/updateuserdatacache --force
/usr/local/cpanel/scripts/rebuildhttpdconf
/usr/local/cpanel/scripts/restartsrv_httpd
/usr/local/cpanel/scripts/restartsrv_cpsrvd

4. O desfecho: bug identificado na raiz e correção oficial da cPanel#

A investigação comprovou que a falha não era erro de configuração de conta, mas sim uma inconsistência interna no manuseio de cabeçalhos de Proxy Subdomains do próprio cPanel.

Posteriormente, a equipe da cPanel catalogou e corrigiu exatamente esse comportamento no changelog oficial da versão 126.0.72:

• Artigo da cPanel: Webmail/cPanel failing to open when using service subdomain ("Over standard port expect cpanel service subdomain, not 127.0.0.1")
• Changelog 126.0.72: Fixed CPANEL-53956: Fix proxy issues.

A experiência reforça uma lição valiosa: quando comandos de rede como tcpdump apontam que o comportamento da pilha diverge da lógica esperada, vale investigar a fundo antes de aplicar regras globais invasivas no servidor web.

Veja também

E-mail Anatomia de uma falha em cascata: do bloqueio de IP por spam à depuração do Roundcube no cPanel

E-mail A anatomia de um troubleshooting: cotas fantasmas, Dovecot e a ilusão do espaço físico em servidores cPanel

Infraestrutura Anatomia de um deadlock silencioso no CloudLinux e cPanel: processos fantasmas, travas de sessão e filas TCP

Este post está licenciado sob CC BY-NC.