Meine IP-Adresse

- Standort wird ermittelt... Um die echte IP-Adresse des Besuchers zu sehen, klicken Sie hier

Terminal- und Systemumgebungsnutzung

Nur erklären, wie man das Terminal nutzt: Für jede „gängige Variante“ jeweils den Befehl angeben + erklären, welches Problem er löst (Protokoll-Stack, Ausgabeformat, Timeouts, Retries, Bedeutung des Pfads).

macOS / Linux / Raspberry Pi / BSD

Die häufigsten Anforderungen im Terminal sind: Die Ausgabe muss sauber sein (eine Zeile zum Kopieren/Schreiben/Vergleichen) und Skripte dürfen nicht hängen bleiben. Deshalb enthalten die Empfehlungen hier standardmäßig: Silent-Modus (keine „verschmutzte“ Ausgabe) + HTTPS (nicht das falsche Protokoll) + je nach Bedarf Timeouts (kein Festhängen).

Grundnutzung (am meisten empfohlen)

curl -4  my.ipin.io
Eingabeaufforderung
C:\Users\admin>curl -4 my.ipin.io
171.83.40.149
  • -s: Fortschrittsbalken/Hinweise deaktivieren, damit die Ausgabe „rein“ bleibt (in Skripten kein Rauschen).
  • https://: Sehr empfehlenswert, das vollständige Schema zu schreiben, um zu vermeiden, dass manche Umgebungen standardmäßig http nutzen und dadurch Redirects/Abfangen/Port-Policy-Probleme entstehen.
  • Root-Pfad /: Gibt strikt IPv4 aus; wenn kein IPv4 verfügbar ist, schlägt es fehl (verhindert, dass IPv6 fälschlich als IPv4 genutzt wird).

Gängige Varianten (die meistgenutzte Gruppe in der Praxis)

# A1) Nur IPv6 (zum Verifizieren/Debuggen von IPv6)

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

   # A2) Standort-Kurzinfo (besser lesbare Textausgabe im Terminal)
   curl -s https://my.ipin.io/info

   # A3) Im Terminal JSON erzwingen (User-Agent auf nicht-curl setzen)
   curl -s -A "Mozilla/5.0" https://my.ipin.io/info

   # A4) IPv4 erzwingen / IPv6 erzwingen (prüfen, welchen Protokoll-Stack das System tatsächlich nutzt)
   curl -s -4 https://my.ipin.io
   curl -s -6 https://my.ipin.io/v6

   # A5) Timeouts setzen (Skript-Pflicht: verhindert Hängen bei Netzwerk-Jitter)
   curl -s --connect-timeout 3 --max-time 8 https://my.ipin.io

   # A6) Retries setzen (schwaches Netz/kurzer Jitter: 1–2 empfohlen)
   curl -s --retry 2 --connect-timeout 3 --max-time 8 https://my.ipin.io/info

Erklärung der Varianten (die Punkte, die du wirklich wissen musst)

  • /v6: Gibt auf Endpoint-Ebene nur IPv6 zurück; zur „eindeutigen Verifikation, ob IPv6 verfügbar ist“.
  • /info: Gibt auf Endpoint-Ebene IP + Standortfelder zurück; im Terminal eher „lesbare Ausgabe“, gut zum „visuellen Bestätigen des Egress“.
  • -A "Mozilla/5.0": Ausgabeformat-Steuerung. Standardmäßig enthält curl-UA „curl“ → Service liefert Text; UA ändern → Service liefert JSON.
  • -4/-6: Erzwingt auf Verbindungsebene den Protokoll-Stack (Client verbindet nur über v4/v6), häufig zur Diagnose „warum gehe ich immer über v6“.
  • --connect-timeout: Gilt nur für die Phase „Verbindung aufbauen“; langsamer Handshake/Connect wird hier abgebrochen.
  • --max-time: Obergrenze für die Gesamtdauer der Anfrage; in Automatisierung am wichtigsten (verhindert Festhängen).
  • --retry: Erhöht die Erfolgsquote, aber nur wenige Retries (1–2) sind sinnvoll. Zu viele Retries verlangsamen Jobs und verstärken Störungen.

Android (Termux)

Häufige Termux-Probleme: Mobilfunk ist stärker schwankend, die Route ist komplexer, und die Protokoll-Stack-Auswahl ist instabiler. Daher Empfehlung als Standard: Stack fixieren + Timeouts + bei Bedarf Retries.

Grundnutzung (empfohlen)

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

Gängige Varianten

# B1) Standort-Kurzinfo (Egress-Position schnell prüfen)
    curl -s https://my.ipin.io/info

    # B2) IPv6-Verifikation (nur wenn du ausdrücklich IPv6 testen willst)
    curl -s -6 https://my.ipin.io/v6

    # B3) Schwaches Netz: wenige Retries
    curl -s --retry 2 --connect-timeout 5 --max-time 10 https://my.ipin.io

Erklärung der Varianten

  • -4: Wenn du eindeutig IPv4 willst, fixiere es, damit IPv6-Priorität der Umgebung nicht zu „driftenden“ Ergebnissen führt.
  • /info: Mobilfunk wechselt häufig den Egress; damit prüfst du am direktesten, ob der Standort den Erwartungen entspricht.
  • Retry-Strategie: Gelegentliche Timeouts sind im Mobilfunk üblich; wenige Retries erhöhen die Erfolgsquote deutlich.

Windows (CMD / PowerShell)

Unter Windows lohnt es sich, den Zweck zu trennen: CMD/Batch ist eher „eine Textzeile holen“; PowerShell ist eher „JSON holen und Felder direkt parsen“.

Grundnutzung (Text: eine IP-Zeile)

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

Gängige Varianten

# C1) Standort-Kurzinfo (terminal-lesbar)
    curl.exe -s https://my.ipin.io/info

    # C2) PowerShell holt JSON (gut für Skripte, die Felder parsen)
    Invoke-RestMethod -Uri "https://my.ipin.io/info"

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

    # C4) Verbindungs-Diagnose (DNS, Handshake, Timeout-Gründe; lange Ausgabe)
    curl.exe -v https://my.ipin.io/info

Erklärung der Varianten

  • Invoke-RestMethod: Ideal für JSON-Szenarien, spart dir manuelles Parsen.
  • -v: Nur zur Diagnose. Gibt viele Debug-Infos aus; in Skripten nicht standardmäßig aktivieren.
  • Häufige Ursachen: System-Proxy, Unternehmens-Gateway, DNS-Umschreiben oder hosts-Regeln führen dazu, dass „derselbe Befehl“ je nach Maschine unterschiedlich wirkt.

iOS (iSH / Leichtgewichtige Terminals)

Leichtgewichtige Terminals haben oft nur wget. Hinweis: Der Standard-UA von wget enthält oft kein curl, daher bekommst du häufig JSON. Wenn du „eine Textzeile“ willst, musst du den UA explizit setzen, um Textausgabe im Terminal zu erzwingen.

Grundnutzung

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

Gängige Varianten

# D1) Standort-Kurzinfo
    wget -qO- https://my.ipin.io/info

    # D2) Reinen Text erzwingen (eine IP-Zeile)
    wget -qO- -U "curl/8" https://my.ipin.io

    # D3) JSON erzwingen (stabile Integration)
    wget -qO- -U "Mozilla/5.0" https://my.ipin.io/info

Erklärung der Varianten

  • -qO-: Leise + Ausgabe nach stdout, praktisch für Skripte.
  • -U: Der zentrale Schalter zur Kontrolle des Ausgabeformats (UA enthält curl → Text; UA ohne curl → JSON).

OpenWRT / Embedded-Geräte

Das Kernziel auf Embedded-Geräten ist: nicht hängen bleiben. Daher unbedingt Timeouts setzen. Bei „Public-IP-Änderungserkennung“ auch Fehlalarme vermeiden: Eine fehlgeschlagene Anfrage bedeutet nicht, dass sich die IP geändert hat.

Grundnutzung (mit Timeout)

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

Gängige Varianten

# E1) Standort-Kurzinfo (Egress-Selbstcheck)
    wget -qO- --timeout=10 https://my.ipin.io/info

    # E2) Reinen Text erzwingen (eine IP-Zeile)
    wget -qO- --timeout=10 -U "curl/8" https://my.ipin.io

Erklärung der Varianten

  • --timeout: Für Embedded stark empfohlen als Default, damit Cron-/Timer-Jobs nicht hängen bleiben.
  • Stabiles Ausgabeformat: wget liefert standardmäßig ggf. JSON; wenn dein Skript nur eine IP-Zeile will, ist Textausgabe via UA zuverlässiger.

Docker / CI / Automatisierte Jobs

In Automatisierung ist die Ungewissheit größer: DNS-Schwankungen, kurze Timeouts und Egress-Policy-Änderungen sind häufiger. Empfehlung als Default: Timeouts + wenige Retries + festes Ausgabeformat (damit Parsing nicht auf unterschiedlichen Runnern bricht).

Grundnutzung (mit Timeouts)

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

Gängige Varianten (am praktischsten in CI)

# F1) Standort zuverlässig holen (mit Retries)
    curl -s --retry 2 --connect-timeout 3 --max-time 8 https://my.ipin.io/info

    # F2) CI will stabiles JSON: UA auf nicht-curl fixieren
    curl -s -A "Mozilla/5.0" --connect-timeout 3 --max-time 8 https://my.ipin.io/info

    # F3) Diagnose: Protokoll-Stack erzwingen
    curl -s -4 https://my.ipin.io
    curl -s -6 https://my.ipin.io/v6

Erklärung der Varianten

  • UA fixieren: In CI können unterschiedliche Images/Tools unterschiedliche UAs haben; fixiert man ihn, driftet das Ausgabeformat nicht.
  • Wenige Retries: Erhöht die Erfolgsquote, aber Fehler sollen weiterhin schnell sichtbar werden (leichter zu diagnostizieren).

Häufig gestellte Fragen (FAQ)

Q1: Ich nutze curl -s https://my.ipin.io — warum schlägt es manchmal fehl oder gibt einen Fehler zurück?

Der Root-Pfad ist „striktes IPv4“: Wenn der aktuelle Pfad kein IPv4 liefern kann, schlägt er ausdrücklich fehl (statt mit einem IPv6 so zu tun, als wäre es erfolgreich). Das passiert typischerweise bei: IPv6-only-Netzen, bestimmten Proxy-/Gateway-Umgebungen oder wenn dein Client auf IPv6 gezwungen wird und auf der Strecke kein nutzbares IPv4 existiert.

Diagnose: Mit curl -s -4 IPv4 erzwingen; oder /info nutzen, um zu sehen, welche Egress-IP aktuell verwendet wird, und dann den nächsten Schritt entscheiden.

Q2: Ich rufe /info mit curl ab — warum ist das nicht JSON?

Weil Terminal-Tools standardmäßig im „Terminal-Ausgabemodus“ laufen und /info

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

Q3: Warum ist das Ausgabeformat derselben Anweisung auf verschiedenen Rechnern unterschiedlich?

Das Ausgabeformat hängt vom User-Agent der Anfrage ab. Unterschiedliche Tools (curl / wget / manche Distributionstools) können unterschiedliche Standard-UAs haben, was zu Unterschieden zwischen Text- und JSON-Antworten führt.

Lösung: UA fixieren. Für Text soll der UA curl enthalten; für JSON soll der UA curl nicht enthalten. Für Automatisierung/CI ist ein fixer UA der Schlüssel für „stabiles Parsing“.

Q4: Warum will ich eindeutig IPv4, habe aber das Gefühl, ich „bin über IPv6 gegangen“?

Hier muss man zwei Dinge unterscheiden: den Protokoll-Stack beim Verbinden (Client wählt v4/v6 zum Verbinden), und den vom Endpoint zurückgegebenen IP-Typ (bestimmt durch den Pfad / oder /v6).

Diagnose-Empfehlung: Mit -4/-6 den Verbindungs-Stack erzwingen, um zu bestätigen, welche Strecke dein Netzwerk tatsächlich bevorzugt. Wenn du nur IPv4 willst, den Root-Pfad nutzen und bei Bedarf -4 erzwingen.

Q5: Wie sollte ich es in Skripten schreiben, damit es nicht leicht zu Fehlalarmen kommt und nichts hängen bleibt?

Empfohlene Kombination: silent (kein Rauschen), Timeouts (kein Hängen), wenige Retries (gegen Jitter), und bei Fehlschlag den alten Wert nicht überschreiben (Fehler nicht als Änderung werten).

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

Q6: Soll ich eher curl oder wget verwenden?

Wenn möglich, nimm curl: mehr Optionen und stärker für Diagnose. Aber in leichten/embedded Umgebungen gibt es häufig nur wget—wget ist völlig okay. Entscheidend ist: Timeouts setzen, nach stdout ausgeben und bei Bedarf den UA fixieren, um das Ausgabeformat zu sperren.