Mein Hinweis auf die nicht korrekte Update URL bleibt aber dennoch bestehen.
Korrekt sieht das in allen Fritten so aus https://...64.de&ip=<ipaddr>&ip6=<ip6addr>&ip6lanprefix=<ip6lanprefix>
Da gehören die <> mitsamt deren Inhalt rein.
CDN hängt bei mir wieder, er schien kein Let’s Encrypt Cert. abrufen zu können. Jedenfalls steht der CDN bei Reverse Proxy seit gestern auf „signing cert.“
Wer oder was ist denn er? Der Geist hinter v64.tech?
Deswegen gibt es ja den „Vorformatierten Text“ (Symbol: </>), den du jetzt ja scheinbar auch gefunden hast. 
Aber gut, dann ist ja nun alles klar
Am Ende bin nur ich das Problem. Weiß nicht woran es liegt. Evtl. der Editor. Hab es jetzt einfach als Bild gepostet, daher passt es Danke für Deine Geduld mit dem Unwissenden 
Also sieh dir doch mal das Bild an, mit dem Text von dir, der grau hinterlegt ist.
Da ist doch über dem Text eine Zeile mit verscheidenen Symbolen und Buchstaben. F = Fettschrift K = Kursiv und eben auch </> = Vorformatierter Text. Packst du die Update URL in diesen „Vorformatierten Text“ schneiden auch keine Geister etwas davon ab oder formatieren es um.
Ah, ok. Danke für den Hinweis. 
Jetzt sollte es wieder seit ca. über 12 Stunden Ruhig sein.
1 „Gefällt mir“
Bei mir wurden gestern auch die Nameserver nicht mehr aktualisiert, obwohl ich alle IPs auf der IPV64-Webseite eingetragen habe. Heute gehts.
Es funktioniert zur Zeit bei mir, aber bei meinem Update Script liefert ipv4.ipv64.net keine gültige json-response mehr zurück. Musste mein Script anpassen. Habt ihr was geändert?
Bei mir hat diesmal nach der Zwangstrennung durch den Provider alles ordnungsgemäß funktioniert.
Kannst mir ein Beispiel senden?
Der Aufruf funktioniert nicht mehr. Ich hab es gestern bemerkt, kann aber auch schon länger kaputt sein. curl -sSL "https://ipv4.ipv64.net/update.php?key=xxx&domain=xxx.ipv64.de" | jq . parse error: Invalid literal at EOF at line 1, column 5
Am 11. kam noch ne json zurück, ab dem 12. nur noch die info aus der json.
11.05.2025--08.06.09:1746943569 - Dns upgedatet --> ipv4 aktuell: .83 dns: .105 -- {"status":"success","ip":{"ipv4":".83"},"info":"good"}
11.05.2025--08.06.09:1746943569 - Dns upgedatet --> ipv6 aktuell: :48e3: dns: :2f20: -- {"status":"success","ip":{"ipv6":":48e3:"},"info":"good"}
------------------------------------------
12.05.2025--07.31.01:1747027861 - Dns upgedatet --> ipv4 aktuell: .178 dns: .83 -- good
12.05.2025--07.31.01:1747027861 - Dns upgedatet --> ipv6 aktuell: :5408: dns: :6820: -- good
1 „Gefällt mir“
Hallo, ich weiß das arrangement von Dennis und seinem Team wirklich zu schätzen und bin überzeugt, dass sie ihr Bestes geben um die Probleme in den Griff zu bekommen.
Doch bin ich in einem Segment nun mal von einem einwandfreiem 24/7 Dienst abhängigt. Mit kleineren Ausfällen bei 99% Abdeckung kann ich dank Redundanz arbeiten, aber wenn sich die Ausfälle bis hin zum Totalausfall häufen und ich Ständig durch Fehlalarme gestört werde, strengt das doch sehr an. Seit letzten WE funktioniert die Android-APP auch nicht mehr und stürzt direkt nach der Anmeldung ab. Keine Ahnung ob dies mit den derzeitigen Störungen zusammenhängt.
Ich bedauere meine Entscheidung sehr, doch habe ich mich für einen anderen DynDNS-Anbieter entschieden und den Healthcheck über anderer Software realisiert. Ich wünsche dem Team von IPv64 weiterhin viel Erfolg.
1 „Gefällt mir“
Setz mal im Updater &output=full
Danke, funktioniert.
Just for Information. In den nächsten Stunden wird vor den Webservice ein HAProxy gehängt. Dieser wird die Zugriffe deutlich mehr überwachen und sauberer Blockieren.
5 „Gefällt mir“
Just for Info. IPv64.net wird gerade umgestellt hinter einen HAProxy