Acelerando SSH com os domínios otimizados da Cloudflare: um post-mortem que, quanto mais eu corrigia, mais virava um suspense

Geral
1

Grandes momentos de comportamento irritante ao “acelerar” SSH: como transformamos “dá pra conectar” em “finalmente conecta de forma estável”

Vamos direto à conclusão, pra você não fechar a página no meio:

  • Este conjunto de soluções melhora a “estabilidade”, mas não necessariamente reduz de forma significativa o “número de latência”.
  • Cloudflare grátis + wstunnel pode salvar a vida, mas não vai virar uma linha dedicada do nada.
  • O maior ganho é: da próxima vez que aparecer um problema parecido, você sabe em qual camada checar primeiro, sem depender de “misticismo”.

Capítulo 1: 300ms não é assustador; assustador é “travar como um PPT”

A história começa bem simples:

  • China para Singapura, ping 300ms.
  • O site do negócio parece usável, porque tem proxy reverso do CF e domínio otimizado.
  • Mas basta digitar no SSH e você entra na fase da vida de “você fala e eu dou uma segurada antes de te responder”.

Aí vem a pergunta da alma:

“Se HTTP dá pra acelerar, será que SSH também consegue pegar carona?”

Resposta: dá, mas você precisa aceitar que não é “mágica de um clique”, e sim um quebra‑cabeça de múltiplas camadas.

Capítulo 2: a gente achou que era a rede, mas era configuração brigando entre si

O ponto mais com cara de suspense dessa vez foi:

  • ssh.cafe.de5.net parece passar.
  • ssh.aiya.de5.net com certificado também active.
  • Mas o cliente dá todo tipo de connection closed by foreign host、Connection refused.

Depois de localizar, descobrimos:

  • O Cloudflare SaaS com host personalizado traz o próprio Host no origin (back-to-origin).
  • Quando o server_name do Nginx não inclui ssh.aiya.de5.net, ele cai no site errado.
  • E aí o que você vê não é “erro claro”, e sim “nada parece fazer sentido”.

Em uma frase:

Não está caído; é só que cada camada está “quase certa”.

Capítulo 3: o 400 no navegador na verdade é uma boa notícia

Muita gente se assusta na primeira vez:

Ao acessar https://ssh.xxx e ver Invalid protocol request ou 400, acha que explodiu.

Mas nessa arquitetura, muitas vezes isso é bom:

  • Significa que a requisição já chegou no backend do wstunnel.
  • Só que você usou o navegador pra enviar HTTP, não o fluxo de protocolo do SSH-over-WS.

Ou seja:

  • 400 pode significar “o caminho está ok, mas o protocolo está errado”;
  • 404 é mais “nem chegou no backend que você esperava”.

Capítulo 4: o cliente é a última milha (e também a milha mais fácil de dar ruim)

Mesmo com o servidor todo configurado, o cliente ainda pode falhar:

  • Você acha que está conectando no domínio acelerado, mas na prática o FinalShell está conectando em 127.0.0.1:10022 — só que o túnel local não subiu.
  • A versão/parâmetros do wstunnel não batem, um -v e já aparece unexpected argument.
  • No log do SSH aparece kex_exchange_identification: Connection closed — no fundo, é o túnel que não foi estabelecido de forma estável.

No fim, o jeito correto é bem simples:

  1. Primeiro rode localmente wstunnel client, fazendo o 10022 local ficar em escuta.
  2. Depois faça o FinalShell/terminal conectar em 127.0.0.1:10022.
  3. Se não conectar, primeiro verifique “a porta local está em escuta?”, não comece suspeitando da vida.

Capítulo 5: então afinal isso “acelera” mesmo?

Vale falar disso separado.

Na maioria dos casos você vai obter:

  • Número de latência: muda pouco (ou fica parecido)
  • Estabilidade percebida: melhora bem (não cai do nada, não dá chilique)

Por quê?

  • CF grátis não é Argo dedicado, não vai apagar a distância física com magia.
  • Mas ele muitas vezes consegue transformar “jitter de rota ruim” em algo mais controlável.

Então esse conjunto de soluções parece mais:

colocar um “gimbal anti-trepidação” no SSH, não trocar por um “motor de velocidade da luz”.

Checklist anti-armadilhas pra quem vier depois (versão concentrada)

  1. Primeiro confirme o modelo do caminho: você está usando wstunnel ou cloudflared tunnel — não misture os conceitos.
  2. Em host personalizado do SaaS, confira custom_origin_server e o Host de origin combinando.
  3. O server_name do Nginx precisa cobrir o hostname do SaaS, senão vai cair no site errado.
  4. Abrir o domínio do SSH no navegador e voltar 400 não é necessariamente ruim.
  5. No cliente, olhe primeiro a escuta da porta local, depois os logs do SSH.
  6. Defina como objetivo “estabilidade”, não fique obcecado com “a latência tem que cair”.

Uma última frase (pra você que virou a noite ajustando rede)

O maior valor dessa brincadeira não foi “algum comando finalmente deu certo”, e sim você ter desmontado uma cadeia complexa em módulos verificáveis:

  • DNS
  • Host SaaS
  • Origin
  • Túnel
  • Cliente

Quando você consegue depurar por camadas, o tal “problema de rede místico” vira “problema de engenharia comum”.

Parabéns: de ser torturado pela rede, você evoluiu para torturar a rede.

1 Curtiu