> ## Documentation Index > Fetch the complete documentation index at: https://docs.x.com/llms.txt > Use this file to discover all available pages before exploring further. # Lidando com desconexões > Aprenda a lidar com desconexões ao usar endpoints de streaming do X, incluindo Filtered Stream, Volume Streams, Powerstream e Compliance Streams. Aprenda a lidar com desconexões ao usar endpoints de streaming do X, incluindo [Filtered Stream](/x-api/posts/filtered-stream/introduction), [Volume Streams](/x-api/posts/volume-streams/introduction), [Powerstream](/x-api/powerstream/introduction) e [Compliance Streams](/x-api/compliance/streams/introduction). ## O que é uma desconexão? Estabelecer uma conexão com APIs de streaming significa fazer uma solicitação HTTPS muito longa e analisar a resposta de forma incremental. Ao conectar-se a um endpoint de streaming, você deve formar uma solicitação HTTPS e consumir o stream resultante o máximo possível. Os servidores do X manterão a conexão aberta indefinidamente, salvo: * Erros do lado do servidor * Atraso excessivo do lado do cliente * Problemas de rede * Manutenção rotineira do servidor * Logins duplicados Com conexões de streaming, desconexões **irão** ocorrer e devem ser esperadas. Sua aplicação deve incluir lógica de reconexão. *** ## Por que as conexões desconectam Possíveis motivos para desconexões: | Motivo | Descrição | | :----------------------- | :------------------------------------------------------------------------------------------------------------------- | | Erro de autenticação | Token errado ou método de autenticação incorreto | | Reinício do servidor | Deploy de código no lado do X — deve ser esperado e considerado no design | | Cliente muito lento | Seu cliente não está acompanhando o volume. A fila de mensagens no servidor cresce demais e a conexão é fechada | | Cota excedida | Sua conta excedeu a cota de Posts diária/mensal | | Muitas conexões | Você tem conexões redundantes ativas em excesso | | Parada súbita de leitura | A taxa de Posts sendo lidos cai repentinamente | | Problemas de rede | Problemas de conectividade entre servidor e cliente | | Manutenção do servidor | Problema temporário do servidor ou manutenção agendada (verifique a [página de status](https://api.twitterstat.us/)) | *** ## Erros comuns de desconexão ### Operational disconnect ```json theme={null} { "errors": [{ "title": "operational-disconnect", "disconnect_type": "UpstreamOperationalDisconnect", "detail": "This stream has been disconnected upstream for operational reasons.", "type": "https://api.x.com/2/problems/operational-disconnect" }] } ``` ### Too many connections ```json theme={null} { "title": "ConnectionException", "detail": "This stream is currently at the maximum allowed connection limit.", "connection_issue": "TooManyConnections", "type": "https://api.x.com/2/problems/streaming-connection" } ``` *** ## Detectando desconexões Os endpoints de streaming fornecem um heartbeat de keep-alive de 20 segundos (um caractere de nova linha). Use esse sinal para detectar desconexões: 1. Seu código deve detectar quando o conteúdo novo e o heartbeat param de chegar 2. Se nenhum dado for recebido por 20 segundos, acione a lógica de reconexão 3. Alguns clientes HTTP permitem especificar um read timeout — defina-o para 20 segundos *** ## Estratégia de reconexão Assim que uma conexão estabelecida cair, tente reconectar imediatamente. Se a reconexão falhar, use estratégias de backoff com base no tipo de erro: ### Erros de rede TCP/IP Use backoff **linear**. Esses problemas são geralmente temporários. * Aumente o atraso em 250ms a cada tentativa * Atraso máximo: 16 segundos ### Erros HTTP Use backoff **exponencial** para erros HTTP onde a reconexão é apropriada. * Comece com espera de 5 segundos * Dobre a cada tentativa * Atraso máximo: 320 segundos ### Erros de rate limit (HTTP 429) Use backoff **exponencial** com espera inicial maior. * Comece com espera de 1 minuto * Dobre a cada tentativa * Cada 429 recebido aumenta o tempo de espera até o rate limiting expirar *** ## Rate limits e uso As respostas de conexão de streaming retornam três cabeçalhos para ajudá-lo a entender os limites: | Cabeçalho | Descrição | | :----------------------- | :--------------------------------------------------------------- | | `x-rate-limit-limit` | Número de solicitações permitidas durante a janela de 15 minutos | | `x-rate-limit-remaining` | Solicitações feitas até agora na janela de 15 minutos | | `x-rate-limit-reset` | UNIX timestamp de quando a janela é redefinida | Para acompanhar quantos Posts foram entregues, implemente lógica de medição no lado do cliente para que o consumo possa ser medido e pausado se necessário. *** ## Boas práticas de reconexão ### Use uma arquitetura de fila FIFO Seu cliente de stream deve inserir os Posts recebidos em uma fila first-in, first-out (FIFO) ou estrutura de memória semelhante. Um processo/thread separado deve consumir Posts dessa fila para análise e armazenamento. Esse design escala eficientemente quando os volumes de Posts mudam drasticamente. ### Teste estratégias de backoff Teste sua implementação de backoff usando credenciais de autorização inválidas e examine as tentativas de reconexão. Uma boa implementação não receberá respostas 429. ### Emita alertas para múltiplas reconexões Se seu cliente atingir seu limite superior de tempo entre reconexões, envie notificações para que você possa investigar os problemas de conexão. ### Trate mudanças de DNS Certifique-se de que seu processo cliente honre o Time To Live (TTL) do DNS. Algumas stacks armazenam em cache os endereços resolvidos durante toda a duração do processo e não detectarão alterações de DNS dentro do TTL. Cache agressivo leva a interrupções de serviço à medida que o X redistribui a carga entre endereços IP. ### Defina o cabeçalho User-Agent Inclua a versão do seu cliente no cabeçalho HTTP `User-Agent`. Isso é crítico para diagnosticar problemas do lado do X. Se seu ambiente impedir a definição de `User-Agent`, use o cabeçalho `x-user-agent` em vez disso. *** ## Próximos passos Recupere dados perdidos após desconexões Construa clientes de streaming robustos Lidar com streams de alta taxa de transferência