> ## 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.

# IPs flutuantes

> Endereços virtuais públicos ou privados que se movem independentemente de uma NIC, com anexo direcionado a endereços e integridade de membros.

Um IP flutuante é um endereço IPv4 ou IPv6 alocado separadamente. Os endereços públicos vêm do pool público regional; os endereços privados vêm de uma sub-rede selecionada e permanecem dentro de sua VPC. Ambos traduzem para um endereço na NIC de destino, portanto, anexar ou mover um não reconfigura o convidado.

Um IP flutuante público não é alcançável simplesmente porque você o alocou. Alcançar uma instância da internet requer quatro coisas, e três delas não têm nada a ver com o endereço em si.

<Warning>
  **Alocar um IP flutuante e anexá-lo não é suficiente.** A sub-rede da instância também precisa de um gateway de internet conectado à VPC *e* uma rota `0.0.0.0/0` apontando para esse gateway. Sem a rota, o tráfego de resposta não tem para onde ir, e de fora parece exatamente como o pacote de entrada sendo descartado — então você passa a tarde depurando a direção errada.

  A API recusa o anexo por esse motivo, em vez de entregar um endereço morto.
</Warning>

<a id="the-reachability-chain" />

## A cadeia de alcançabilidade

```mermaid theme={null}
flowchart LR
  NET([Internet]) --> IGW["Internet gateway<br/>attached to the VPC"]
  IGW --> RT{"Subnet's route table<br/>0.0.0.0/0 → that gateway?"}
  RT -- no --> D1["Reply has no way out.<br/>Looks like inbound blackhole."]
  RT -- yes --> FIP["Floating IP<br/>attached to the NIC"]
  FIP --> SG{"Security group<br/>allows the port?"}
  SG -- no --> D2["Dropped at the interface"]
  SG -- yes --> VM([Instance])
```

<Steps>
  <Step title="Anexe um gateway de Internet à VPC">
    <Tabs>
      <Tab title="Console">
        Vá para **Networking → Internet Gateways** e escolha **Create Internet
        Gateway**. Um **Name** é tudo o que é necessário, e o gateway é "Criado separadamente; anexe-o a uma VPC da lista para começar a rotear o tráfego de saída".

        Abra-o e escolha **Attach**, escolha o **VPC** e confirme com **Attach**. **Status** muda de **Detached** para **Attached** e **Attached VPC** é preenchida.
      </Tab>

      <Tab title="API">
        ```bash theme={null}
        POST /v1/internet-gateways        { "name": "main" }
        POST /v1/internet-gateways/{id}/attach  { "vpc": "<vpc>" }
        ```
      </Tab>

      <Tab title="CLI">
        ```bash theme={null}
        basaltic network internet-gateway create --name main
        basaltic network internet-gateway attach <igw-id> --vpc <vpc-id>
        ```
      </Tab>

      <Tab title="Go">
        ```go theme={null}
        n := network.New(cfg)
        g, err := n.CreateInternetGateway(ctx, &network.InternetGatewayCreateRequest{
            Name: "main",
        })
        g, err = n.AttachInternetGateway(ctx, g.ID, &network.InternetGatewayAttachRequest{
            VPC: vpcID,
        })
        ```
      </Tab>
    </Tabs>

    A anexação não cria rotas. Ele só torna o gateway disponível como um destino de rota.
  </Step>

  <Step title="Adicionar a rota padrão à tabela de rotas da sub-rede">
    <Tabs>
      <Tab title="Console">
        Vá para **Networking → Route Tables** e abra a tabela que a sub-rede usa — a página da sub-rede a nomeia em **Route table**. Escolha **Add
        Route**, defina **Destination CIDR** para `0.0.0.0/0`, defina **Target type** para **Internet Gateway**, escolha o gateway em **Internet gateway** e confirme com **Add Route**.

        Se o seletor estiver vazio e disser "Nenhum IGW anexado a esta VPC. Anexe um primeiro.", você ainda está no passo anterior.
      </Tab>

      <Tab title="API">
        ```bash theme={null}
        POST /v1/route-tables/{route_table_id}/routes
        { "destination_cidr": "0.0.0.0/0", "target_internet_gateway": "<igw>" }
        ```
      </Tab>

      <Tab title="CLI">
        ```bash theme={null}
        basaltic network route create <route-table-id> \
          --destination-cidr 0.0.0.0/0 --target-internet-gateway <igw-id>
        ```
      </Tab>

      <Tab title="Go">
        ```go theme={null}
        r, err := network.New(cfg).CreateRoute(ctx, routeTableID, &network.RouteCreateRequest{
            DestinationCIDR:             "0.0.0.0/0",
            TargetInternetGateway: basaltic.String(gatewayID),
        })
        ```
      </Tab>
    </Tabs>

    Isso é o que torna a sub-rede pública. É também o que faz o caminho *reply* existir.
  </Step>

  <Step title="Anexe o IP flutuante à interface">
    <Tabs>
      <Tab title="Console">
        Vá para **Networking → Floating IPs**, escolha **Allocate Floating IP** se você não tiver um de reserva, então abra o endereço e escolha **Attach**. Escolha a NIC em **Interface**; seu endereço correspondente é selecionado como o destino. Confirme com **Attach
        floating IP**.

        O mesmo anexo está na NIC: abra-a em **Networking →
        Interfaces** e escolha **Attach floating IP**.
      </Tab>

      <Tab title="API">
        ```bash theme={null}
        POST /v1/floating-ips/{floating_ip_id}/attach
        { "interface": "<interface>", "address_id": "<address-id>" }
        ```
      </Tab>

      <Tab title="CLI">
        ```bash theme={null}
        basaltic network floating-ip attach <floating-ip-id> \
          --interface <interface-id> --address-id <address-id>
        ```
      </Tab>

      <Tab title="Go">
        ```go theme={null}
        fip, err := network.New(cfg).AttachFloatingIP(ctx, floatingIPID,
            &network.AttachFloatingIPRequest{Interface: interfaceID, AddressID: addressID})
        ```
      </Tab>
    </Tabs>

    Se a sub-rede não tiver uma rota padrão para um gateway de internet, isso falhará com `400`: "a sub-rede da interface não tem uma rota padrão (0.0.0.0/0) para um gateway de internet — anexe um gateway de internet à VPC e adicione uma rota padrão primeiro". O console mostra o mesmo texto sob **Failed to attach floating IP**.
  </Step>

  <Step title="Permitir o tráfego em um grupo de segurança">
    <Tabs>
      <Tab title="Console">
        Abra a NIC em **Networking → Interfaces** e escolha **Attach
        security group**. Suas regras "começam a filtrar o tráfego desta interface assim que ela é conectada".
      </Tab>

      <Tab title="API">
        ```bash theme={null}
        PUT /v1/interfaces/{interface_id}/security-groups
        { "security_groups": ["<sg>"] }
        ```
      </Tab>

      <Tab title="CLI">
        ```bash theme={null}
        basaltic network interface set-security-group <interface-id> \
          --security-groups <sg-id>
        ```
      </Tab>

      <Tab title="Go">
        ```go theme={null}
        groups, err := network.New(cfg).SetInterfaceSecurityGroups(ctx, interfaceID,
            &network.InterfaceSecurityGroupsRequest{
                SecurityGroups: []string{securityGroupID},
            })
        ```
      </Tab>
    </Tabs>

    Uma interface em nenhum grupo de segurança deixa cair tudo. [Grupos de segurança](/pt/networking/security-groups) cobre a postura padrão.
  </Step>
</Steps>

<Tip>
  **Create VPC** no console faz as duas primeiras etapas para você. Ative **Internet gateway** em **Internet access** e solicite pelo menos uma sub-rede pública, e o fluxo de trabalho executará **Create internet gateway**, **Attach
  internet gateway** e **Configure public internet route** como parte do provisionamento. O IP flutuante e o grupo de segurança ainda são seus para fazer depois.
</Tip>

<Note>
  O guarda corre em ambas as direções. Apagar a rota `0.0.0.0/0` enquanto os IPs flutuantes ainda dependem dela também é recusado: "não é possível apagar a rota padrão: *N* IP(s) flutuantes nas sub-redes desta tabela de rotas dependem dela para a acessibilidade à internet — desligue-os primeiro". Qualquer outra rota é excluída normalmente, e assim é a rota padrão uma vez que nada é anexado.
</Note>

<a id="allocating-an-address" />

## Atribuir um endereço

Escolha `visibility` (`public` por padrão ou `private`) e `family` (`ipv4` por padrão ou `ipv6`) na alocação. Estes valores são imutáveis. O endereço é atribuído pela plataforma. Uma alocação privada também requer `subnet`.

<Tabs>
  <Tab title="Console">
    Vá para **Networking → Floating IPs** e escolha **Allocate Floating IP**. Escolha **Visibility** e **Family** e selecione uma sub-rede para uma alocação privada. Adicione uma **Description** e **Tags** se desejar. Confirme com **Allocate IP**.
  </Tab>

  <Tab title="API">
    ```bash theme={null}
    POST /v1/floating-ips
    { "description": "web front door" }          # IPv4 (the default)
    { "description": "web front door", "family": "ipv6" }
    ```
  </Tab>

  <Tab title="CLI">
    ```bash theme={null}
    basaltic network floating-ip create --description "web front door"
    basaltic network floating-ip create --description "web front door" --family ipv6
    ```
  </Tab>

  <Tab title="Go">
    ```go theme={null}
    fip, err := network.New(cfg).CreateFloatingIP(ctx, &network.FloatingIPCreateRequest{
        Description: basaltic.String("web front door"),
        Family:      basaltic.Ptr(network.IPFamilyIPv6), // omit for IPv4
    })
    ```
  </Tab>
</Tabs>

Um endereço IPv4 conta contra sua cota `floating_ips_v4`, a mesma que um endereço de gateway NAT usa; um endereço IPv6 conta contra `floating_ips_v6`. Os dois são permissões separadas - um endereço v4 é uma parte do escasso bloco IPv4 da região, um v6 não é.

<a id="public-and-private-attachment" />

## Anexo público e privado

Leia o array `addresses` da NIC de destino e passe seu ID filho correspondente à família como `address_id` ao lado de `interface`. Uma NIC pode ter um IP flutuante público e um privado por família: no máximo quatro mapeamentos com os limites de endereço atuais. Um FIP IPv4 público e privado podem traduzir para o mesmo endereço IPv4 do convidado; o mesmo é verdadeiro para o IPv6.

O IPv4 público requer `0.0.0.0/0` para um gateway de internet. O IPv6 público requer `::/0` para um gateway de internet e um endereço IPv6 diretamente anexado. O NAT66 mapeia o FIP para o IPv6 primário `/128` da NIC, seja esse endereço global ou ULA. Novas conexões de saída desse endereço de destino usam o FIP público enquanto estão conectadas. Se o destino tiver um endereço IPv6 global, esse endereço nativo e o IP flutuante permanecerão acessíveis, sujeito às rotas da sub-rede e às regras do grupo de segurança. As respostas usam o endereço ao qual o cliente se conectou. Anexando ou desligando o FIP não requer alterações de endereço de convidado. Outros endereços globais dentro do `/96` da NIC mantêm seu roteamento nativo. O tráfego ULA não traduzido não pode sair para a internet pública.

Os FIPs privados não precisam de um gateway de internet. Sua sub-rede de alocação e NIC de destino devem estar na mesma VPC; eles podem estar em sub-redes diferentes. O endereço permanece reservado em sua sub-rede de alocação até ser liberado, inclusive enquanto estiver desconectado. Os mapeamentos privados traduzem o tráfego de entrada e suas respostas, sem substituir o endereço de origem da NIC para conexões de saída não relacionadas. Eles são úteis para identidades de serviço privadas e balanceadores de carga personalizados.

Desvincular remove o mapeamento, mas mantém a alocação. Não aloca um endereço público de substituição. O endereço do convidado permanece inalterado. Sem um FIP público, o IPv4 pode usar um gateway NAT, enquanto um endereço IPv6 global nativo pode usar sua rota de internet diretamente.

As verificações de integridade se aplicam a FIPs privados e públicos com suporte a NIC. Os endereços multimembro compartilhados permanecem gerenciados por meio de pools de instâncias; o endpoint de anexo de interface manual leva um membro.

<AccordionGroup>
  <Accordion title="Anexar" icon="link">
    <Tabs>
      <Tab title="Console">
        Abra um endereço não anexado e escolha **Attach**, em seguida, escolha a NIC em **Interface** e confirme com **Attach floating IP**. A mesma ação é na própria NIC, como **Attach floating IP** em **Networking → Interfaces**.
      </Tab>

      <Tab title="API">
        `POST /v1/floating-ips/{floating_ip_id}/attach` com `interface` (um UUID de interface ou CRN aninhado) e `address_id` (o ID de filho do endereço NIC correspondente).
      </Tab>

      <Tab title="CLI">
        ```bash theme={null}
        basaltic network floating-ip attach <floating-ip-id> \
          --interface <interface-id> --address-id <address-id>
        ```
      </Tab>

      <Tab title="Go">
        ```go theme={null}
        fip, err := network.New(cfg).AttachFloatingIP(ctx, floatingIPID,
            &network.AttachFloatingIPRequest{Interface: interfaceID, AddressID: addressID})
        ```
      </Tab>
    </Tabs>

    Re-conectar a uma NIC que já o possui é um sucesso sem operação.

    É recusado quando:

    * Um FIP público não tem uma rota de gateway de internet padrão em sua família (`400`);
    * um FIP privado e uma NIC de destino pertencem a VPCs diferentes (`400`);
    * o endereço de destino está ausente ou pertence à outra família (`400`);
    * a interface já possui um IP flutuante diferente na mesma família e visibilidade (`409`);
    * o endereço já tem um membro, então um segundo o tornaria um endereço anycast (`409`, veja abaixo);
    * o endereço está vinculado a um recurso que possui suas próprias vinculações, como um balanceador de carga ou um pool de instâncias — anexe e desconecte-o lá. O console não oferece **Attach** em tal endereço: sua interface **Attached interface** lê **Ligado por outro serviço** ou **No
      replica is serving it yet** para um pool.
  </Accordion>

  <Accordion title="Desconectar" icon="unlink">
    <Tabs>
      <Tab title="Console">
        Escolha **Detach** na página do endereço, ou **Detach floating IP** da página da NIC. Confirme com **Detach**. As ligações de pool e balanceador de carga devem ser gerenciadas por meio de seus proprietários.
      </Tab>

      <Tab title="API">
        `POST /v1/floating-ips/{floating_ip_id}/detach`. O corpo é opcional: um IP flutuante comum tem no máximo um membro. Omita `interface` para limpar a ligação, ou nomeie sua interface por UUID ou CRN aninhado. Nomes nulos, referências nulas e vazias são rejeitadas.
      </Tab>

      <Tab title="CLI">
        ```bash theme={null}
        basaltic network floating-ip detach <floating-ip-id>
        ```
      </Tab>

      <Tab title="Go">
        ```go theme={null}
        fip, err := network.New(cfg).DetachFloatingIP(ctx, floatingIPID,
            &network.DetachFloatingIPRequest{})
        ```
      </Tab>
    </Tabs>

    É idempotente. Separando um endereço já separado, ou nomeando uma NIC que não seja um membro, retorna `200` com a linha inalterada.
  </Accordion>

  <Accordion title="Liberação" icon="trash-2">
    <Tabs>
      <Tab title="Console">
        **Release floating IP**, na guia **Settings** do endereço.
      </Tab>

      <Tab title="API">
        `DELETE /v1/floating-ips/{floating_ip_id}`
      </Tab>

      <Tab title="CLI">
        ```bash theme={null}
        basaltic network floating-ip delete <floating-ip-id>
        ```
      </Tab>

      <Tab title="Go">
        ```go theme={null}
        err := network.New(cfg).DeleteFloatingIP(ctx, floatingIPID)
        ```
      </Tab>
    </Tabs>

    De qualquer forma, o endereço volta para a pool. Recusado com `409` enquanto ainda estiver anexado ou enquanto pertencer a um pool de instâncias. Desconecte primeiro.
  </Accordion>
</AccordionGroup>

<a id="reading-the-bindings" />

## Lendo as ligações

`attached_to` identifica o proprietário do anexo pelo seu CRN canônico. É `null` somente quando o endereço não está anexado. Uma ligação de interface nomeia o CRN da interface aninhada; uma ligação de pool ou de balanceador de carga nomeia esse recurso. Um pool vazio ainda possui seu endereço: `members: []` não significa que ele é livre para anexar ou liberar. Gerencie as ligações de pool por meio dos [pontos finais de pool](/pt/compute/instance-pools#one-address-for-the-whole-pool).

`members` descreve as ligações atuais, não a propriedade. Cada membro tem
`interface`, `address_id`, `health`, `reason` e `created_at`. O embutido `interface`
contém `id`, `crn` e um nullable `instance` Resumo (`id`, `crn`, `name`). Uma interface sem uma instância proprietária tem `instance: null`. Os membros do balanceador de carga têm `interface: null`; use o CRN do proprietário de nível superior para identificar o balanceador de carga.Verifique se há null antes de seguir qualquer um dos resumos.

Estes trechos de `GET /v1/floating-ips/{floating_ip_id}` ilustram os campos de anexo dentro de `floating_ip`; outros campos são omitidos.

Uma ligação de interface comum:

```json theme={null}
{
  "attached_to": "crn:network:sa-saopaulo-1:my-account:vpc/prod/subnet/public/interface/eth0",
  "members": [{
    "interface": {
      "id": "b9e4c7a2-1f8d-4a3b-9c6e-2d5a8b1f4c7e",
      "crn": "crn:network:sa-saopaulo-1:my-account:vpc/prod/subnet/public/interface/eth0",
      "instance": {
        "id": "550e8400-e29b-41d4-a716-446655440000",
        "crn": "crn:compute:sa-saopaulo-1:my-account:instance/web",
        "name": "web"
      }
    },
    "health": "unknown",
    "reason": "unprobed",
    "created_at": "2026-09-01T12:00:00Z"
  }]
}
```

Um pool sem membros atuais mantém sua propriedade:

```json theme={null}
{
  "attached_to": "crn:compute:sa-saopaulo-1:my-account:instance-pool/web",
  "members": []
}
```

À medida que as réplicas se juntam, os `members` do pool contêm a mesma interface incorporada e resumos de instância como uma ligação comum. O proprietário continua a ser a pool CRN.

Um endereço não anexado:

```json theme={null}
{"attached_to": null, "members": []}
```

Uma ligação de balanceador de carga:

```json theme={null}
{
  "attached_to": "crn:loadbalancer:sa-saopaulo-1:my-account:load-balancer/web",
  "members": [{
    "interface": null,
    "health": "healthy",
    "reason": "passing",
    "created_at": "2026-09-01T12:00:00Z"
  }]
}
```

<a id="filter-by-attachment-owner" />

### Filtrar por proprietário do anexo

Passe um CRN canônico exato para `attached_to` em `GET /v1/floating-ips`. Por exemplo, isso lista os endereços de um pool, mesmo quando o pool não tem membros:

```http theme={null}
GET /v1/floating-ips?attached_to=crn:compute:sa-saopaulo-1:my-account:instance-pool/web&limit=50
```

O filtro é aplicado antes da paginação e intersecta com outros filtros. Enquanto `meta.has_more` for true, passe `meta.marker` como `marker` na próxima requisição, preservando `attached_to` e os outros filtros. Um CRN mal formado, um valor vazio ou um CRN de interface plana retorna `400`. Um CRN bem formado para outra conta, região ou tipo de recurso não suportado retorna uma página vazia. O filtro não aceita UUIDs, nomes nulos ou `null` para selecionar endereços livres; lista endereços e seleciona aqueles cujo `attached_to` é nulo.

Com a CLI liberada, use o comando singular canônico e `--all` para percorrer todas as páginas correspondentes:

```bash theme={null}
basaltic network floating-ip list --attached-to 'crn:compute:sa-saopaulo-1:my-account:instance-pool/web' --all
```

Com o Go SDK, passe o mesmo filtro para `ListFloatingIPs`:

```go theme={null}
page, err := network.New(cfg).ListFloatingIPs(ctx, &network.ListFloatingIPsParams{
    AttachedTo: "crn:compute:sa-saopaulo-1:my-account:instance-pool/web",
})
```

Isso retorna uma página. Preserve `AttachedTo` ao definir `Marker` para a próxima página; alternativamente, o iterador `ListFloatingIPsAll` do SDK percorre todas as páginas para você.

O SDK representa JSON `attached_to: null` como uma cadeia vazia `AttachedTo`.

<a id="understand-member-health" />

### Entenda a saúde do membro

| Estado | Significado | Recebe tráfego? |
| - | - | - |
| `unknown` | Nenhuma verificação está em execução; membros comuns anexados à mão sem uma verificação de integridade usam esse estado. | Sim |
| `healthy` | O convidado está ativo e qualquer verificação de prontidão configurada passa. | Sim |
| `unhealthy` | A instância ainda não confirmou que está ativa ou uma verificação de prontidão está falhando. | Não |

`reason` explica o estado: `unprobed` significa nenhuma verificação, `booting` significa que o convidado ainda não foi alcançado, `probe_failed` significa que uma verificação configurada está falhando, e `passing` significa que o convidado está ativo e qualquer verificação configurada passa. Um membro sem integridade permanece em `members`; fazer parte do grupo não significa estar pronto para receber tráfego. Sem `health_check`, healthy indica se o sistema da instância está ativo, não a prontidão da aplicação. Veja [solução de problemas de saúde](/pt/networking/troubleshooting#attachment-and-health-fields).

<a id="one-address-in-front-of-several-instances" />

## Um endereço na frente de várias instâncias

Um endereço com mais de um membro é um endereço anycast, e somente um [instance pool](/pt/compute/instance-pools) pode possuir um. Anexando uma segunda interface à mão é recusado com `409`.

Um pool mantém a associação em ritmo à medida que ela escala. Todas as réplicas ativas podem ingressar, incluindo réplicas que compartilham um host; o posicionamento afeta a capacidade e a resiliência, não se um membro pode receber tráfego. Membros que ainda estão inicializando podem aparecer na lista como não funcionando antes de receberem tráfego.

<Tabs>
  <Tab title="Console">
    Abra o pool em **Compute → Instance pools**, vá para a guia **Floating
    IPs** e escolha **Attach floating IP**. O desvinculamento é a ação **Detach floating IP** da linha na mesma guia.

    A própria página do endereço não permitirá que você faça isso — um endereço que um pool possui não oferece nenhum botão **Attach**, e sua interface **Attached interface** lê **No replica is serving it yet** até que uma réplica o pegue. Use **Attachment owner** para abrir o pool de proprietários ou o balanceador de carga; se o proprietário não puder ser resolvido, seu CRN permanecerá visível. A guia **Interfaces** mostra identidades de membros incorporadas, **Health** e **Reason**, sem controles de membros manuais. Um pool vazio permanece anexado.
  </Tab>

  <Tab title="API">
    ```bash theme={null}
    POST   /v1/instance-pools/{pool_id}/floating-ips
    { "floating_ip": "<floating-ip-id-or-crn>" }
    DELETE /v1/instance-pools/{pool_id}/floating-ips/{floating_ip_id}
    ```
  </Tab>

  <Tab title="CLI">
    ```bash theme={null}
    basaltic compute instance-pool attach-floating-ip <pool-id> \
      --floating-ip <floating-ip-id>
    basaltic compute instance-pool detach-floating-ip <pool-id> <floating-ip-id>
    ```
  </Tab>

  <Tab title="Go">
    ```go theme={null}
    c := compute.New(cfg)
    fip, err := c.AttachInstancePoolFloatingIP(ctx, poolID,
        &compute.InstancePoolFloatingIPAttachRequest{FloatingIP: floatingIPID})
    err = c.DetachInstancePoolFloatingIP(ctx, poolID, floatingIPID)
    ```
  </Tab>
</Tabs>

Com vários membros saudáveis, novas conexões são distribuídas entre eles. Os endereços de pool privado ficam dentro de sua VPC. Os endereços de pool público requerem roteamento de Internet na família selecionada. As conexões já estabelecidas com um membro não são migradas quando esse membro desaparece.

<Warning>
  Um endereço compartilhado não termina TLS ou roteia solicitações HTTP. Sem um `health_check` configurado, a saúde do membro indica apenas se o sistema da instância está ativo. Conexões em andamento para um membro que vai embora terminam em vez de se mover.
</Warning>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.