> ## Documentation Index > Fetch the complete documentation index at: https://docs.basaltic.sh/llms.txt > Use this file to discover all available pages before exploring further. # Cotas e solução de problemas > Diferencie um problema de roteamento de um problema de filtragem, o que cada recusa está protegendo, a ordem em que as coisas têm que se separar e as cotas. ## O silêncio tem duas causas Um pacote que nunca chega parece idêntico se a rota estiver faltando ou o grupo de segurança o descartou. De fora não há diferença alguma, e é por isso que "verificar o grupo de segurança" é o primeiro movimento errado na metade das vezes. Os dois falham de forma diferente no *outro* lado, e esse é o tell: **Outbound da instância também falha.** A resposta a um pacote de entrada não tem saída, então nada funciona em qualquer direção - `curl` de dentro da instância também trava. Verifique a tabela de rotas da sub-rede para uma entrada `0.0.0.0/0` (ou `::/0`) e confirme que ela tem como alvo um gateway que está conectado a *esta* VPC. Veja [routing](/pt/networking/routing). **A saída da instância ainda funciona**, porque um novo grupo permite toda a saída por padrão. Apenas a porta de entrada específica é silenciada. Verifique os grupos da interface, e lembre-se que uma interface em **no** grupo deixa tudo cair. Consulte [grupos de segurança](/pt/networking/security-groups). Um terceiro caso parece com ambos: **IPv6 funciona sobre v4 e falha sobre v6**. A regra de saída padrão com a qual um novo grupo de segurança começa é apenas IPv4, portanto, uma instância de pilha dupla pode ter v4 amplamente aberto e nenhuma saída `::/0`. Adicione uma regra de saída `ipv6` explicitamente. ## O que cada recusa está protegendo Cada um deles é uma proteção contra deixar algo apontando para nada. A mensagem nomeia o bloqueador; é isso que ele está defendendo. | Você tentou | Ele se recusa quando | Porque | | - | - | - | | Anexar um IP flutuante | a sub-rede não tem rota padrão para um gateway de internet | o endereço estaria morto na chegada, e pareceria um problema de filtragem | | Excluir a rota `0.0.0.0/0` | IPs flutuantes nas sub-redes da tabela dependem dela | que silenciosamente alcançaria cada um deles | | Anexar um segundo IP flutuante a uma NIC | um já está anexado | um NIC tem uma identidade pública | | Anexar uma segunda interface a um endereço | já tem um membro | ver [anycast](/pt/networking/floating-ips#one-address-in-front-of-several-instances) | | Libere um IP flutuante | ainda está anexado, ou um pool é dono dele | o proprietário perderia um endereço abaixo dele | | Desconectar ou excluir um gateway | uma rota ainda o direciona | a rota não apontaria para nada | | Excluir a sub-rede de um gateway NAT | o portal vive lá | mesmo | | Excluir uma interface | uma instância ou IP flutuante o mantém | excluí-lo iria quebrar o anexo, mesmo se a instância é interrompida | | Excluir uma VPC | sub-redes permanecem, ou um gateway é anexado | mesmo | | Excluir uma sub-rede | interfaces permanecem, um gateway NAT vive lá, ou outro recurso detém um endereço nele | o terceiro é o surpreendente: um VIP de balanceador de carga fica na sua sub-rede sem ser uma interface | | Excluir um grupo de segurança | uma interface ainda pertence a ele | que a interface silenciosamente perderia suas regras | | Excluir uma tabela de rotas | é `main`, ou sub-redes ainda o usam | sub-redes não teriam roteamento | | Adicionar uma segunda rota para o mesmo destino | um já existe | não há nenhum par de igual custo aqui | Adicionando uma segunda rota para o mesmo destino retorna `409`. Nenhuma rota é criada e a existente permanece intacta. ## Campos de apego e saúde `attached_to` contém o UUID da instância proprietária, ou nulo quando nenhuma instância possui a interface. Parar uma instância não libera suas NICs. `DELETE /v1/interfaces/{interface_id}` recusa enquanto uma instância de vinculação ou um IP flutuante mantém a interface. Desconecte-o da instância e desconecte qualquer IP flutuante primeiro. Liste as NICs da instância na API [compute](/pt/compute) para gerenciar seus anexos. `unknown` significa que ninguém está verificando esse membro — o padrão para um que você anexou sem `health_check` no endereço. Ele permanece anunciado. Configure um `health_check` no IP flutuante (a mesma forma de um grupo alvo de balanceador de carga: protocolo, caminho, porta, intervalo, tempo limite, limiares saudáveis/não saudáveis, correspondência) e o `health` de cada membro reflete isso: `healthy` enquanto a verificação passa, `unhealthy` enquanto falha, e o `reason` do membro diz por que — `passing`, `probe_failed` (o serviço não está respondendo), `booting` (o convidado ainda não foi alcançado), ou `unprobed` (sem verificação). Um membro não saudável é retirado do endereço; se todos os membros falharem, o endereço deixa de encaminhar tráfego, então uma verificação mal configurada é uma interrupção visível, em vez de a plataforma anunciar algo que acredita estar inativo. Leia o `attached_to` de um IP flutuante para propriedade: nulo significa não anexado; caso contrário, ele nomeia a interface, o pool de instâncias ou o balanceador de carga pelo CRN. Um pool vazio ainda pode possuir um endereço com `members: []`. Os resumos da interface de membro e da instância podem ser nulos; consulte [Lendo as ligações](/pt/networking/floating-ips#reading-the-bindings). Sem uma verificação de prontidão, a saúde de um membro do pool reflete se o sistema da instância está ativo. Uma réplica que ainda está inicializando permanece na lista sem integridade e não recebe tráfego até ser admitida. Esse estado, por si só, não comprova que a aplicação está pronta. ## Destruindo-o na ordem certa Cada uma dessas recusas existe porque a etapa anterior foi ignorada. Trabalhando para dentro: Release se recusa enquanto estiver anexado, e o default-route delete se recusa enquanto qualquer IP flutuante nas sub-redes da tabela estiver ativo. Cada tipo de gateway se recusa a desacoplar e excluir enquanto uma rota ainda faz referência a ele. Um gateway NAT também bloqueia a exclusão da sub-rede em que ele reside. Um gateway anexado também bloqueia a exclusão da VPC. Desconecte cada interface de sua instância primeiro — veja [interfaces](/pt/networking/interfaces). O console pode fazer essa caminhada para você. **Excluir VPC** abre uma página de plano que descobre tudo dentro da VPC, mostra a ordem e trabalha com ela, que é a mesma ordem acima, porque é o mesmo conjunto de guardas. ## Cotas Seis cotas regionais se aplicam à sua organização. Os nomes abaixo são o que a API [quota](/pt/billing) e o console relatam, e vários não correspondem ao nome do recurso: | Quota de participação | Contas | | - | - | | `networks` | VPCs | | `subnets` | sub-redes | | `ports` | interfaces | | `routers` | tabelas de rotas | | `security_groups` | grupos de segurança | | `floating_ips_v4` | IPs flutuantes IPv4 **e endereços de gateway NAT** | | `floating_ips_v6` | IPv6 IPs flutuantes | Os IPs flutuantes e os endereços de gateway NAT se baseiam no IPv4 público. **mesmo** `floating_ips_v4` Assim, um gateway NAT custa um IP flutuante de quota e uma quota completa bloqueia ambos. `rules_per_security_group` é uma quota **por-recurso**: ela limita as regras em cada grupo individual, não o total entre eles. Bater em um grupo não diz nada sobre os outros. Nada cobra cota para os próprios gateways, para rotas ou para associações de tabela de rotas. Um gateway de internet e um gateway somente de saída são gratuitos; um gateway NAT é cobrado pelo endereço, não por ser um gateway.