> ## Content Index > Fetch the complete content index at: https://www.azurebrasil.cloud/llms.txt > Use this file to discover other available public pages before exploring further. # O problema que o NAT Gateway não resolveu: quando a instância é a culpada - URL: https://www.azurebrasil.cloud/blog/o-problema-que-o-nat-gateway-nao-resolveu-quando-a-instancia-e-a-culpada/ - Published: 2026-03-11T12:15:26.000Z - Updated: 2026-03-11T12:15:26.000Z - Author: Rafael dos Santos - Tags: case No [post anterior](https://www.azurebrasil.cloud/blog/o-timeout-que-funcionava-na-minha-maquina-como-diagnosticamos-snat-port-exhaustion-no-azure/), contei como diagnosticamos e resolvemos SNAT Port Exhaustion implementando **NAT Gateway** com **VNet Integration**. Foi uma vitória. Os timeouts sumiram, os usuários pararam de reclamar, e seguimos em frente. Algumas semanas de paz. Até que o alerta voltou. **SNAT Connection Failed Count** apareceu novamente no Azure Monitor. Não com a mesma intensidade de antes, mas estava lá. Intermitente, teimoso. Se você já passou por isso — resolver um problema e vê-lo voltar — sabe a frustração. Será que o NAT Gateway não funcionou? Será que tem algo errado na configuração? ![app_service__failed_snat.jpeg](https://storage.ghost.io/c/00/52/0052dced-0017-4d07-b190-1f5c48e0ab59/content/images/2026/02/app_service__failed_snat.jpeg) ## A Investigação Minha primeira reação foi duvidar da solução. Será que o `WEBSITE_VNET_ROUTE_ALL=1` estava configurado corretamente? Será que o NAT Gateway estava associado à subnet certa? Verifiquei tudo. Configuração perfeita. Então fui para as métricas. No **Azure Monitor**, acessei as métricas do App Service e adicionei **SNAT Connection Failed Count**. Os erros estavam lá, mas algo não batia: o volume era muito menor do que antes. Foi quando lembrei de uma funcionalidade que raramente uso: **Split by Instance**. No gráfico de métricas, cliquei em **Apply splitting** → **Instance**. E ali estava a resposta. De duas instâncias rodando, **apenas uma** estava gerando erros SNAT. A outra estava completamente limpa. > "O problema não é o NAT Gateway. O problema é uma instância específica." **BINGO.** ## O Teste: Escalando para Isolar Antes de agir, precisávamos ter certeza. Uma instância com problema poderia ser coincidência — talvez ela estivesse recebendo mais tráfego, talvez houvesse algo específico nas requisições que ela processava. Decidimos escalar de 2 para 4 instâncias. Não por capacidade, mas por **diagnóstico**. Aguardamos alguns minutos para as novas instâncias entrarem em operação e começarem a receber tráfego. Voltamos ao Azure Monitor com o split por instância. O resultado foi claro: - **3 instâncias**: zero erros SNAT - **1 instância**: continuava falhando Não era o código. Não era a configuração. **Era a instância.** ## Por que uma instância pode falhar isoladamente? Cada instância do App Service roda em uma VM (ou container, no caso de Linux) na infraestrutura do Azure. Embora o Azure abstraia isso de nós, essas VMs são máquinas reais com componentes reais que podem apresentar problemas: - **Problemas de conectividade de rede** no host subjacente - **Configuração de rede corrompida** no container - **Estado inconsistente** após uma atualização de plataforma - **Problemas no roteamento** para o NAT Gateway através da VNet O NAT Gateway estava funcionando perfeitamente — para as instâncias que conseguiam rotear corretamente até ele. A instância problemática, por algum motivo, não estava conseguindo utilizar o NAT Gateway corretamente, caindo de volta no pool SNAT limitado. ## A Solução: Repair no App Service Linux O App Service Linux tem uma funcionalidade poderosa e pouco conhecida: o **Repair** (ou **Linux Repair** em algumas documentações). ![app_service_repair.jpeg](https://storage.ghost.io/c/00/52/0052dced-0017-4d07-b190-1f5c48e0ab59/content/images/2026/02/app_service_repair.jpeg) Diferente de um simples **Restart**, que apenas reinicia sua aplicação, o **Repair** substitui a infraestrutura subjacente — o container e potencialmente o host onde sua instância roda. ### Como usar o Repair 1. No portal do Azure, acesse seu **App Service** 2. No menu lateral, clique em **Diagnose and solve problems** 3. Na barra de pesquisa, digite **"Repair"** 4. Selecione **Linux Repair** nos resultados 5. O Azure mostrará as instâncias disponíveis — selecione a instância problemática 6. Clique em **Repair** e confirme O processo leva alguns minutos. O Azure irá: - Criar uma nova infraestrutura para a instância - Migrar sua aplicação para a nova infraestrutura - Remover a infraestrutura antiga Durante o processo, as outras instâncias continuam operando normalmente, então não há downtime para seus usuários (desde que você tenha mais de uma instância). ### Alternativa: Reiniciar instância específica Se você preferir tentar um restart antes do repair, pode reiniciar uma instância específica via REST API ou usando o **Advanced Tools (Kudu)**. Mas na nossa experiência, quando o problema é de infraestrutura, o **Repair** é mais efetivo porque substitui o ambiente completamente. Para referência, veja como reiniciar instâncias específicas: - [How to restart Azure App Service instance](https://stackoverflow.com/questions/36917229/how-to-restart-azure-app-service-instance?ref=azurebrasil.cloud) — Discussão no Stack Overflow sobre métodos de reinício ## O Resultado Após executar o **Repair** na instância problemática, voltamos ao Azure Monitor. **SNAT Connection Failed Count: 0** ![app_service__success_snat.jpeg](https://storage.ghost.io/c/00/52/0052dced-0017-4d07-b190-1f5c48e0ab59/content/images/2026/02/app_service__success_snat.jpeg) Desde então, nenhuma falha SNAT ocorreu. A nova instância está roteando corretamente através do NAT Gateway, como deveria. Após confirmar a estabilidade, reduzimos o scale de volta para o número de instâncias adequado para nossa carga. ## Lições Aprendidas 1. **A infraestrutura também pode ser a culpada.** Quando código e configuração estão corretos, considere que o problema pode estar na camada que você não controla — o host, o container, a rede subjacente. 2. **Métricas por instância revelam problemas escondidos.** Sempre use **Split by Instance** quando estiver investigando problemas intermitentes. Uma média saudável pode esconder uma instância doente. 3. **Escalar pode ser ferramenta de diagnóstico.** Às vezes você escala não por capacidade, mas para isolar e confirmar onde está o problema. 4. **Repair > Restart para problemas persistentes.** Se um restart não resolve, o Repair substitui a infraestrutura completa. É mais invasivo, mas mais efetivo para problemas de plataforma. ## Referências Para se aprofundar no tema: ### Diagnóstico por Instância - [Troubleshoot instance-related issues on Azure App Service](https://learn.microsoft.com/en-us/troubleshoot/azure/app-service/troubleshoot-instance-related-issues-on-azure-app-service?ref=azurebrasil.cloud) — Guia oficial para diagnosticar problemas específicos de instância ### App Service Linux - [FAQs for App Service on Linux](https://learn.microsoft.com/en-us/troubleshoot/azure/app-service/faqs-app-service-linux-new?ref=azurebrasil.cloud) — Perguntas frequentes incluindo informações sobre Repair ### Reinício de Instâncias - [How to restart Azure App Service instance](https://stackoverflow.com/questions/36917229/how-to-restart-azure-app-service-instance?ref=azurebrasil.cloud) — Discussão sobre métodos para reiniciar instâncias específicas ### Post Anterior - [O Timeout que funcionava na minha máquina: como diagnosticamos SNAT Port Exhaustion no Azure](https://www.azurebrasil.cloud/blog/o-timeout-que-funcionava-na-minha-maquina-como-diagnosticamos-snat-port-exhaustion-no-azure/) — Parte 1: diagnóstico e solução com NAT Gateway *Já teve problemas com instâncias específicas do App Service? O Repair resolveu? Compartilhe sua experiência nos comentários.*