Release 2026.6 - Migração de infraestrutura para Cloudflare
Tipo: Mudança de infraestrutura · Ação requerida: apenas para integrações com allowlist de IP de saída ou certificate pinning
A camada de borda de todos os serviços da NFe.io foi migrada de Azure para Cloudflare.
O contrato da API permanece idêntico: status HTTP, Content-Type, corpo e versão HTTP não mudaram.
O que mudou
| Item | Antes (origin direto) | Agora (via Cloudflare) |
|---|---|---|
| IP resolvido | IPv4 dedicado do origin | Ranges Cloudflare (IPv4 + IPv6) |
| Terminação TLS | Servidor de origem | Cloudflare |
| Certificado | Leaf por host (Let's Encrypt) | *.nfe.one (Google Trust Services) |
| Headers adicionados | — | cf-ray, cf-cache-status, server: cloudflare, NEL, Report-To |
Strict-Transport-Security | Presente | Em descontinuação (ver Ação requerida) |
| Status / Content-Type / Corpo / HTTP version | — | Sem alteração |
Ação requerida
- Allowlist de IP (apenas saída): atualize as regras de saída dos seus sistemas para os ranges oficiais da Cloudflare (IPv4 e IPv6). Prefira liberar por hostname em vez de IP fixo. Allowlist de entrada não é afetada — a NFe.io não origina requisições a partir de IPs da Cloudflare.
- Certificate pinning: o host continua apresentando SSL válido e a validação TLS padrão funciona normalmente — sem ação para a maioria. Só impacta quem faz pinning explícito de leaf/CA: nesse caso, remova o pinning anterior ou atualize para a cadeia
*.nfe.one(Google Trust Services). - HSTS / parsing de headers: o header
Strict-Transport-Securityestá sendo descontinuado na borda. Use semprehttps://explicitamente nas integrações — não dependa do HSTS para forçar o upgrade dehttpparahttps. Ajuste também se houver parsing rígido de headers.
Sem ação necessária
Integrações que usam validação TLS padrão e não restringem por IP de saída continuam funcionando sem alterações. Quem recebe tráfego da NFe.io (ex.: webhooks) também não precisa ajustar allowlist de entrada.