Resposta rápida
Se o receptor do webhook usa uma allowlist estática, adicione agora as redes 9.234.98.160/28, 9.234.98.176/28 e 9.234.106.48/28 sem remover as faixas que já estão em produção. O GitHub anunciou em 29 de outubro de 2026 que esses blocos passaram a ser usados para entregas de webhooks no GitHub.com, em todos os planos, inclusive GitHub Enterprise Cloud.
A correção durável é consultar periodicamente GET https://api.github.com/meta e sincronizar a lista da chave hooks com o firewall. Se sua automação já faz isso, o GitHub informa que nenhuma mudança é necessária. A allowlist deve complementar HTTPS e a validação de X-Hub-Signature-256; endereço IP não substitui autenticação do payload.
Por que um webhook correto pode parar de chegar
O GitHub entrega o POST a partir de sua infraestrutura. Quando um firewall, WAF, load balancer ou security group aceita somente redes previamente cadastradas, uma entrega originada em um bloco novo pode ser recusada antes de alcançar a aplicação. Nesse cenário, URL, evento e segredo continuam corretos, mas o endpoint não recebe o corpo para validar a assinatura.
A mudança não significa que todo erro observado em 29 de outubro seja causado pelos novos IPs. Ela é relevante quando existe filtragem por origem e o histórico de Recent deliveries mostra falha de conexão ou recusa de rede. Um HTTP 401, 403 ou 500 vindo da aplicação prova que a requisição chegou mais longe e exige outro diagnóstico.
Descubra em qual camada a entrega falhou
Abra o webhook no repositório, organização ou GitHub App e consulte Recent deliveries. A ausência de uma entrega para o evento esperado aponta primeiro para escopo, assinatura do evento ou configuração do hook. Uma entrega registrada com falha indica que o GitHub tentou chamar o endpoint e preserva informações úteis sobre requisição e resposta.
O GitHub diferencia erros de conexão com o host, bloqueio de rede, timeout e resposta HTTP. Use essa evidência junto com logs do edge e da aplicação; não libere redes adicionais por tentativa quando o erro real é DNS, certificado, demora ou código do receptor.
- Sem entrada em Recent deliveries: confirme evento, repositório, organização, GitHub App e estado ativo do hook.
- Failed to connect to host: teste resolução DNS, rota, porta 443 e disponibilidade pública do endpoint.
- Failed to connect to network ou conexão recusada: compare a origem com a allowlist do firewall e confirme se as três novas redes estão aceitas.
- Timeout: responda em até dez segundos e mova o processamento para uma fila assíncrona.
- HTTP 4xx ou 5xx: revise proxy, rota, método, autenticação da aplicação, validação da assinatura e logs pelo X-GitHub-Delivery.
Atualize uma allowlist estática sem abrir uma brecha
Inclua os três CIDRs anunciados no conjunto existente e aplique a mudança de forma atômica, com validação de sintaxe e plano de reversão. Não troque toda a regra por apenas esses blocos: eles foram adicionados à lista, não apresentados como substitutos das demais redes de webhooks.
Mantenha a regra restrita à porta e ao destino usados pelo receptor. Aceitar um IP do GitHub não torna qualquer conteúdo vindo dele confiável, porque integrações diferentes compartilham infraestrutura e uma configuração incorreta ainda pode encaminhar um payload inesperado. O endpoint precisa continuar validando a assinatura antes de processar o evento.
- Exporte a configuração atual e registre o conjunto de redes aceitas antes da mudança.
- Adicione 9.234.98.160/28, 9.234.98.176/28 e 9.234.106.48/28 à regra específica do endpoint HTTPS.
- Valide a configuração do firewall ou proxy antes do reload e preserve uma reversão conhecida.
- Monitore rejeições no edge e entregas recentes no GitHub durante a aplicação.
- Depois do teste, remova somente regras obsoletas confirmadas pela fonte oficial e pelo histórico do ambiente.
Automatize a chave hooks da Meta API
O endpoint público GET /meta retorna metadados do GitHub, incluindo a matriz hooks com os CIDRs usados para entregar webhooks. A documentação alerta que os valores exibidos em exemplos podem estar desatualizados; consulte o endpoint diretamente para obter a lista atual. Não use as chaves actions, api ou git para preencher a regra de webhooks.
Uma automação segura baixa o JSON, valida que hooks existe e contém apenas CIDRs válidos, compara o resultado com a configuração aprovada e aplica a diferença de maneira controlada. Uma resposta vazia, formato inesperado ou redução abrupta deve falhar de forma segura e exigir revisão, em vez de apagar a allowlist atual.
- Consulte https://api.github.com/meta por HTTPS e extraia somente a chave hooks.
- Valide cada IPv4 ou IPv6 como CIDR e rejeite resposta vazia, duplicada ou malformada.
- Gere um diff entre a lista oficial e a regra instalada; registre adições e remoções sem incluir segredos.
- Aplique a atualização em uma regra temporária ou transação e confirme a saúde do endpoint.
- Execute a consulta periodicamente e alerte quando a aplicação automática falhar.
Preserve HTTPS, assinatura e idempotência
O GitHub recomenda HTTPS com verificação de certificado habilitada e um segredo de webhook de alta entropia. Calcule o HMAC-SHA256 sobre os bytes originais do corpo, acrescente o prefixo sha256= e compare com X-Hub-Signature-256 usando uma função de tempo constante. Uma comparação comum com == pode vazar informação por tempo de execução.
Use X-GitHub-Delivery como chave de idempotência e rejeite duplicatas já concluídas. Valide assinatura e tipo do evento antes de enfileirar o trabalho, devolva um código 2xx rapidamente e processe tarefas demoradas fora da requisição. Não confie em X-Forwarded-For sem uma cadeia de proxies própria e configurada para sobrescrever cabeçalhos recebidos do cliente.
Teste a correção e recupere entregas perdidas
Depois de liberar as redes e confirmar a aplicação, escolha uma entrega falhada e use Redeliver. O GitHub permite reenviar pela interface entregas dos últimos três dias. Ele não reenvia automaticamente webhooks que falharam, então uma correção no firewall não recupera por si só os eventos anteriores.
Confirme um código 2xx, a presença do mesmo X-GitHub-Delivery nos logs e o efeito esperado no consumidor. A redelivery repete um evento antigo e pode chegar depois de eventos mais novos; idempotência e tolerância a ordem são necessárias para não duplicar tickets, deploys, pagamentos ou notificações.
- Consulte o GitHub Status para excluir um incidente amplo em Webhooks ou API.
- Reenvie uma única entrega recente de baixo risco e acompanhe edge, aplicação e fila.
- Confirme a validação HMAC e o retorno 2xx dentro de dez segundos.
- Verifique se uma segunda tentativa com o mesmo identificador não duplica o efeito.
- Só então reenvie outras entregas necessárias dentro da janela disponível.
Limitações e próxima ação útil
Este guia foi verificado em 30 de outubro de 2026 e se aplica às entregas de webhooks no GitHub.com. Instalações do GitHub Enterprise Server têm infraestrutura e documentação próprias. A Meta API pode mudar; a lista de IPs do GitHub não representa todos os serviços da plataforma, por isso use especificamente hooks para este caso e não transforme a allowlist em mecanismo único de confiança.
A próxima ação é consultar agora a chave hooks da Meta API, comparar o resultado com a regra que protege seu receptor e adicionar as três redes caso a lista ainda seja estática. Depois, reenvie uma entrega falhada dos últimos três dias e confirme conexão, HMAC, resposta 2xx e idempotência antes de considerar o incidente encerrado.
Faça o próximo teste
Fontes consultadas
Os links abaixo servem para conferir conceitos, orientações oficiais e o critério editorial usado neste conteúdo.
- Webhook IP ranges added to the Meta APIGitHub Changelog
- Meta APIGitHub Docs
- Best practices for using webhooksGitHub Docs
- Troubleshooting webhooksGitHub Docs
- Validating webhook deliveriesGitHub Docs
- Redelivering webhooksGitHub Docs
- GitHub StatusGitHub