Resposta rápida
Este guia conecta uma requisição real de teste do Telegram ao código local. Só pode ser publicado após teste em sandbox controlado, revisão das fontes oficiais atuais e definição de responsável pela manutenção.
Passo a passo
- Prepare sandbox ou conta de teste, tipo de evento, segredo e handler local mínimo.
- Inicie o handler e valide uma rota de health determinística.
- Instale/entre no Oxaa, execute
oxaa http <port>e aguarde a prontidão da borda. - Copie a URL HTTPS e o caminho exatos para a configuração atual do provedor.
- Dispare um evento real de teste.
- Confirme entrega do provedor, metadados no Oxaa e resposta do handler local.
- Valide raw body/assinatura, timestamp, retry e proxy confiável.
- Ative captura local limitada somente quando necessário; redija e exclua dados sensíveis.
- Use replay do Oxaa apenas para requisições elegíveis; peça nova entrega ao provedor quando a autenticidade depender de timestamp ou token novo.
- Remova callback, rotacione segredo, exclua capturas e leve produção ao endpoint implantado ou à plataforma de eventos.
Verificação específica do Telegram
Configure o webhook ou callback atual do Telegram com a URL e o caminho exatos do Oxaa. Dispare um evento real de teste e valide o registro de entrega do provedor, os metadados da requisição no Oxaa e a resposta do aplicativo local. O guia de produção deve validar setWebhook, secret token quando compatível e getWebhookInfo.
Como o tráfego e os dados do Inspector são tratados
A borda pública do Oxaa termina o TLS público para resolver o hostname exato, identificar a rota autenticada atual e encaminhar a requisição. A sessão entre o dispositivo cadastrado e o Oxaa é criptografada; por ela, a requisição chega somente ao serviço local selecionado.
O Oxaa mantém metadados limitados de conta, rota, uso, segurança, cobrança, suporte e diagnóstico necessários para operar e proteger o serviço. A captura de body no Inspector é uma ação de depuração separada e explícita: a cópia limitada do body da requisição ou da resposta exibida no Inspector local permanece no dispositivo do desenvolvedor e pode ser redigida, excluída imediatamente ou expirar automaticamente. O tráfego público ainda precisa ser processado na borda; portanto, a afirmação correta é “cópias locais no Inspector”, e não “o Oxaa não consegue ver o tráfego”.
Solução de problemas
Comece pelo processo local, porta e esquema. Depois verifique autenticação e relógio, DNS, UDP/443, fallback TCP/443, proxy corporativo ou interceptação TLS, propriedade da rota e prontidão da borda. Use oxaa routes list, oxaa diagnose --network e IDs de erro estáveis; revise e remova segredos, bodies e caminhos privados antes de compartilhar o diagnóstico.
Limpeza e passagem para produção
Remova o callback externo, a URL de preview ou o vínculo DNS; rotacione credenciais de teste; exclua capturas locais; pare a rota; e revogue o dispositivo ou a sessão quando necessário. Direcione o tráfego de produção para o aplicativo implantado, o ingress de produção ou a plataforma de entrega de eventos adequada.
O que o Oxaa é - e o que não é
O Oxaa fornece conectividade de desenvolvimento para um serviço HTTP ou HTTPS local selecionado enquanto o dispositivo cadastrado e a rota autenticada estão ativos. Não é hospedagem, VPN genérica, forward proxy, implantação permanente de produção, túnel raw TCP/UDP, passthrough TLS arbitrário, substituto de CDN/WAF nem plataforma de entrega de webhooks de produção.