GitHub Bloqueado: A Internet Brasileira Virou um Ambiente Hostil para Desenvolvedores

Que baita semana para gostar de computador.

De um lado, centenas de pacotes do AUR aparecem em listas de comprometimento com suspeita de infostealer e rootkit. Do outro, a API do GitHub começa a cair no Brasil como se tivesse sido hospedada numa TV Box apreendida em operação da Anatel.

Se você é desenvolvedor brasileiro, a quinta-feira virou um daqueles dias em que o terminal te olha de volta e pergunta: “você tem certeza que escolheu essa profissão por vontade própria?”.

O site do GitHub abria. O repositório podia até clonar. Mas ferramentas que dependem de api.github.com começaram a falhar. GitHub CLI, autenticação de extensões, bots, scripts de release, automações, consultas de issues, listagens de pull requests, integrações com CI, utilitários pessoais e qualquer coisa que conversasse com a API do GitHub entrava em timeout.

Não era o GitHub inteiro fora do ar. Era pior.

Era aquele tipo de falha seletiva que parece bug local, depois parece problema de DNS, depois parece rota quebrada, depois começa a aparecer no relato de gente em operadoras diferentes, e no final você percebe que talvez o problema não esteja no seu computador. Talvez o problema esteja no país.

A API Que Ninguém Vê Até Parar

Para um usuário comum, GitHub é o site. É a página que abre no navegador, o botão verde de clone, o README bonito, as issues, os releases e os repositórios públicos.

Para um desenvolvedor, GitHub é muito mais que isso. É uma camada de infraestrutura.

A API do GitHub é o canal invisível que conecta uma quantidade enorme de ferramentas ao ecossistema da plataforma. Quando você roda gh pr list, não tem um duende raspando HTML da página de pull requests. A CLI fala com a API. Quando uma extensão do VS Code precisa validar autenticação, buscar informações da conta ou acionar recursos do Copilot, ela conversa com endpoints do GitHub. Quando um script interno lista issues abertas, fecha releases, cria tags, lê metadados ou consulta rate limit, ele usa a API. Quando um dashboard seu mostra pendências de repositórios, aquilo provavelmente não está olhando para o site: está chamando api.github.com.

É por isso que o bloqueio de uma API não é pequeno só porque o site principal continua abrindo.

Essa é a diferença entre quebrar a vitrine e quebrar o estoque. O usuário final olha a loja funcionando e acha que está tudo bem. O desenvolvedor entra no depósito e encontra os corredores alagados, o ERP fora do ar e o sistema de pagamento respirando por aparelhos.

A internet moderna é feita de APIs. Elas são a parte menos visível e mais crítica da infraestrutura. Bloquear uma API de forma descuidada é atingir diretamente a automação, a integração e a operação de quem trabalha com tecnologia.

E no caso do GitHub, isso significa mexer em uma das principais peças da cadeia global de desenvolvimento de software.

O Que Aparentemente Aconteceu

O caso ainda exige cuidado. Até onde encontrei, não há uma nota oficial clara, pública e detalhada dizendo: “a Anatel mandou bloquear api.github.com por este motivo, neste escopo, nesta data, por este procedimento, com este mecanismo técnico e com este plano de correção”.

O que existe são indícios fortes, relatos técnicos e um padrão já conhecido por quem acompanha bloqueios de internet no Brasil.

O Ayub, do Internet Propriamente Dita, publicou que havia todos os indícios típicos de bloqueio nacional determinado pela Anatel contra api.github.com. Outros usuários reportaram que o domínio resolvia para o IP 4.228.31.149, mas conexões para a porta 443 simplesmente morriam em timeout. Alguns testavam por grandes operadoras e falhavam. Outros testavam por VPN ou rotas fora do Brasil e funcionava. Em comunidades técnicas, apareceram relatos de falha em Claro, Vivo, TIM, Algar e outras redes, enquanto alguns provedores regionais pareciam não sofrer o mesmo efeito.

Esse padrão é importante porque ele não se parece com uma queda global do GitHub. Também não se parece simplesmente com “meu DNS está ruim”. Quando o domínio resolve corretamente, mas a conexão TCP para o destino morre no caminho, estamos em outro território. Pode ser rota quebrada, blackhole, bloqueio em provedor, filtragem em backbone, política aplicada por operadoras ou algum tipo de regra mal calibrada no caminho.

O problema é que, no Brasil, quando esse tipo de falha aparece em ondas e atinge grandes operadoras, a suspeita imediatamente cai sobre o sistema de bloqueios administrativos e judiciais que vem sendo usado há anos para combater pirataria, TV Box, streaming ilegal, sites de apostas irregulares e outros alvos.

O ponto não é defender pirataria. Esse espantalho é cansativo.

O ponto é que um mecanismo criado para bloquear um alvo específico não pode sair atropelando infraestrutura legítima como dano colateral aceitável.

Bloqueio Sigiloso É o Nome Bonito Para Quebrar a Internet Sem Prestar Conta

A parte mais grave dessa história não é apenas a API do GitHub ter ficado inacessível. O grave é a opacidade.

Quando uma autoridade pública manda bloquear algo na internet, essa decisão deveria ser pública, rastreável, auditável e tecnicamente limitada. Deveria haver escopo claro. Deveria haver mecanismo de contestação. Deveria haver transparência sobre o domínio, IP, ordem judicial ou administrativa, duração, motivação e efeito esperado. Deveria haver análise de impacto antes de sair aplicando regra em massa.

Mas o que usuários técnicos vêm denunciando há tempos é justamente o contrário: bloqueios sigilosos, listas não auditáveis, decisões difíceis de rastrear e efeitos colaterais descobertos só depois que usuários legítimos perdem acesso a serviços completamente alheios ao alvo original.

O Ayub vem batendo nessa tecla há bastante tempo. A tese central é simples: quando o Estado cria uma infraestrutura de bloqueio nacional e opera isso sem transparência pública adequada, não importa se o discurso inicial é combater pirataria, proteger propriedade intelectual ou derrubar serviço ilegal. O mecanismo passa a existir. E mecanismo estatal opaco, uma vez instalado, tende a expandir.

Hoje é site de streaming pirata. Amanhã é domínio compartilhado em CDN. Depois é GitHub Pages. Depois é API do GitHub. Depois é um registry de container. Depois é um endpoint usado por ferramenta de autenticação. Depois é um serviço que alguma empresa brasileira usa em produção e ninguém sabe explicar por que parou.

O usuário comum chama suporte e escuta “reinicie o roteador”.

O desenvolvedor roda traceroute e percebe que o problema é o país.

A Fragilidade Técnica de Bloquear a Internet Moderna

Bloquear internet em 2026 não é como bloquear uma linha telefônica.

A web moderna não é um conjunto simples de sites isolados, cada um com um IP dedicado, um servidor físico e uma relação direta entre domínio e conteúdo. A infraestrutura atual é compartilhada, distribuída, cacheada, balanceada, roteada por CDNs, protegida por proxies reversos, replicada em regiões diferentes e exposta por APIs que atendem milhões de clientes programáticos.

Um único endereço IP pode hospedar ou encaminhar tráfego para muitos serviços. Um único domínio pode ser crítico para uma cadeia inteira de ferramentas. Um endpoint pode parecer irrelevante para quem olha de fora, mas ser essencial para autenticação, automação, deploy, monitoramento ou integração de sistemas.

GitHub é um exemplo perfeito. github.com é a superfície humana. api.github.com é a superfície de máquina. raw.githubusercontent.com serve conteúdo bruto. objects.githubusercontent.com pode aparecer em downloads. O ecossistema de autenticação, releases, actions, pacotes, Copilot, integrações e CLIs conversa com múltiplos endpoints. Quebrar um pedaço pode não derrubar o site, mas derruba fluxos inteiros de trabalho.

Isso é o que autoridades e operadoras frequentemente parecem subestimar. A internet não é uma lista de “endereços de sites”. É um grafo de dependências.

E quando você bloqueia um nó errado, o dano se propaga.

O Desenvolvedor Vira Operador de Rede Por Obrigação

Uma das coisas mais absurdas desse episódio é ver desenvolvedores precisando diagnosticar bloqueio de infraestrutura nacional como se isso fosse parte normal do expediente.

A pessoa senta para revisar um pull request. O gh pr list trava. Ela testa o navegador. O GitHub abre. Ela testa a API. Timeout. Testa DNS. Resolve. Testa outro DNS. Mesmo IP. Testa VPN. Funciona. Testa operadora diferente. Às vezes funciona, às vezes não. Testa IPv6. Testa curl com timeout. Testa porta 443. Testa traceroute. Testa de uma VPS fora do Brasil. Funciona. Testa pelo 4G. Falha.

Em algum momento, o trabalho deixou de ser desenvolver software e virou perícia amadora de backbone.

Isso não é normal.

Claro, diagnosticar rede faz parte da vida técnica. Todo desenvolvedor deveria entender o básico de DNS, TCP, TLS, HTTP e roteamento. Mas existe uma diferença entre depurar sua aplicação e ter que provar que uma autoridade ou operadora quebrou o acesso a uma infraestrutura global de desenvolvimento.

O usuário técnico brasileiro está sendo empurrado para uma postura de sobrevivência: VPN, DNS alternativo, WARP, proxy, túnel SSH, VPS fora do país, fallback em ferramenta própria, wrappers locais, split tunneling, gambiarras em /etc/hosts, scripts com proxy configurável.

Isso pode ser tecnicamente interessante. Mas politicamente é péssimo.

Quando uma população técnica começa a tratar bypass como requisito básico para trabalhar, o país está normalizando a degradação da própria internet.

Não É Sobre O GitHub Ser Sagrado

É importante deixar uma coisa clara: GitHub não é uma entidade divina. É uma empresa privada, centralizada, com seus próprios problemas, lock-ins, decisões ruins e dependências questionáveis. Eu mesmo gosto de pensar em alternativas, mirrors, forge própria, Gitea, Forgejo, GitLab, backups e estratégias para não depender cegamente de uma plataforma só.

Mas essa discussão é outra.

O problema aqui não é “desenvolvedores dependem demais do GitHub”. Isso pode até ser verdade, mas não justifica bloqueio colateral opaco. Se amanhã o alvo fosse GitLab, npm, PyPI, Docker Hub, crates.io, Go Proxy, Maven Central, Arch mirrors, Nix cache, Vercel, Cloudflare, AWS, Google APIs ou qualquer outra infraestrutura legítima, o princípio seria o mesmo.

A crítica não é “mexeram no meu brinquedo favorito”.

A crítica é: uma autoridade pública não pode tratar infraestrutura compartilhada como se fosse botão de liga e desliga em painel de TV a cabo pirata.

Esse é o tipo de coisa que separa política pública séria de improviso burocrático com poder demais.

O Argumento da Pirataria Não Pode Virar Carta Branca

Toda vez que se critica bloqueio de internet no Brasil, aparece alguém dizendo que é necessário combater pirataria, proteger propriedade intelectual, bloquear golpe, impedir crime, derrubar streaming ilegal, proteger consumidor ou fechar botnet de TV Box.

Algumas dessas preocupações são legítimas. Crime digital existe. Pirataria existe. Golpe existe. Infraestrutura abusada por malware existe. Ninguém sério nega isso.

Mas legitimidade do objetivo não absolve irresponsabilidade do método.

Se para derrubar um serviço ilegal você cria um mecanismo sigiloso que pode bloquear infraestrutura legítima sem transparência, sem contraditório, sem auditoria pública e sem reparação rápida, você não criou uma política de segurança. Criou um canhão apontado para a camada errada.

O Estado não pode responder ao abuso da internet quebrando a internet.

Essa frase parece óbvia. Infelizmente, no Brasil, o óbvio precisa ser documentado em traceroute.

Quando a Solução Técnica Vira Sintoma Político

O mais curioso é que a comunidade técnica sempre encontra um jeito. E isso é, ao mesmo tempo, bonito e triste.

Bonito porque desenvolvedores são bons em contornar falhas. Se a rota direta não funciona, usa-se outra rota. Se o DNS do provedor mente, testa-se outro resolvedor. Se a operadora joga tráfego no buraco, passa-se por VPN. Se uma CLI trava, exporta-se HTTPS_PROXY. Se uma ferramenta própria depende da API, adiciona-se suporte a proxy. Se o endpoint falha em uma rede, testa-se de uma VPS.

Triste porque nada disso deveria ser necessário para acessar a API pública do GitHub.

Workaround é curativo. Não é cura.

E pior: workaround individual tende a anestesiar a indignação coletiva. O desenvolvedor mais experiente configura um túnel, volta a trabalhar e segue a vida. A empresa coloca uma VPN corporativa e esquece. O usuário avançado muda DNS, usa WARP, sobe proxy SOCKS e transforma a exceção em rotina. Enquanto isso, o mecanismo que causou o problema continua existindo, opaco, silencioso e pronto para quebrar outra coisa no futuro.

Essa é a armadilha. Resolver para si mesmo não resolve o problema público.

A Internet Brasileira Está Ficando Menos Confiável

Existe um custo econômico e técnico nesse tipo de instabilidade.

Uma empresa que depende de automações no GitHub pode perder deploy. Um time pode ficar sem revisar PR. Uma extensão de editor pode parar de autenticar. Um bot interno pode deixar de triagear issues. Uma pipeline pode falhar não porque o código está errado, mas porque um endpoint externo foi bloqueado no caminho. Um desenvolvedor júnior pode gastar horas achando que configurou errado o ambiente. Um freelancer pode perder prazo. Um projeto open source pode ficar inacessível para parte dos mantenedores.

E tudo isso é invisível para a estatística comum.

Do ponto de vista de quem só mede “o site abre?”, talvez nada tenha acontecido. Do ponto de vista de quem trabalha com a API, o sistema quebrou.

Isso é um problema de infraestrutura nacional. A confiança na internet de um país não depende apenas de velocidade de download em propaganda de operadora. Depende de previsibilidade, neutralidade, transparência e baixa interferência arbitrária.

Se desenvolvedores começam a assumir que certas APIs podem morrer por decisão opaca ou erro de bloqueio, eles passam a projetar sistemas pensando em evasão, redundância forçada e rotas estrangeiras. Isso encarece operação. Isso degrada experiência. Isso reduz competitividade. Isso transforma conectividade em risco de negócio.

O Brasil já tem desafio suficiente com imposto, burocracia, instabilidade jurídica e custo de infraestrutura. Adicionar “talvez a API que você usa seja bloqueada em alguma quarta-feira” ao pacote é quase uma piada de mau gosto.

A Relação Com o Caso do AUR

O mais irônico é que esse episódio aconteceu no mesmo momento em que usuários Linux estavam discutindo pacotes AUR comprometidos.

Os dois casos parecem diferentes, mas conversam muito bem.

O caso do AUR é sobre supply chain de software. O caso do GitHub bloqueado é sobre supply chain de infraestrutura. Em um, a confiança quebra porque código comunitário pode ter sido manipulado. No outro, a confiança quebra porque a rede entre você e uma dependência legítima pode ser interrompida por decisão externa opaca.

Nos dois casos, o desenvolvedor é lembrado de uma verdade desagradável: seu ambiente de trabalho é uma pilha de dependências que você não controla completamente.

Você depende do mantenedor do pacote. Depende do upstream. Depende do registry. Depende do DNS. Depende da operadora. Depende do backbone. Depende do provedor cloud. Depende da autoridade regulatória. Depende da plataforma de hospedagem. Depende da CDN. Depende de uma cadeia enorme de decisões técnicas e políticas invisíveis.

Quando tudo funciona, parece simples. Quando quebra, você descobre quantas camadas havia entre você e um comando aparentemente banal.

yay -S.

gh pr list.

Duas linhas inocentes. Dois lembretes de que infraestrutura é confiança empilhada.

O Que Deveria Acontecer

O mínimo aceitável seria transparência.

Se houve bloqueio determinado por autoridade pública, a ordem deveria ser identificável. O escopo deveria ser claro. O alvo deveria ser tecnicamente justificado. A lista de domínios ou IPs afetados deveria ser auditável por órgãos competentes e contestável por partes impactadas. Deveria existir canal rápido de correção para falso positivo. Deveria haver relatório de impacto. Deveria haver responsabilização quando infraestrutura legítima é atingida.

Se não houve bloqueio, então as operadoras envolvidas deveriam explicar por que um endpoint crítico ficou inacessível em suas redes enquanto funcionava por outras rotas. Problema técnico também exige prestação de contas quando afeta tanta gente.

O que não dá é ficar nesse limbo brasileiro onde ninguém sabe oficialmente o que aconteceu, todo mundo coleta evidência por conta própria, usuários técnicos viram testemunhas de rede e o incidente desaparece quando volta a funcionar.

Falha que some sem explicação não deixa de ser falha. Só vira precedente.

O Que Desenvolvedores Devem Fazer

Do ponto de vista técnico, o mais importante é documentar. Não basta reclamar no Twitter ou no grupo do Telegram. É preciso coletar evidências úteis: horário, operadora, cidade, domínio afetado, IP resolvido, resultado de conexão TCP, comportamento com e sem VPN, teste em rede alternativa, traceroute quando aplicável, ferramenta impactada e mensagem de erro.

Isso não é para alimentar paranoia. É para transformar sensação em dado.

Também é prudente projetar ferramentas próprias com suporte a proxy e timeout decente. Não porque isso resolva o problema político, mas porque ferramentas que travam indefinidamente por falha de rede são ruins de qualquer forma. Se uma CLI depende de API externa, ela precisa falhar bem, explicar o erro, respeitar timeout, permitir proxy e não fingir que toda falha de conexão é bug de autenticação.

Empresas deveriam observar esse episódio como alerta de continuidade operacional. Se sua esteira de deploy, autenticação ou release depende de um único endpoint externo acessado por uma única rota nacional, você tem um ponto de falha. Talvez o risco seja aceitável. Talvez não. Mas ele precisa ser consciente.

E, principalmente, a comunidade técnica não deveria normalizar o bloqueio. Workaround é necessário para trabalhar. Mas workaround não pode virar silêncio.

Conclusão: O Brasil Está Testando a Paciência da Própria Infraestrutura

O bloqueio aparente da API do GitHub é o tipo de evento que parece pequeno para quem não entende desenvolvimento de software e enorme para quem vive dele.

Para o burocrata, é só mais um domínio. Para o desenvolvedor, é autenticação, automação, integração, release, issue, PR, bot, CLI, editor, extensão e fluxo de trabalho. Para a economia digital, é mais uma rachadura na confiança de que a internet brasileira é neutra, previsível e tecnicamente séria.

O problema não é apenas um timeout em api.github.com.

O problema é a naturalidade com que aceitamos que pedaços essenciais da internet possam ser bloqueados, afetados ou degradados sem explicação pública adequada. O problema é o sigilo tratado como ferramenta administrativa normal. O problema é o dano colateral tratado como inconveniente menor. O problema é desenvolvedor precisando aprender bypass para revisar pull request.

Ainda não é o fim do mundo. Mas é mais um daqueles sinais feios piscando no painel.

No mesmo dia em que o AUR lembra que rodar código de terceiros exige desconfiança, a internet brasileira lembra que depender de infraestrutura pública também exige vigilância.

A diferença é que, no AUR, pelo menos o PKGBUILD está na sua frente.

No bloqueio estatal opaco, nem isso.