Meu Endereço IP

- Determinando a localização... Para visualizar as informações do seu IP real (visitante), clique aqui

Uso do terminal e do ambiente do sistema

Fale apenas sobre como usar o terminal: para cada “variante comum”, forneça o comando + explique qual problema ele resolve (pilha de protocolos, formato de saída, timeouts, retries, significado do caminho).

macOS / Linux / Raspberry Pi / BSD

As necessidades mais comuns no terminal são: a saída precisa ser limpa (uma linha copiável/gravável/comparável) e scripts não podem travar. Por isso, a forma recomendada aqui inclui por padrão: modo silencioso (não poluir a saída) + HTTPS (evitar usar o protocolo errado) + timeouts quando necessário (evitar ficar pendurado).

Uso básico (o mais recomendado)

curl -4  my.ipin.io
Prompt de Comando
C:\Users\admin>curl -4 my.ipin.io
171.83.40.149
  • -s: Desliga barra de progresso/avisos para deixar a saída mais “pura” (evita ruído em scripts).
  • https://: Recomenda-se fortemente escrever o esquema completo para evitar que alguns ambientes usem http por padrão e causem redirecionamento/interceptação/problemas de política de portas.
  • Caminho raiz /: Saída estrita de IPv4; se não conseguir IPv4, falha (evita confundir IPv6 com IPv4).

Variantes comuns (o conjunto mais usado em engenharia real)

# A1) Apenas IPv6 (para validar/diagnosticar IPv6)

   curl -s https://my.ipin.io/v6

   # A2) Resumo de localização (saída de texto mais legível no terminal)
   curl -s https://my.ipin.io/info

   # A3) Forçar JSON no terminal (mudar o UA para não-curl)
   curl -s -A "Mozilla/5.0" https://my.ipin.io/info

   # A4) Forçar IPv4 / forçar IPv6 (diagnosticar qual pilha o sistema realmente usa para conectar)
   curl -s -4 https://my.ipin.io
   curl -s -6 https://my.ipin.io/v6

   # A5) Adicionar timeouts (essencial em scripts: evita travar por oscilações de rede)
   curl -s --connect-timeout 3 --max-time 8 https://my.ipin.io

   # A6) Adicionar retries (rede fraca / oscilação ocasional: recomendado 1–2)
   curl -s --retry 2 --connect-timeout 3 --max-time 8 https://my.ipin.io/info

Explicação das variantes (o que você realmente precisa saber)

  • /v6: No nível do endpoint, retorna apenas IPv6; usado para “verificar claramente se o IPv6 está disponível”.
  • /info: No nível do endpoint, retorna IP + campos de localização; saída mais voltada à leitura no terminal, adequada para “confirmar visualmente o egress”.
  • -A "Mozilla/5.0": Controle do formato de saída. Por padrão, o UA do curl contém curl → o serviço retorna texto; ao mudar o UA → o serviço retorna JSON.
  • -4/-6: Força a pilha de protocolos no nível de conexão (o cliente conecta apenas via v4/v6), comumente usado para localizar “por que eu sempre acabo no v6”.
  • --connect-timeout: Controla apenas a fase de “estabelecer conexão”; handshake/conexão lenta é interrompida aqui.
  • --max-time: Limite de tempo total da requisição; o mais importante em automação (evita travar).
  • --retry: Aumenta a taxa de sucesso, mas recomenda-se poucos retries (1–2). Muitos retries deixam a tarefa lenta e ampliam falhas.

Android (Termux)

Problemas comuns no Termux: a rede móvel oscila mais, o caminho é mais complexo e a escolha de pilha de protocolos é mais instável. Por isso, recomenda-se por padrão: pilha fixa + timeouts + retries quando necessário.

Uso básico (recomendado)

curl -s -4 --connect-timeout 5 --max-time 10 https://my.ipin.io

Variantes comuns

# B1) Resumo de localização (confirmar rapidamente a localização de saída)
    curl -s https://my.ipin.io/info

    # B2) Verificação de IPv6 (somente quando você quiser testar IPv6 explicitamente)
    curl -s -6 https://my.ipin.io/v6

    # B3) Rede fraca: poucos retries
    curl -s --retry 2 --connect-timeout 5 --max-time 10 https://my.ipin.io

Explicação das variantes

  • -4: Se você quer IPv4 explicitamente, fixe-o para evitar que o ambiente priorize IPv6 e o resultado “derive”.
  • /info: Mudanças de egress são comuns no móvel; usar isso para confirmar a localização esperada é o mais direto.
  • Estratégia de retries: Timeouts ocasionais são comuns em redes móveis; poucos retries podem aumentar muito a taxa de sucesso.

Windows (CMD / PowerShell)

No Windows, vale separar bem o objetivo: CMD/batch é mais para “pegar uma linha de texto”; PowerShell é mais para “pegar JSON e analisar campos diretamente”.

Uso básico (texto: IP em uma linha)

curl.exe -s https://my.ipin.io

Variantes comuns

# C1) Resumo de localização (legível no terminal)
    curl.exe -s https://my.ipin.io/info

    # C2) PowerShell pega JSON (bom para scripts analisarem campos)
    Invoke-RestMethod -Uri "https://my.ipin.io/info"

    # C3) Verificação de IPv6
    curl.exe -s https://my.ipin.io/v6

    # C4) Diagnosticar conexão (ver DNS, handshake, motivo de timeout; saída longa)
    curl.exe -v https://my.ipin.io/info

Explicação das variantes

  • Invoke-RestMethod: Ideal para cenários JSON; evita parsing manual.
  • -v: Só para diagnóstico. Ele imprime muita informação de debug; não habilite por padrão em scripts.
  • Fontes comuns de problema: proxy do sistema, gateway corporativo, reescrita de DNS, regras de hosts podem fazer “o mesmo comando” ter comportamentos diferentes em máquinas diferentes.

iOS (iSH / Terminais leves)

Terminais leves muitas vezes só têm wget. Atenção: o UA padrão do wget geralmente não contém curl, então muitas vezes você recebe JSON. Se você quer “texto em uma linha”, precisa definir o UA explicitamente para acionar a saída de texto para terminal.

Uso básico

wget -qO- https://my.ipin.io

Variantes comuns

# D1) Resumo de localização
    wget -qO- https://my.ipin.io/info

    # D2) Forçar texto puro (IP em uma linha)
    wget -qO- -U "curl/8" https://my.ipin.io

    # D3) Forçar JSON (integração estável)
    wget -qO- -U "Mozilla/5.0" https://my.ipin.io/info

Explicação das variantes

  • -qO-: Silencioso + saída para stdout, facilita processamento em scripts.
  • -U: A chave central de controle do formato de saída (UA contém curl → texto; UA não contém curl → JSON).

OpenWRT / Dispositivos embarcados

O objetivo central em dispositivos embarcados é: não travar. Então é obrigatório definir timeouts. Em “detecção de mudança de IP público”, também evite falsos positivos: falha de requisição não significa que o IP mudou.

Uso básico (com timeout)

wget -qO- --timeout=10 https://my.ipin.io

Variantes comuns

# E1) Resumo de localização (autoinspeção do egress)
    wget -qO- --timeout=10 https://my.ipin.io/info

    # E2) Forçar texto puro (IP em uma linha)
    wget -qO- --timeout=10 -U "curl/8" https://my.ipin.io

Explicação das variantes

  • --timeout: Em embarcados, recomenda-se fortemente usar por padrão para evitar que tarefas agendadas travem.
  • Formato de saída estável: o wget pode retornar JSON por padrão; se seu script só quer um IP em uma linha, acionar texto via UA é mais estável.

Docker / CI / Tarefas automatizadas

Em automação a incerteza é maior: variações de DNS, timeouts curtos e mudanças de política de egress são mais comuns. Recomendação por padrão: timeouts + poucos retries + formato de saída fixo (evita que o parsing quebre em runners diferentes).

Uso básico (com timeouts)

curl -s --connect-timeout 3 --max-time 8 https://my.ipin.io

Variantes comuns (as mais úteis no CI)

# F1) Buscar localização de forma estável (com retries)
    curl -s --retry 2 --connect-timeout 3 --max-time 8 https://my.ipin.io/info

    # F2) CI quer JSON estável: fixar UA como não-curl
    curl -s -A "Mozilla/5.0" --connect-timeout 3 --max-time 8 https://my.ipin.io/info

    # F3) Diagnóstico: forçar pilha de protocolos
    curl -s -4 https://my.ipin.io
    curl -s -6 https://my.ipin.io/v6

Explicação das variantes

  • Fixar UA: no CI, imagens/ferramentas diferentes podem ter UAs diferentes; fixando, o formato de saída não “deriva”.
  • Poucos retries: melhora o sucesso, mas as falhas precisam aparecer rápido (para facilitar a análise).

Perguntas frequentes (FAQ)

Q1: Eu uso curl -s https://my.ipin.io — por que às vezes falha ou retorna erro?

O caminho raiz é “IPv4 estrito”: se o caminho atual não consegue obter IPv4, ele falha explicitamente (em vez de “fingir” sucesso com IPv6). Isso geralmente acontece em: redes IPv6-only, certos ambientes de proxy/gateway, ou quando seu cliente é forçado a usar IPv6 e não há IPv4 utilizável no caminho.

Como diagnosticar: use curl -s -4 para forçar IPv4; ou use /info para ver qual é o IP de saída atual e decidir o próximo passo.

Q2: Eu faço uma requisição curl para /info — por que não é JSON?

Porque ferramentas de terminal usam por padrão o “modo de saída de terminal”, e /info nesse modo imprime uma caixa de texto mais legível. Se você quer JSON (para jq/parsing por programa), basta trocar o UA para não-curl.

curl -s -A "Mozilla/5.0" https://my.ipin.io/info

Q3: Por que o mesmo comando tem formatos de saída diferentes em máquinas diferentes?

O formato de saída depende do User-Agent da requisição. Ferramentas diferentes (curl / wget / ferramentas do sistema) podem ter UAs padrão diferentes, o que leva a diferenças entre retorno em texto e JSON.

Solução: fixar o UA. Se você quer texto, faça o UA conter curl; se quer JSON, faça o UA não conter curl. Para automação/CI, fixar o UA é a chave para “parsing estável”.

Q4: Por que eu claramente quero IPv4, mas sinto que “saí pelo IPv6”?

Aqui é importante diferenciar duas coisas: a pilha de protocolos usada ao conectar (o cliente escolhe v4/v6 para conectar), e o tipo de IP retornado pelo endpoint (definido pelo caminho / ou /v6).

Sugestão de diagnóstico: use -4/-6 para forçar a pilha de conexão e confirmar qual caminho sua rede realmente prefere. Se você quer apenas IPv4, use o caminho raiz e force -4 quando necessário.

Q5: Como eu devo escrever em scripts para evitar falsos positivos e não travar?

Combinação recomendada: silencioso (evitar ruído), timeouts (evitar travar), poucos retries (resistir a oscilações), e não sobrescrever o valor antigo em caso de falha (não tratar falha como mudança).

curl -s --retry 2 --connect-timeout 3 --max-time 8 https://my.ipin.io

Q6: Eu devo priorizar curl ou wget?

Se puder usar curl, use curl: opções mais ricas e melhor para diagnóstico. Mas em ambientes leves/embarcados é comum ter apenas wget; wget está totalmente ok. O ponto-chave é: definir timeouts, enviar a saída para stdout e, se necessário, fixar o UA para travar o formato de saída.