Tentando usar o Claude Code em uma máquina corporativa ou via VPN, e ele não conecta com erros como estes?

# O que aparece agora (exemplos)
Can't reach the API server — check your internet or DNS (ENOTFOUND)
Connection refused — a firewall or proxy may be blocking it (ConnectionRefused)
Unable to connect to API. Check your internet connection
Unable to connect to Anthropic services
fetch failed

# O que as versões anteriores mostravam
Unable to connect to API (ECONNREFUSED)
Unable to connect to API: SSL certificate verification failed.
  Check your proxy or corporate SSL certificates

O texto depende da versão. Desde a v2.1.227, as mensagens que antes só acrescentavam um código, como Unable to connect to API (ECONNREFUSED), passaram a começar pelo tipo de falha, como Connection refused — ou Can't reach the API server — (tabela de correspondência na §2). Seja qual for o texto, o que está acontecendo e como corrigir são a mesma coisa.

Esses são erros de rede que significam "o Claude Code não consegue alcançar o servidor da Anthropic (api.anthropic.com)." Eles não são de autenticação (401/403), não são sobrecarga do servidor (529/500) e não são limite de taxa (429) — a requisição nunca chegou ao servidor. As causas habituais são proxies corporativos, inspeção de TLS (certificados) e firewalls, o que torna isso especialmente comum em redes corporativas. Este artigo cobre a configuração de proxy, os certificados de CA corporativa, os domínios a liberar e os passos de diagnóstico — com base em informações oficiais.

Os pontos-chave de antemão. (1) Atrás de um proxy, defina HTTPS_PROXY. (2) Para um erro de certificado causado por inspeção de TLS (Zscaler, etc.), aponte NODE_EXTRA_CA_CERTS para a CA corporativa — e nunca desative a verificação com NODE_TLS_REJECT_UNAUTHORIZED=0 (isso expõe todo o tráfego à interceptação). (3) Comece executando curl -I https://api.anthropic.com para checar "ele consegue ao menos alcançar?" — essa é a raiz da triagem.

CLAUDE CODE · NETWORK / PROXY

Ele nunca chega ao servidor

— onde ele para é o que decide a solução

Claude Code
requisição
→✗
Proxy / TLS / Firewall
muitas vezes bloqueado aqui
→
api.anthropic.com
Proxy
HTTPS_PROXY
Cert. TLS
NODE_EXTRA_CA_CERTS
Firewall
api.anthropic.com etc.

Primeiro execute curl -I https://api.anthropic.com para checar se ele consegue alcançar.
Quando você souber onde ele para (proxy / TLS / firewall), a configuração a aplicar fica decidida.

1. O que esse erro está te dizendo

Unable to connect to API, fetch failed, ECONNREFUSED / ETIMEDOUT (desde a v2.1.227, com textos como Connection refused —; veja a §2) significam "a requisição não chegou ao servidor da Anthropic" = ela falhou em algum ponto do TCP/TLS/DNS. Essa é a diferença decisiva em relação a outros erros: autenticação (401/403), servidor (529/500) e taxa (429) são respostas depois de alcançar o servidor, ao passo que erros de rede significam que ela nunca chegou lá.

Em redes corporativas, os bloqueios típicos se dividem em três camadas. (1) Proxy — você não pode sair diretamente e precisa rotear por um proxy corporativo que não está configurado. (2) Inspeção de TLS (certificados) — um proxy de inspeção como o Zscaler substitui os certificados, então você precisa confiar na CA raiz corporativa. (3) Firewall — os domínios necessários não estão liberados. A primeira coisa a fazer é confirmar "ele consegue alcançar?" com curl -I https://api.anthropic.com — essa única checagem separa "um problema de rede" de "todo o resto."

3 LAYERS

Onde ele para = qual configuração aplicar

1) Proxy não definido
ECONNREFUSED/ETIMEDOUT/fetch failed. Você precisa rotear pelo proxy corporativo → defina HTTPS_PROXY.
2) Erro de cert. por inspeção de TLS
SSL certificate verification failed/self-signed → coloque a CA corporativa em NODE_EXTRA_CA_CERTS. Nunca desative a verificação.
3) Domínio bloqueado pelo firewall
Domínios necessários não liberados → libere api.anthropic.com etc. (§5).
4) DNS / VPN / ferramentas locais
Could not resolve host/ENOTFOUND. DNS fora do ar, VPN com resíduos, ou Docker interceptando o tráfego.

Se curl -I https://api.anthropic.com tiver sucesso, o problema se restringe ao espaço entre o Claude Code e a rede.

2. O que cada mensagem significa (textos desde a v2.1.227)

Segundo a referência oficial de erros, as mensagens desta família indicam que a conexão TCP com a API falhou ou não chegou a se completar. Para os códigos de erro mais comuns, a mensagem descreve o tipo de falha e mantém o código entre parênteses. É isto que aparece agora:

Unable to connect to API. Check your internet connection
Connection refused — a firewall or proxy may be blocking it (ConnectionRefused)
Can't reach the API server — check your internet or DNS (ENOTFOUND)
No internet route — check your connection or VPN (EHOSTUNREACH)
Couldn't connect through your proxy (ERR_PROXY_TUNNEL) — the proxy refused the tunnel: check its credentials and that it allows this host
Connection dropped (ECONNRESET)
fetch failed
Request timed out. Check your internet connection and proxy settings

Antes da v2.1.227, todas essas mensagens com código diziam Unable to connect to API seguido do código (por exemplo, Unable to connect to API (ECONNREFUSED)). Códigos que o Claude Code não reconhece continuam aparecendo assim. Além disso, a mesma mensagem pode trazer códigos diferentes: Connection refused pode mostrar ConnectionRefused ou ECONNREFUSED, e Can't reach the API server pode mostrar ENOTFOUND ou FailedToOpenSocket.

A mensagem começa comO que a mensagem indicaO que verificar primeiro
Connection refused —A conexão foi recusada; um firewall ou proxy pode estar bloqueandoA lista de liberação (§5) e o HTTPS_PROXY (§3)
Can't reach the API server —O servidor da API não é alcançado; suspeite da conexão com a internet ou do DNSO DNS e a VPN; no WSL, o /etc/resolv.conf (§6)
No internet route —Não há rota até o destinoO estado da sua linha e da conexão VPN
Couldn't connect through your proxyO proxy recusou o túnelAs credenciais do proxy e se ele libera o host de destino
Connection droppedA conexão foi redefinida (ECONNRESET)A estabilidade do proxy e da rede

Seja qual for a mensagem, as falhas temporárias são repetidas automaticamente, então, quando ela aparece na tela, as novas tentativas já se esgotaram. Se ela volta a aparecer, a causa está na sua rede local. A referência oficial cita como causas comuns a falta de acesso à internet, uma VPN que bloqueia api.anthropic.com ou um proxy corporativo obrigatório que não foi configurado. As correções estão nas §3–§6.

Unable to connect to Anthropic services (configuração inicial)

Na configuração da primeira execução, antes de mostrar a etapa de login, o Claude Code verifica se consegue alcançar api.anthropic.com e platform.claude.com. Se alguma das verificações falhar, ele mostra o motivo e encerra. O exemplo oficial:

Unable to connect to Anthropic services
Failed to connect to api.anthropic.com: ECONNREFUSED
Connection to api.anthropic.com timed out after 10 seconds
A proxy is configured via HTTPS_PROXY. Check that it allows connections to the host above.

A verificação passa pela mesma configuração de proxy das requisições à API e dá 10 segundos a cada tentativa. Quando a tentativa que falhou passou por um proxy, a mensagem cita a variável de ambiente que o configurou (como HTTPS_PROXY). O que fazer:

  • Confirme que a variável citada aponta para o proxy certo e peça à equipe de rede que libere por ele as conexões HTTPS para o host da mensagem (lista de liberação na §5)
  • Faça a verificação de alcance com curl da §6 no mesmo shell
  • Se ficar parado em Checking connectivity... atrás de uma URL de proxy que começa com https://, pode ser um bug anterior à v2.1.222 (a verificação seguia um caminho diferente do das requisições à API e não tinha tempo limite). Atualize
  • Se a sua organização faz login por um gateway em nuvem (Claude apps gateway) e este erro aparece na primeira execução, atualize para a v2.1.247 ou posterior

Se a sua rede está aberta e a falha continua, a referência oficial observa que o Claude Code pode não estar disponível no seu país ou região. Confira a lista de países e regiões compatíveis.

Streaming response ended before any complete data was received

Streaming response ended before any complete data was received. Retrying without streaming. If this keeps happening, check any proxy or gateway between Claude Code and your model provider.

Este aviso não significa "não chegou", e sim "algo no meio do caminho alterou a resposta". Uma resposta em streaming do seu provedor de modelos terminou sem entregar nenhum dado utilizável, então o Claude Code reenviou a requisição sem streaming para concluir o turno. Cada requisição afetada é enviada duas vezes: a tentativa em streaming vazia e o reenvio. Segundo a referência oficial, a causa comum é um proxy ou gateway que consome ou transforma no caminho o corpo da resposta em streaming, e a correção é configurar qualquer proxy ou gateway entre o Claude Code e o seu provedor de modelos para repassar sem alterações o corpo e os cabeçalhos das respostas em streaming. O aviso aparece uma vez por sessão e só em sessões interativas. Antes da v2.1.239, o Claude Code repetia sem streaming em silêncio.

3. Configuração de proxy (HTTPS_PROXY)

Quando você precisa rotear por um proxy corporativo, defina as variáveis de ambiente de proxy padrão. O Claude Code as respeita.

# Recomendado: proxy HTTPS
export HTTPS_PROXY=http://proxy.example.com:8080
# Se HTTPS não estiver disponível, HTTP_PROXY
export HTTP_PROXY=http://proxy.example.com:8080
# Destinos que ignoram o proxy (separados por espaço ou vírgula)
export NO_PROXY="localhost,127.0.0.1,.internal.example.com"

# Proxy com autenticação (evite codificar senhas no código)
export HTTPS_PROXY=http://username:password@proxy.example.com:8080

Ressalvas: proxies SOCKS não são suportados. Para proxies NTLM / Kerberos, a recomendação oficial é colocar um LLM gateway no meio e apontar ANTHROPIC_BASE_URL para ele. Essas variáveis também podem ir no bloco env do settings.json.

4. TLS e certificados de CA corporativa (o mais importante, com segurança)

O bloqueio corporativo mais comum é um erro de certificado causado por um proxy de inspeção de TLS (Zscaler, Netskope, Palo Alto, etc.) substituindo os certificados. As mensagens típicas são unable to get local issuer certificate e SELF_SIGNED_CERT_IN_CHAIN.

Desde a v2.1.273, as mensagens do próprio Claude Code incluem o código do erro e a correção. Durante uma sessão, as requisições à API mostram:

Unable to connect to API: SSL certificate verification failed (UNABLE_TO_GET_ISSUER_CERT_LOCALLY). The certificate comes from an authority Claude Code doesn't trust, usually a TLS-inspecting corporate proxy or a gateway signed by a private CA: set NODE_EXTRA_CA_CERTS to that CA bundle, or add it to the system certificate store · see https://code.claude.com/docs/en/network-config
Unable to connect to API: Self-signed certificate detected (SELF_SIGNED_CERT_IN_CHAIN). The certificate comes from an authority Claude Code doesn't trust, usually a TLS-inspecting corporate proxy or a gateway signed by a private CA: set NODE_EXTRA_CA_CERTS to that CA bundle, or add it to the system certificate store · see https://code.claude.com/docs/en/network-config

Durante o /login e a verificação de conectividade na inicialização, a mesma falha gera outra mensagem:

SSL certificate error (UNABLE_TO_GET_ISSUER_CERT_LOCALLY). If you are behind a corporate proxy or TLS-intercepting firewall, set NODE_EXTRA_CA_CERTS to your CA bundle path, or ask IT to allowlist *.anthropic.com. Run `claude doctor` for details.

Antes da v2.1.273, as duas primeiras mensagens terminavam em Check your proxy or corporate SSL certificates, sem o código nem a dica de NODE_EXTRA_CA_CERTS (a saída antiga do início do artigo). Além disso, desde a v2.1.199 uma falha na validação do certificado não é repetida, então o erro aparece na primeira tentativa (versões anteriores passavam alguns minutos tentando de novo). Condições temporárias de TLS, como um tempo esgotado no handshake, continuam sendo repetidas.

Para dar contexto, versões recentes do Claude Code confiam TANTO no seu conjunto de CAs embutido QUANTO no repositório de confiança do SO. Então se a CA raiz corporativa estiver no repositório de certificados do SO, muitas vezes funciona sem configuração extra (o comportamento varia por versão, então confirme a mais recente). Se não estiver no repositório do SO, aponte NODE_EXTRA_CA_CERTS para o pacote de CA (PEM) que você recebeu do TI:

# A maneira correta e segura: confiar na CA corporativa
export NODE_EXTRA_CA_CERTS=/path/to/corporate-ca.pem

# Se o proxy exigir um certificado de cliente (mTLS)
export CLAUDE_CODE_CLIENT_CERT=/path/to/client-cert.pem
export CLAUDE_CODE_CLIENT_KEY=/path/to/client-key.pem

⚠️ NÃO faça: desativar a verificação de TLS

Desligar a verificação de certificado com NODE_TLS_REJECT_UNAUTHORIZED=0 parece "resolver", mas nunca faça isso. Isso desativa a verificação de TLS para o processo inteiro, então todo o tráfego — inclusive para api.anthropic.com — fica exposto a ataques man-in-the-middle (espionagem/adulteração). Isso arrisca vazar credenciais e código. A resposta correta é sempre "confiar adequadamente na CA corporativa via NODE_EXTRA_CA_CERTS."

Se você se deparar com um erro de certificado na hora da instalação (antes do binário existir), passe a CA para o curl: curl --cacert /path/to/corporate-ca.pem -fsSL https://claude.ai/install.sh | bash.

OAuth error: SSL certificate error (CERT_HAS_EXPIRED)

No meio do login (a etapa OAuth do /login), a mensagem abaixo pode aparecer e travar tudo. É o texto exato que usuários relataram em issues do GitHub:

OAuth error: SSL certificate error (CERT_HAS_EXPIRED). If you are behind a corporate proxy or TLS-intercepting firewall, set NODE_EXTRA_CA_CERTS to your CA bundle path, or ask IT to allowlist *.anthropic.com. Run /doctor for details.

Essa mensagem não está na referência oficial de erros. A seção oficial SSL certificate errors mostra apenas os códigos UNABLE_TO_GET_ISSUER_CERT_LOCALLY e SELF_SIGNED_CERT_IN_CHAIN; o certificado expirado só é citado de passagem, como um exemplo de falha na validação de certificados, na explicação sobre novas tentativas automáticas. O texto acima vem de usuários nas issues do GitHub #71708 e #71727 (ambas de junho de 2026).

O que CERT_HAS_EXPIRED significa: é um dos códigos de erro de certificado que a camada TLS do Node.js retorna, e a documentação oficial do Node.js o descreve como "Certificate has expired" (o certificado expirou). Ou seja, o certificado recebido do servidor foi verificado e considerado fora da validade. Essa verificação é feita com o relógio do seu próprio computador.

O que os relatos dizem: os autores das duas issues escreveram que não usavam proxy nem VPN e que o curl chegava ao mesmo host sem problemas (o autor da #71708 também confirmou que o relógio estava certo). Ou seja, o erro também aparece em ambientes que não se encaixam na dica da própria mensagem (proxy corporativo, inspeção TLS). Os autores suspeitaram do runtime embutido no Claude Code, e vários comentários dizem que voltar para uma versão anterior resolveu. Mas não há resposta da Anthropic em nenhuma das issues, e as duas foram fechadas por inatividade. A causa não foi confirmada oficialmente. Em 30 de setembro de 2026, o CHANGELOG oficial também não tem nenhuma entrada dizendo que corrige esse sintoma.

O que verificar, nesta ordem:

  1. O relógio do computador: data, hora e fuso horário estão certos? Se o relógio estiver muito errado, até um certificado válido pode ser considerado expirado.
  2. O certificado do proxy da empresa: se o seu tráfego passa por um proxy ou produto de segurança que inspeciona TLS, pergunte à TI se o certificado que ele insere (incluindo a CA corporativa) expirou.
  3. NODE_EXTRA_CA_CERTS: se você precisa confiar em uma CA corporativa, aponte NODE_EXTRA_CA_CERTS para o pacote de CA fornecido pela TI, como indica a página oficial de configuração de rede (os passos acima). Para confirmar que foi carregado, procure a linha CA certs: Appended extra certificates from NODE_EXTRA_CA_CERTS no log do claude --debug.
  4. Se continuar aparecendo: se o relógio está certo, não há proxy e curl -I https://platform.claude.com funciona, talvez você esteja na mesma situação dos relatos do GitHub. Atualize o Claude Code e confira as issues e o changelog. Um comentário diz que NODE_TLS_REJECT_UNAUTHORIZED=0 fez funcionar, mas, como explica o quadro acima, isso desliga a verificação por completo, então não use.

5. Domínios para liberar no firewall

Se o seu firewall restringe destinos, libere estes domínios principais sobre HTTPS (443) (conforme os requisitos de rede oficiais; se você usa conectores MCP, plugins etc., também precisa de outros hosts da lista oficial).

DomínioUsado para
api.anthropic.comRequisições da Claude API (obrigatório)
claude.aiAutenticação da conta claude.ai
claude.comA página que o navegador abre no login com conta claude.ai (redireciona para claude.ai)
platform.claude.comAutenticação da conta do Console; contas claude.ai também o usam para obter e renovar tokens (verificado pela checagem de conectividade inicial)
downloads.claude.aiInstalador, atualização automática, plugins
raw.githubusercontent.comRegistro de alterações do /release-notes

Os hosts de telemetria operacional e de relatório de erros (http-intake.logs.us5.datadoghq.com e browser-intake-us5-datadoghq.com) são opcionais, e CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC desativa os dois (não precisam estar na lista de liberação obrigatória). Se você instala via npm, não precisa dos usos de instalador e atualização automática do downloads.claude.ai, mas precisa do registro de pacotes registry.npmjs.org. Os domínios e faixas de IP exatos podem ser revisados, então confirme os mais recentes na página oficial de configuração de rede.

6. O fluxo de diagnóstico

Quando não conecta, vá de cima para baixo. O primeiro curl define a direção.

DIAGNOSE

Isole de cima para baixo

1
curl -I https://api.anthropic.com (Windows: curl.exe) para testar a acessibilidade. Se passar, o problema está do seu lado.
2
/doctor (ou claude doctor se ele não iniciar) e verifique as variáveis de ambiente do proxy.
3
Erro de certificado → aplique NODE_EXTRA_CA_CERTS; proxy não definido → aplique HTTPS_PROXY.
4
Tente uma conexão direta (sem VPN/proxy) para confirmar que o proxy é a causa. Peça ao TI a URL do proxy e a CA.
5
Se o curl passa mas o Claude Code falha, suspeite de DNS (resolv.conf do WSL), VPN com resíduos ou Docker interceptando o tráfego.

A regra: "teste a acessibilidade (curl) primeiro, depois aplique a configuração da camada que te travou."
Lide com certificados via NODE_EXTRA_CA_CERTS. Nunca desative a verificação.

7. Como diferenciar de erros parecidos

"Travou" também pode não ser de rede. A grande divisão é "chegou ao servidor?"

SintomaO que realmente éSolução principal
Unable to connect / Connection refused / Can't reach the API server / fetch failed / erro de certificadoEste artigo = rede (nunca chegou ao servidor)HTTPS_PROXY / NODE_EXTRA_CA_CERTS / liberação no firewall
401 / 403 / Invalid API keyAutenticação (chegou, mas há um problema de credencial)erros de autenticação / login
529 / 500Lado do servidor (chegou, mas sobrecarregado / erro interno)erros 529/500
429 Request rejectedLimite de taxa (chegou, mas tráfego demais)Reduza o ritmo, aguarde
Connection lost mid-response (antes da v2.1.227: Connection closed mid-response)Corte no meio do stream (chegou e a resposta começou a fluir, e então a conexão fechou)A resposta é cortada no meio (artigo sobre o texto antigo)

Um macete: erros de rede significam "nunca chegou ao servidor" (TCP/TLS/DNS), e HTTPS_PROXY ou NODE_EXTRA_CA_CERTS só ajudam nessa camada. Em contraste, 401/403, 529/500 e 429 são "respostas depois de chegar", então mexer no proxy ou na CA não vai resolvê-los. Se o curl tem sucesso ou não é o melhor indicador para separar os dois casos. Para outros erros comuns, veja a coletânea de erros.

Resumo

Os erros de rede/proxy do Claude Code (Unable to connect / fetch failed / SSL certificate verification failed, etc.) significam que a requisição nunca chegou ao servidor = uma falha de TCP/TLS/DNS. Eles são diferentes de autenticação (401/403), servidor (529/500) e taxa (429), e os culpados habituais são o proxy, a inspeção de TLS e o firewall corporativos. Desde a v2.1.227, eles aparecem com textos que citam primeiro o tipo de falha, como Connection refused — ou Can't reach the API server —, e a configuração inicial encerra com Unable to connect to Anthropic services.

As soluções: (1) atrás de um proxy, defina HTTPS_PROXY (SOCKS não suportado; NTLM/Kerberos via um gateway), (2) para erros de certificado coloque a CA corporativa em NODE_EXTRA_CA_CERTS — nunca NODE_TLS_REJECT_UNAUTHORIZED=0, (3) libere api.anthropic.com etc. no firewall. Diagnostique primeiro testando a acessibilidade com curl -I https://api.anthropic.com -> /doctor e verificação do proxy -> configurações de certificado/proxy -> uma conexão direta para confirmar -> DNS/VPN/Docker. A chave é separar rede de autenticação/servidor/taxa pela pergunta "chegou ao servidor?" Relacionados: erros de autenticação / login, erros 529/500, coletânea de erros do Claude Code.

A configuração, os custos e os pontos de atenção para apontar ANTHROPIC_BASE_URL para modelos que não são da Claude (DeepSeek, GLM, Kimi etc.) são explicados em Como usar DeepSeek, GLM e Kimi no Claude Code.

FAQ

Q. No PC da minha empresa aparece "Unable to connect to API" e não consigo conectar.
A. Normalmente você precisa rotear por um proxy corporativo que não está configurado. Primeiro verifique a acessibilidade com curl -I https://api.anthropic.com; se falhar, defina um proxy como export HTTPS_PROXY=http://proxy.example.com:8080 (adicione user:password@ para um proxy com autenticação). Observe que SOCKS não é suportado, e para proxies NTLM/Kerberos a recomendação oficial é passar por um LLM gateway.

Q. "Can't reach the API server" e "Connection refused" são erros diferentes do antigo "Unable to connect to API"?
A. São da mesma família; só o texto mudou na v2.1.227. Antes ele só acrescentava um código, como Unable to connect to API (ECONNREFUSED); agora cita primeiro o tipo de falha, como Connection refused — a firewall or proxy may be blocking it (ConnectionRefused) ou Can't reach the API server — check your internet or DNS (ENOTFOUND). O código entre parênteses dá uma pista da causa, então veja o que verificar na tabela da §2.

Q. Na primeira execução aparece "Unable to connect to Anthropic services" e ele encerra.
A. Ele falhou na etapa que verifica a conectividade com api.anthropic.com e platform.claude.com antes do login. Se a mensagem cita uma variável de proxy (como HTTPS_PROXY), confirme o valor dela com a equipe de rede e verifique se as conexões para o host da mensagem estão liberadas. Você também pode verificar o alcance com curl -I https://api.anthropic.com. Se a sua rede está aberta e o erro continua, a referência oficial observa que o Claude Code pode não estar disponível no seu país ou região, o que você pode conferir na lista oficial de países compatíveis.

Q. Aparece "SSL certificate verification failed".
A. Isso normalmente é um proxy corporativo de inspeção de TLS (por exemplo, Zscaler) substituindo os certificados. Obtenha a CA raiz corporativa (PEM) com o TI e defina export NODE_EXTRA_CA_CERTS=/path/to/corporate-ca.pem. Se a CA corporativa já estiver no repositório de certificados do SO, pode funcionar sem configuração. Nunca desative a verificação com NODE_TLS_REJECT_UNAUTHORIZED=0 — isso expõe todo o tráfego à interceptação.

Q. Definir NODE_TLS_REJECT_UNAUTHORIZED=0 resolveu. Isso está OK?
A. Não — reverta agora. Isso desativa a verificação de certificado de TLS para o processo inteiro, deixando todo o tráfego — inclusive para api.anthropic.com — indefeso contra ataques man-in-the-middle (espionagem/adulteração). É um risco de segurança sério que pode vazar credenciais e código-fonte. A única solução correta é confiar adequadamente na CA corporativa via NODE_EXTRA_CA_CERTS.

Q. Quais domínios devo liberar no firewall?
A. Sobre HTTPS (443), no mínimo libere api.anthropic.com (API), claude.ai, claude.com e platform.claude.com (autenticação), downloads.claude.ai (instalador/atualizações) e raw.githubusercontent.com (registro de alterações). Telemetria operacional e relatório de erros (Datadog) são opcionais. Os domínios/IPs exatos podem ser revisados, então confirme os mais recentes na página oficial de configuração de rede.

Q. O curl funciona, mas só o Claude Code não conecta.
A. A causa muitas vezes está entre o Claude Code e o SO. Casos comuns: um /etc/resolv.conf do WSL apontando para um DNS morto, resíduos de VPN (por exemplo, interfaces utun antigas do macOS), ou uma ferramenta residente como o Docker interceptando o tráfego. Tente uma conexão direta sem VPN, pare as ferramentas residentes e revise o DNS, nessa ordem. Observe que erros 5xx transitórios são repetidos automaticamente até 10 vezes, então se você vir um erro enquanto o curl tem sucesso, as tentativas já foram esgotadas.