DeepSeek não funciona? Fluxo avançado para Web, App e API

DeepSeek não funciona? Fluxo avançado para Web, App e API é um guia para diagnosticar o problema certo antes de tentar a solução errada. “DeepSeek não funciona” pode significar muitas coisas: o Web Chat não carrega, o aplicativo trava, o login falha, a resposta demora, aparece “server busy”, a API retorna erro, há timeout, o saldo acabou, o modelo está incorreto ou o payload JSON está inválido.

O primeiro passo é separar o problema em três superfícies diferentes: DeepSeek Web, DeepSeek App e DeepSeek API. Um erro no Web Chat não prova automaticamente que a API caiu. Um erro 401 na API não significa que o aplicativo oficial está com problema. E uma falha no aplicativo móvel pode ser local, de rede, de cache, de versão ou de sessão.

A DeepSeek mantém uma página oficial de status que separa componentes como API Service e Web Chat Service, o que ajuda a diferenciar incidente global de falha local. Como o status muda com o tempo, um conteúdo evergreen não deve afirmar que “o DeepSeek está fora do ar agora”; o correto é orientar o usuário a verificar o status oficial no momento do problema.

Resposta rápida

Quando o DeepSeek não funciona, identifique primeiro onde o erro aparece: Web, App ou API. Depois, verifique a página oficial de status, teste navegador, rede, cache e sessão, e só então revise a integração. Na API, confirme base_url, endpoint, Authorization: Bearer, chave, saldo, modelo, payload, timeout e streaming. Use retry com backoff apenas para erros transitórios, como 429, 500 e 503.

Diagnóstico em 5 minutos: por onde começar

Antes de limpar tudo, reinstalar aplicativo ou alterar código em produção, use uma triagem curta. O objetivo é descobrir se o problema é local, de conta, de rede, de status global ou de integração.

Sintoma	Onde acontece	Causa provável	Primeiro teste	Repetir a tentativa?
Página não carrega	Web	Cache, DNS, extensão, rede ou incidente no Web Chat	Abrir em janela anônima e verificar status oficial	Sim, após testar outra rede
Login falha	Web/App	Sessão expirada, cookies, conta errada, bloqueio ou problema temporário	Testar login em janela anônima ou outro dispositivo	Sim, mas sem insistência excessiva
Resposta demora muito	Web/API	Fila, prompt longo, non-streaming, carga alta ou timeout curto	Reduzir prompt e verificar status	Sim, com intervalo
“Server busy”	Web/App	Alta demanda, limitação temporária ou fila do serviço	Esperar alguns minutos e comparar com status oficial	Sim, depois de um intervalo
App fecha sozinho	App	Bug local, versão antiga, cache, memória ou sistema	Atualizar pela loja oficial e reiniciar o aparelho	Sim, após atualização
API retorna 401	API	Chave ausente, incorreta ou header errado	Conferir Authorization: Bearer e variável de ambiente	Não, corrija primeiro
API retorna 402	API	Saldo insuficiente	Verificar billing/top-up	Não, corrija saldo
API retorna 429	API	Muitas requisições ou limite dinâmico de concorrência	Reduzir ritmo e aplicar backoff	Sim, com backoff
API retorna 503	API	Servidor sobrecarregado	Verificar status e tentar novamente depois	Sim, com limite
JSON inválido	API	Payload malformado ou parsing incorreto	Validar JSON e schema	Não, corrija primeiro
Timeout	API/Web	Resposta longa, fila, rede, timeout curto ou streaming mal tratado	Aumentar timeout e reduzir prompt	Depende do status
Resposta vazia ou incompleta	API	finish_reason, limite de tokens, streaming interrompido ou parsing	Checar finish_reason, logs e max_tokens	Só após entender a causa

Os códigos oficiais de erro da DeepSeek API incluem 400, 401, 402, 422, 429, 500 e 503. A documentação descreve 401 como falha de autenticação por chave errada, 402 como saldo insuficiente, 429 como envio de requisições rápido demais, 500 como erro de servidor e 503 como sobrecarga do servidor.

Antes de mexer no código: Web, App ou API?

DeepSeek Web, DeepSeek App e DeepSeek API são canais diferentes. Eles podem usar infraestrutura relacionada, mas não devem ser tratados como a mesma coisa durante o diagnóstico.

Um problema no navegador pode estar ligado a cookies, extensão, bloqueador de scripts, DNS, proxy corporativo ou cache. Um problema no aplicativo pode estar ligado à versão instalada, permissões, rede móvel, economia de bateria ou dados corrompidos. Já uma falha na API pode vir de chave, saldo, endpoint, modelo, payload, rate limit, timeout, parsing de streaming ou logs insuficientes.

A própria página oficial da DeepSeek apresenta DeepSeek V4 como disponível em web, app e API, e também oferece caminhos separados para Chat, App, Platform, API Docs, API Pricing e Service Status.

O problema aparece onde?
├── Navegador/Web Chat → testar status, navegador, cache, extensão e rede
├── Aplicativo móvel → testar atualização, cache, permissões, rede e instalação oficial
└── API/integração → testar chave, saldo, endpoint, modelo, payload, rate limit e logs

Regra prática

Se o DeepSeek Web não responde, mas sua API continua retornando 200, provavelmente o problema não está na API. Se a API retorna 401, mas o Web Chat abre normalmente, provavelmente o problema está na autenticação da sua integração. Se o App trava, mas o Web Chat funciona no mesmo login, investigue dispositivo, versão, cache e rede.

Verifique o status oficial da DeepSeek

A página oficial de status deve ser o primeiro ponto quando houver suspeita de incidente global. Ela exibe o estado dos serviços e separa componentes como API Service e Web Chat Service, além de mostrar histórico de incidentes e manutenção.

Use esta checklist:

• O API Service está afetado?
• O Web Chat Service está afetado?
• O incidente começou no mesmo horário em que seu erro apareceu?
• Há histórico recente de incidentes resolvidos?
• O problema afeta todos os usuários ou apenas uma rede, conta ou dispositivo?
• Os logs da sua aplicação mostram aumento de 429, 500 ou 503?
• A falha começou depois de deploy, mudança de modelo ou troca de chave?

Se houver incidente ativo no componente certo, não adianta alterar código sem evidência. Em produção, a melhor resposta é reduzir retries agressivos, exibir uma mensagem amigável e usar fallback quando possível.

Exemplos de mensagens úteis:

“Estamos enfrentando instabilidade temporária na resposta da IA. Tente novamente em alguns minutos.”

“Não foi possível processar sua solicitação agora. Nenhum dado foi perdido.”

“A resposta está demorando mais do que o normal. Você pode tentar novamente ou reduzir o tamanho do texto.”

Fluxo para DeepSeek Web: quando o chat não carrega ou não responde

Quando o problema aparece no navegador, pense primeiro em ambiente local: navegador, cache, extensão, rede, sessão e bloqueios.

1. Teste uma janela anônima

A janela anônima ajuda a testar sem cookies antigos, extensões persistentes e dados de sessão corrompidos. Se funcionar no modo anônimo, o problema provavelmente está no perfil do navegador, não necessariamente no DeepSeek.

2. Troque de navegador

Teste Chrome, Edge, Firefox ou Safari. Se só falha em um navegador, investigue extensões, bloqueadores de script, service workers, cache e configurações de privacidade.

3. Limpe cookies e cache apenas do domínio

Evite limpar todos os dados do navegador sem necessidade. Comece pelos dados do site relacionado ao DeepSeek. Isso preserva sessões de outros serviços e reduz efeitos colaterais.

4. Desative extensões temporariamente

Bloqueadores de anúncios, extensões de privacidade, antivírus no navegador, tradutores automáticos e ferramentas corporativas podem bloquear scripts, cookies ou requisições. Se o DeepSeek Web não carrega, teste com extensões desativadas.

5. Teste outra rede

Compare Wi-Fi, dados móveis, hotspot e rede corporativa. Se funciona fora da rede da empresa, investigue firewall, DNS, proxy, SSL inspection ou bloqueios de domínio.

6. Reduza prompts muito longos

Se a página abre, mas a resposta não vem, envie um prompt curto. Um texto enorme pode aumentar latência, custo computacional e chance de timeout.

7. Use o console do navegador com cuidado

Usuários técnicos podem abrir DevTools e observar mensagens como network failed, scripts bloqueados, erro de CORS, falha de service worker ou recursos bloqueados por extensão. Não compartilhe prints públicos contendo cookies, tokens, e-mails ou dados pessoais.

Fluxo para DeepSeek App: quando o aplicativo trava, fecha ou não abre

No aplicativo móvel, a causa pode ser diferente do Web Chat. O app pode falhar por versão antiga, cache local, permissões, rede, economia de bateria, incompatibilidade temporária ou problema de sessão.

A página oficial da DeepSeek aponta um link para o DeepSeek App, e a página do Google Play lista o aplicativo “DeepSeek – AI Assistant” publicado por DeepSeek. Use canais oficiais para instalação e atualização; evite APKs aleatórios ou links enviados por terceiros.

Checklist para o App

• Confirme se o app veio de canal oficial.
• Atualize pela loja oficial.
• Feche e abra novamente.
• Reinicie o aparelho.
• Teste Wi-Fi e dados móveis.
• Verifique permissões de rede e armazenamento, quando aplicável.
• Desative temporariamente economia de bateria ou economia de dados.
• Limpe cache do aplicativo, se o sistema permitir.
• Reinstale apenas como último passo.
• Anote versão do app, sistema, região, horário e rede.

Quando usar o Web Chat como comparação temporária

Se o DeepSeek App não abre, teste o Web Chat no navegador do mesmo aparelho e em outro dispositivo. Se o Web Chat funciona e o app não, o problema pode estar na instalação, cache, versão ou sistema. Se ambos falham na mesma rede, investigue conexão, DNS, firewall, VPN, proxy ou status oficial.

Login, conta e sessão: quando o problema parece acesso bloqueado

Falhas de login não são sempre “DeepSeek caiu”. Elas podem acontecer por sessão expirada, cookies corrompidos, conta errada, fluxo de login incompleto, rede bloqueando scripts, e-mail não aceito no cadastro, telefone não confirmado, restrição de conta ou instabilidade temporária.

A FAQ oficial da DeepSeek informa, por exemplo, que uma mensagem de suspensão temporária durante o login indica que a conta acionou protocolos de suspensão por possível violação das diretrizes da plataforma. A mesma FAQ também menciona que alguns domínios de e-mail podem não ser aceitos para registro e recomenda provedores internacionais conhecidos quando esse erro aparece.

Checklist de conta:

• Teste login em janela anônima.
• Teste outro navegador.
• Teste outro dispositivo.
• Confirme se está no canal oficial.
• Limpe dados do site se a sessão parecer corrompida.
• Verifique se está usando a conta correta.
• Não envie senha, código ou token para terceiros.
• Contate suporte oficial se o problema persistir e houver mensagem de conta.

Fluxo para DeepSeek API: quando a integração quebra

Na API, a maioria dos erros vem de configuração, autenticação, saldo, payload ou comportamento de rede. O modelo raramente é a primeira causa a investigar.

A documentação oficial diz que a DeepSeek API usa formato compatível com OpenAI/Anthropic; para o formato OpenAI, o base_url é https://api.deepseek.com, e os modelos listados para novas chamadas são deepseek-v4-flash e deepseek-v4-pro. A mesma página mostra exemplos com Authorization: Bearer ${DEEPSEEK_API_KEY} e endpoint /chat/completions.

Checklist obrigatório:

• base_url correto: https://api.deepseek.com
• endpoint correto: /chat/completions
• header correto: Authorization: Bearer SUA_API_KEY
• modelo válido: deepseek-v4-flash ou deepseek-v4-pro
• messages no formato correto
• JSON válido
• saldo disponível
• timeout adequado
• parsing correto para streaming ou non-streaming
• logs sem API key
• chave protegida no backend, nunca no frontend
• retry somente em erros transitórios

O endpoint /chat/completions cria uma resposta do modelo para uma conversa de chat, e o corpo exige messages e model; a referência atual lista deepseek-v4-flash e deepseek-v4-pro como valores possíveis para model.

Requisição mínima correta com cURL

Use uma chamada mínima para isolar problema de autenticação, saldo, endpoint, modelo e JSON.

curl https://api.deepseek.com/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer ${DEEPSEEK_API_KEY}" \
  -d '{
    "model": "deepseek-v4-flash",
    "messages": [
      {
        "role": "system",
        "content": "Você é um assistente útil e objetivo."
      },
      {
        "role": "user",
        "content": "Responda em uma frase: o que devo testar quando a API falha?"
      }
    ],
    "thinking": {
      "type": "disabled"
    },
    "stream": false
  }'

Não cole chave real em artigo, print, ticket, GitHub, fórum, issue pública ou mensagem de suporte sem mascarar.

Se esse teste falha, o problema provavelmente está em autenticação, saldo, status, endpoint, modelo ou formato do JSON. Se esse teste funciona, mas sua aplicação falha, o problema provavelmente está na integração, payload, timeout, streaming, proxy, CORS, backend ou parsing.

Exemplo mínimo em Node.js para diagnosticar a API

Este teste usa o SDK compatível com OpenAI, variável de ambiente e log seguro. A documentação oficial mostra uso do SDK da OpenAI com baseURL: 'https://api.deepseek.com' e apiKey: process.env.DEEPSEEK_API_KEY.

// npm install openai dotenv
import OpenAI from "openai";
import "dotenv/config";

const apiKey = process.env.DEEPSEEK_API_KEY;

if (!apiKey) {
  console.error("DEEPSEEK_API_KEY não foi definida.");
  process.exit(1);
}

const client = new OpenAI({
  apiKey,
  baseURL: "https://api.deepseek.com"
});

async function main() {
  try {
    const startedAt = Date.now();

    const response = await client.chat.completions.create({
      model: "deepseek-v4-flash",
      messages: [
        {
          role: "system",
          content: "Você é um assistente objetivo."
        },
        {
          role: "user",
          content: "Diga apenas: API funcionando."
        }
      ],
      stream: false,
      thinking: {
        type: "disabled"
      },
      max_tokens: 50
    });

    const elapsedMs = Date.now() - startedAt;

    console.log("Status: sucesso");
    console.log("Latência total:", elapsedMs, "ms");
    console.log("Modelo:", response.model);
    console.log("Resposta:", response.choices?.[0]?.message?.content);
    console.log("Uso:", response.usage);
  } catch (error) {
    console.error("Status:", error.status || "desconhecido");
    console.error("Tipo:", error.name || "erro");
    console.error("Mensagem:", error.message);

    // Nunca registre process.env.DEEPSEEK_API_KEY.
  }
}

main();

Se esse script funciona localmente, mas falha no servidor, compare variáveis de ambiente, firewall, proxy, versão do Node.js, deploy, permissões de saída e secret manager.

Exemplo mínimo em Python para isolar o problema

# pip install openai
import os
from openai import OpenAI

api_key = os.environ.get("DEEPSEEK_API_KEY")

if not api_key:
    raise RuntimeError("DEEPSEEK_API_KEY não foi definida.")

client = OpenAI(
    api_key=api_key,
    base_url="https://api.deepseek.com"
)

try:
    response = client.chat.completions.create(
        model="deepseek-v4-flash",
        messages=[
            {
                "role": "system",
                "content": "Você é um assistente objetivo."
            },
            {
                "role": "user",
                "content": "Diga apenas: API funcionando."
            }
        ],
        stream=False,
        max_tokens=50,
        extra_body={
            "thinking": {
                "type": "disabled"
            }
        }
    )

    print(response.choices[0].message.content)
    print(response.usage)

except Exception as error:
    print("Erro ao chamar DeepSeek API:")
    print(type(error).__name__)
    print(str(error))

Se Python e cURL funcionam, mas sua aplicação não, o problema tende a estar no código da aplicação, serialização do payload, timeout, ambiente de execução ou tratamento da resposta.

Modelos V4 e aliases legados: erro por ID de modelo incorreto

Não trate nomes de modelos como endpoints. O endpoint é /chat/completions; o modelo vai no campo model.

A documentação oficial lista deepseek-v4-flash e deepseek-v4-pro como modelos atuais e informa que deepseek-chat e deepseek-reasoner serão descontinuados em 24 de julho de 2026. Para compatibilidade, esses nomes legados correspondem, respectivamente, ao modo non-thinking e thinking do deepseek-v4-flash.

Nome	Status recomendado	Melhor uso	Observação
deepseek-v4-flash	Recomendado para novas integrações	Testes, suporte, FAQ, respostas rápidas, troubleshooting	Melhor ponto de partida
deepseek-v4-pro	Recomendado para novas integrações complexas	Análise técnica, agentes, raciocínio, tarefas complexas	Mais indicado quando qualidade pesa mais
deepseek-chat	Legado/alias	Projetos antigos	Não use como recomendação principal em projetos novos
deepseek-reasoner	Legado/alias	Projetos antigos com raciocínio	Planeje migração

A página de modelos e preços também informa que os modelos V4 têm contexto de 1M, suportam thinking e non-thinking, e incluem recursos como JSON Output, Tool Calls, Chat Prefix Completion beta e FIM Completion beta em modo non-thinking.

Tabela completa de erros da DeepSeek API

A tabela abaixo combina os códigos oficiais da DeepSeek com decisões práticas para aplicação em produção.

Código	Significado	Causa provável	O que corrigir	Retry automático?	Mensagem amigável
400	Invalid Format	Corpo da requisição inválido	Corrigir JSON, schema, messages ou headers	Não	“A solicitação está em formato inválido.”
401	Authentication Fails	API key errada, ausente ou mal enviada	Revisar chave, variável de ambiente e Authorization: Bearer	Não	“Falha de autenticação no serviço de IA.”
402	Insufficient Balance	Saldo insuficiente	Verificar billing e adicionar fundos	Não	“Serviço temporariamente indisponível por configuração de conta.”
422	Invalid Parameters	Parâmetro incompatível ou inválido	Corrigir modelo, campos, tipos e parâmetros	Não	“A solicitação contém parâmetros inválidos.”
429	Rate Limit Reached	Requisições rápidas demais ou limite dinâmico	Reduzir concorrência, aplicar fila e backoff	Sim, com limite	“Muitas solicitações ao mesmo tempo. Tente novamente em instantes.”
500	Server Error	Erro interno do servidor	Retry breve, fallback e monitoramento	Sim, com limite	“O serviço de IA encontrou uma falha temporária.”
503	Server Overloaded	Servidor sobrecarregado	Retry breve, backoff e fallback	Sim, com limite	“O serviço está sobrecarregado no momento.”

Regra prática: 400, 401, 402 e 422 geralmente exigem correção do seu lado. Fazer retry cego nesses casos só aumenta ruído. 429, 500 e 503 podem aceitar retry com backoff, mas sempre com limite de tentativas.

Rate limit, concorrência e erro 429

Erro 429 DeepSeek geralmente significa que sua aplicação precisa reduzir o ritmo. A documentação oficial informa que a DeepSeek API limita dinamicamente a concorrência do usuário com base na carga do servidor; quando o limite de concorrência é atingido, a API retorna HTTP 429 imediatamente.

A FAQ oficial também informa que o rate limit exposto por conta é ajustado dinamicamente de acordo com a pressão de tráfego em tempo real e o histórico recente de uso da conta, e que a DeepSeek temporariamente não oferece aumento individual desse limite dinâmico.

Use:

• fila de requisições;
• limite por usuário;
• limite por IP;
• limite por organização;
• backoff exponencial;
• circuit breaker;
• timeout controlado;
• monitoramento de taxa de erro;
• fallback temporário.

Não tente resolver 429 com retry agressivo. Isso piora a situação, aumenta a latência e pode multiplicar falhas.

const retryableStatus = new Set([429, 500, 503]);

async function withBackoff(fn, maxAttempts = 3) {
  let lastError;

  for (let attempt = 0; attempt < maxAttempts; attempt++) {
    try {
      return await fn();
    } catch (error) {
      lastError = error;

      if (!retryableStatus.has(error.status)) {
        throw error;
      }

      const delayMs = 500 * Math.pow(2, attempt);
      await new Promise((resolve) => setTimeout(resolve, delayMs));
    }
  }

  throw lastError;
}

Esse código é apenas uma base. Em produção, adicione jitter aleatório, cancelamento, métricas, logs seguros e regras por tipo de usuário.

Quando a API parece travada, mas não está quebrada

Às vezes, a API parece travada porque a aplicação está esperando a resposta completa. A FAQ oficial explica que o Web Chat usa streaming e mostra tokens incrementalmente, enquanto a API usa non-streaming por padrão (stream=false), retornando a saída apenas quando a geração termina. A própria FAQ recomenda streaming na API para melhorar a interatividade.

Outro ponto importante: a documentação de rate limit informa que, enquanto a requisição aguarda processamento, a conexão pode permanecer aberta. Em non-streaming, a API pode retornar linhas vazias; em streaming, pode retornar comentários SSE : keep-alive. Se a inferência não começar após 10 minutos, o servidor fecha a conexão.

Checklist:

• Reduzir prompt.
• Limitar max_tokens.
• Usar stream: true quando fizer sentido.
• Ajustar timeout.
• Tratar empty lines em non-streaming.
• Tratar : keep-alive em streaming.
• Dividir tarefas longas.
• Registrar tempo até primeiro token.
• Verificar finish_reason.
• Medir latência por modelo.

A referência de chat completion informa que stream envia deltas parciais por Server-Sent Events e termina com data: [DONE].

Streaming: problema de experiência ou problema real?

Streaming não necessariamente torna o processamento total muito menor, mas melhora a percepção do usuário porque a resposta começa a aparecer antes.

Use stream: false quando:

• a resposta é curta;
• o fluxo é simples;
• você quer implementar o MVP rapidamente;
• precisa da resposta completa antes de processar.

Use stream: true quando:

• as respostas são longas;
• o chat precisa parecer responsivo;
• você quer medir tempo até primeiro token;
• a experiência do usuário é prioridade.

Cuidados com streaming:

• parsear SSE corretamente;
• lidar com data: [DONE];
• ignorar keep-alive;
• reconstruir deltas na ordem correta;
• tratar resposta interrompida;
• informar progresso ao usuário;
• registrar se houve cancelamento pelo cliente.

Se o Web Chat parece rápido e sua API parece lenta, não conclua automaticamente que “a API está pior”. Talvez seu app esteja usando non-streaming e só mostrando a resposta no final.

JSON inválido, resposta vazia ou requisição “presa”

Se você usa JSON Output, verifique o prompt. A referência oficial informa que response_format: { "type": "json_object" } habilita JSON Output, mas também alerta que o modelo deve ser instruído a produzir JSON por mensagem de sistema ou usuário; sem isso, pode gerar espaços em branco até o limite de tokens, parecendo uma requisição presa.

Exemplo de instrução correta:

const response = await client.chat.completions.create({
  model: "deepseek-v4-flash",
  messages: [
    {
      role: "system",
      content:
        "Responda sempre em JSON válido no formato: {\"status\":\"ok|erro\",\"resumo\":\"string\"}"
    },
    {
      role: "user",
      content: "Analise este erro: timeout ao chamar a API."
    }
  ],
  response_format: {
    type: "json_object"
  },
  max_tokens: 300,
  thinking: {
    type: "disabled"
  }
});

Sempre valide o JSON no backend. Nunca assuma que uma resposta estruturada pode ser enviada diretamente para banco, fila, CRM ou função interna sem validação.

Observabilidade para aplicações em produção

Troubleshooting sem logs é adivinhação. Mas logs ruins podem expor dados sensíveis. O objetivo é registrar o suficiente para diagnosticar sem vazar chaves, prompts privados ou informações pessoais.

A referência da API mostra que a resposta pode incluir estatísticas de uso como prompt_tokens, completion_tokens, prompt_cache_hit_tokens, prompt_cache_miss_tokens, total_tokens e reasoning_tokens, úteis para monitorar custo, latência e comportamento.

Métrica/log	Por que registrar	O que não registrar
Status code	Identificar padrões de 401, 402, 429, 500 e 503	API key
Endpoint	Confirmar rota usada	Headers completos
Modelo	Comparar falhas por deepseek-v4-flash ou deepseek-v4-pro	Dados sensíveis do usuário
Streaming/non-streaming	Diagnosticar percepção de lentidão	Conteúdo completo sem necessidade
Latência total	Medir degradação	Tokens secretos
Tempo até primeiro token	Avaliar experiência com streaming	Prompt confidencial
Tokens de entrada/saída	Monitorar custo	Documentos privados
Tentativas de retry	Detectar loops e overload	Chaves ou cookies
Usuário anonimizado	Medir impacto por conta	E-mail em texto claro
finish_reason	Entender resposta cortada, tool calls ou falta de recurso	Logs de raciocínio sensível

A referência oficial também lista finish_reason como stop, length, content_filter, tool_calls ou insufficient_system_resource. Esse campo ajuda a diferenciar resposta concluída, resposta cortada por limite, chamada de ferramenta ou interrupção por recurso insuficiente.

Plano de resposta a incidentes

Para equipes, use um fluxo simples e repetível.

1. Confirmar se é local ou global
   Compare usuários, regiões, redes, dispositivos e ambientes.
2. Verificar status oficial
   Confirme se API Service ou Web Chat Service estão afetados.
3. Separar Web, App e API
   Não misture sintomas de canais diferentes.
4. Medir impacto
   Quantos usuários foram afetados? Qual rota? Qual modelo? Qual status code?
5. Pausar retries agressivos
   Retry mal configurado pode amplificar o incidente.
6. Ativar mensagem amigável
   Informe instabilidade sem expor detalhes técnicos.
7. Usar fallback se necessário
   Pode ser fila assíncrona, modo degradado, modelo alternativo ou resposta temporária.
8. Registrar horário, status code e ambiente
   Esses dados ajudam a correlacionar com incidentes externos e deploys internos.
9. Revisar depois do incidente
   Ajuste timeout, backoff, filas, logs e alertas.

Mensagens para usuário final:

“Estamos enfrentando instabilidade temporária na resposta da IA. Tente novamente em alguns minutos.”

“Não foi possível processar sua solicitação agora. Nenhum dado foi perdido.”

“Sua solicitação é muito longa. Reduza o texto ou divida em partes.”

“O serviço está com alta demanda. Vamos tentar novamente automaticamente.”

Segurança e privacidade durante o debug

Durante incidentes, é comum alguém colar logs em chats, tickets, planilhas ou issues públicas. Esse é um dos momentos de maior risco.

Boas práticas:

• nunca cole API key em logs;
• nunca envie header Authorization completo;
• mascare tokens, e-mails, IDs e dados pessoais;
• não envie documentos confidenciais em testes;
• não compartilhe prints com cookies ou chaves;
• use ambientes separados de produção e teste;
• restrinja acesso a logs;
• use secret manager quando possível;
• registre prompts completos apenas quando houver base, necessidade e proteção adequadas;
• evite transformar troubleshooting técnico em aconselhamento jurídico sobre LGPD.

A página do Google Play informa que o app DeepSeek pode coletar tipos de dados como localização, informações pessoais e outros, além de indicar criptografia em trânsito e opção de solicitação de exclusão; isso reforça a importância de evitar envio desnecessário de dados sensíveis durante testes.

O que não concluir errado

Evite conclusões apressadas:

• não conclua que App e API estão fora do ar ao mesmo tempo sem evidência;
• não use falha do Web Chat como prova de falha da API;
• não use erro 401 como evidência de instabilidade global;
• não faça retry em 402 esperando resolver saldo;
• não chame deepseek-chat e deepseek-reasoner de endpoints;
• não trate /v1 como versão do modelo;
• não instale apps não oficiais;
• não exponha dados sensíveis;
• não use VPN para burlar restrições legais ou políticas;
• não aumente retry agressivamente em 429;
• não publique API key em repositório;
• não prometa solução garantida.

Checklist final: DeepSeek voltou a funcionar?

Web

• Página abre em janela anônima.
• Outro navegador funciona.
• Cache/cookies do domínio foram limpos.
• Extensões foram testadas.
• Outra rede foi testada.
• Status oficial não indica incidente no Web Chat.
• Prompt curto recebe resposta.

App

• App instalado por canal oficial.
• App atualizado.
• Aparelho reiniciado.
• Wi-Fi e dados móveis testados.
• Cache limpo, se possível.
• Permissões verificadas.
• Economia de bateria/dados revisada.
• Web Chat funciona como comparação.

API

• cURL mínimo funciona.
• base_url é https://api.deepseek.com.
• endpoint é /chat/completions.
• header usa Authorization: Bearer.
• chave está correta e ativa.
• saldo foi verificado.
• modelo é deepseek-v4-flash ou deepseek-v4-pro.
• JSON é válido.
• messages está no formato correto.
• timeout foi ajustado.
• streaming é parseado corretamente.
• retry com backoff foi limitado.
• logs não expõem chave.

Produção

• Alertas por taxa de erro configurados.
• Métricas de latência acompanhadas.
• Uso de tokens monitorado.
• Circuit breaker implementado.
• Fallback definido.
• Mensagem amigável configurada.
• Logs anonimizados.
• Runbook de incidente documentado.
• Chaves em secret manager.
• Testes pós-incidente realizados.

Conclusão

“DeepSeek não funciona” não tem causa única. Pode ser incidente no Web Chat, problema local no navegador, app desatualizado, sessão corrompida, rede corporativa, chave de API errada, saldo insuficiente, payload inválido, rate limit, timeout, streaming mal tratado ou sobrecarga temporária.

O diagnóstico correto começa separando Web, App e API. Para usuários comuns, comece por status oficial, navegador, cache, rede, app e login. Para desenvolvedores, revise chave, saldo, endpoint, modelo, payload, rate limit, timeout, streaming e logs. Para produção, use observabilidade, retry com backoff, fila, fallback e mensagens claras.

O melhor troubleshooting não é tentar tudo ao mesmo tempo. É seguir um fluxo, isolar a causa e aplicar a correção certa.

FAQ