My IP address

macOS / Linux / Raspberry Pi / BSD

The most common terminal requirements are: output must be clean (one line you can copy/write/compare), and scripts must not hang. So the recommended defaults here include: silent mode (no noisy output) + HTTPS (avoid the wrong protocol) + timeouts when needed (avoid dead-hangs).

Basic usage (most recommended)

curl -4  my.ipin.io

C:\Users\admin>curl -4 my.ipin.io
171.83.40.149

• -s: Disable progress/notes to keep output pure (avoid noise in scripts).
• https://: Strongly recommended to include the full scheme, to avoid defaulting to http in some environments and causing redirects/interception/port policy issues.
• Root path /: Strictly outputs IPv4; it fails if IPv4 is unavailable (prevents mistaking IPv6 for IPv4).

Common variants (the most used set in real engineering)

# A1) IPv6 only (for validation/troubleshooting IPv6)

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

   # A2) Location brief (more readable text output in terminal)
   curl -s https://my.ipin.io/info

   # A3) Force JSON in terminal (change UA to non-curl)
   curl -s -A "Mozilla/5.0" https://my.ipin.io/info

   # A4) Force IPv4 / force IPv6 (troubleshoot which stack the system actually uses)
   curl -s -4 https://my.ipin.io
   curl -s -6 https://my.ipin.io/v6

   # A5) Add timeouts (script essential: avoid hanging on network jitter)
   curl -s --connect-timeout 3 --max-time 8 https://my.ipin.io

   # A6) Add retries (weak networks / occasional jitter: recommend 1–2)
   curl -s --retry 2 --connect-timeout 3 --max-time 8 https://my.ipin.io/info

Variant explanations (what you actually need to know)

• /v6: The endpoint returns IPv6 only; used to “explicitly verify whether IPv6 works.”
• /info: The endpoint returns IP + location fields; it’s more human-readable in terminal output, suitable for “visually confirming your egress.”
• -A "Mozilla/5.0": Output format control. By default, curl’s UA contains curl → the service returns text; change UA → the service returns JSON.
• -4/-6: Force the protocol stack at the connection layer (make the client connect only via v4/v6), often used to pinpoint “why I always end up on v6.”
• --connect-timeout: Controls only the “connection establishment” phase; slow handshakes/connections get cut off here.
• --max-time: Upper bound for total request time; the most important one in automation (prevents dead-hangs).
• --retry: Improves success rate, but keep retries small (1–2). Too many retries slow down jobs and amplify failures.

Android (Termux)

Common Termux issues: mobile networks are more jittery, paths are more complex, and protocol stack selection is less stable. So the default recommendation is: fixed stack + timeouts + retries when needed.

Basic usage (recommended)

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

Common variants

# B1) Location brief (quickly confirm egress location)
    curl -s https://my.ipin.io/info

    # B2) IPv6 verification (only when you explicitly want to test IPv6)
    curl -s -6 https://my.ipin.io/v6

    # B3) Weak network: a small number of retries
    curl -s --retry 2 --connect-timeout 5 --max-time 10 https://my.ipin.io

Variant explanations

• -4: If you explicitly want IPv4, lock it to avoid environments that prefer IPv6 causing result drift.
• /info: Mobile networks often switch egress points; this is the most straightforward way to confirm the location matches expectations.
• Retry strategy: Occasional timeouts are common on mobile networks; a small number of retries can significantly improve success rate.

Windows (CMD / PowerShell)

On Windows, it helps to separate use cases: CMD/batch is more about “getting a single line of text”; PowerShell is more about “getting JSON and parsing fields directly.”

Basic usage (one-line IP text)

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

Common variants

# C1) Location brief (terminal-readable)
    curl.exe -s https://my.ipin.io/info

    # C2) PowerShell fetch JSON (good for scripts that parse fields)
    Invoke-RestMethod -Uri "https://my.ipin.io/info"

    # C3) IPv6 verification
    curl.exe -s https://my.ipin.io/v6

    # C4) Connection troubleshooting (DNS, handshake, timeout reasons; verbose output)
    curl.exe -v https://my.ipin.io/info

Variant explanations

• Invoke-RestMethod: Great for JSON scenarios; saves you from manual parsing.
• -v: Use only for troubleshooting. It prints lots of debug info; don’t enable it by default in scripts.
• Common root causes: system proxy, corporate gateways, DNS rewriting, or hosts rules can make “the same command behave differently on different machines.”

iOS (iSH / Lightweight Terminals)

Lightweight terminals often only have wget. Note: wget’s default UA often does not include curl, so you often get JSON. If you want “one-line text”, you need to explicitly set the UA to trigger terminal text output.

Basic usage

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

Common variants

# D1) Location brief
    wget -qO- https://my.ipin.io/info

    # D2) Force plain text (one-line IP)
    wget -qO- -U "curl/8" https://my.ipin.io

    # D3) Force JSON (stable integration)
    wget -qO- -U "Mozilla/5.0" https://my.ipin.io/info

Variant explanations

• -qO-: Quiet + output to stdout, convenient for scripting.
• -U: The core switch for controlling output format (UA contains curl → text; UA is non-curl → JSON).

OpenWRT / Embedded Devices

The core goal on embedded devices is: do not hang. So you must set a timeout. When doing “public IP change detection”, you should also avoid false positives: a failed request does not mean the IP changed.

Basic usage (with timeout)

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

Common variants

# E1) Location brief (egress self-check)
    wget -qO- --timeout=10 https://my.ipin.io/info

    # E2) Force plain text (one-line IP)
    wget -qO- --timeout=10 -U "curl/8" https://my.ipin.io

Variant explanations

• --timeout: Strongly recommended as a default on embedded devices to prevent scheduled jobs from hanging.
• Stable output mode: wget may return JSON by default; if your script only wants one-line IP, using UA to trigger text output is more reliable.