Por que os navegadores podem ocultar a página de bloqueio HTTPS do Squid
Entenda por que um navegador pode mostrar o próprio erro de túnel em vez do HTML personalizado retornado para uma solicitação CONNECT negada.
A página de bloqueio personalizada do proxy aparece para um site HTTP. Para um site HTTPS, o navegador mostra um erro de túnel. Substituir novamente o modelo HTML pode não mudar nada.
Com um proxy HTTP explícito, uma visita HTTPS normalmente começa com CONNECT. O navegador pede ao proxy que abra um túnel para um host e uma porta. Se o Squid rejeitar essa solicitação, a sessão TLS do site nunca começa.
A rejeição pode ter um status HTTP e conteúdo de resposta. Você pode inspecionar essa resposta CONNECT com falha usando curl independentemente da página de erro do navegador. Isso não exige que o navegador apresente o HTML fornecido como a página web do destino. Um navegador pode descartar o corpo do erro CONNECT e usar sua própria interface de erro de proxy; a apresentação exata depende do cliente.
Se a rejeição do Squid já contém o corpo deny_info pretendido, editar seu texto, folha de estilo ou permissões do arquivo não muda qual etapa da resposta o navegador trata. Mantenha o status da rejeição e o log de acesso disponíveis para estabelecer se o CONNECT foi negado e por quê. Uma página genérica do navegador pode ocultar detalhes da política enquanto o proxy aplica a regra corretamente.
Servir uma página de bloqueio dentro de uma conexão HTTPS interceptada é outra arquitetura, envolvendo terminação TLS, confiança do cliente e tratamento de certificados. Ela não é habilitada editando deny_info, e um modelo personalizado não confere autoridade para se passar pelo site bloqueado. Escolha esse design apenas se necessário; caso contrário, use os relatórios de erro disponíveis no cliente e os logs operacionais do proxy.