Spuckt es irgendwelche nützlichen Details aus, wenn Du das hier abarbeitest?
https://stackoverflow.com/a/38706495/3747688
Worüber spricht Du das Remote Repository an? SSH, HTTP, …? Funktioniert ein Verbindungsaufbau z.B. mit wget vom Webhostingserver zum Remote Repository?
Am Stadtrand ticken die Uhren vielleicht anders, keine Ahnung von wo Du da was hörst. 
In Simmering oder Transdanubien ist so was auch keine Seltenheit…
Und bitte verzichte auf die Fehlerunterdrückung (@), nutze stattdessen Exceptions (MYSQLI_REPORT_STRICT) und bei Bedarf try/catch-Blöcke.
Dann schraube am SSH-Server mal temporär das Debuglevel hoch und schau, was während dem Verbindungsversuch von Terminus passiert.
Österreicher wissen es wie es in AT läuft; jede Woche am Samstag Punkt 12:00¹ gibts eine Sirenprobe mit einem 15 Sekunden Dauerton […]
Anmerkung: Nicht in Großstädten wie z.B. Wien. Da gibt es nur den jährlichen Test.
Wöchentliches Rumgeheule gibt's nur bei den Gschärden 
*duck*
Prinzipiell funktioniert das bei Debian sehr gut, wenn man keine Version überspringt. Nur bei Fremdpaketen, Backports und sehr exotischen Konfigurationen könnte es unvorhersehbare Probleme geben.
Erstellt einfach ein Backup und leg nach dem Lesen der Release (bzw. Upgrade) Notes los. Wenn es unlösbare Probleme gibt, kannst Du immer noch neu installieren.
Ein einfaches lauffähiges Testscript zum Reproduzieren wäre bei so etwas sehr hilfreich. Dann sieht man meistens schneller, woran es konkret liegt.
Das komische ist nur, dass ich das (interne) Ziel nicht kenne. Die IP-Adresse taucht in meinem RackTables und Wiki nicht auf! Die dazugehörende Mac-Adresse ebenfalls nicht. Wo auch immer diese Pakete landen und beantwortet werden, es ist innerhalb des Heimnetzwerks, ich weiß nur noch nicht wo…
Ziel gefunden: Eine VM, die (noch) nicht ordentlich dokumentiert ist.
Das DNAT für Port 80/443 sollte auf der Router-VM in dieser Art eigentlich gar nicht existieren. Das sind wohl Altlasten von irgendeinem Test.
Fazit: Ich rühre das DNAT vorerst trotzdem lieber nicht an, sonst fliegt mir da noch etwas Anderes um die Ohren…
Was lernen wir daraus? Man sollte immer alles brav dokumentieren, auch wenn es nur temporäre Tests sind! 
Ergänzung: Ich Trottel such den Fehler an der falschen Stelle… 
Da mir die Sache spanisch vorkam, habe ich mal mit tcpdump geschaut, ob bei IPv4 über die Problemports überhaupt etwas in der VM ankommt. Nein, tut es nicht! 
Aus historischen Gründen liegt da noch ein DNAT über eine andere Router-VM dazwischen. Das ist bei IPv6 nicht der Fall, da geht es direkt in die richtige VM. Auf der Router-VM sehe ich nur, dass bei den Ports 80 und 443 ein völlig anderes Ziel kontaktiert wird, als bei Port 8080. Das komische ist nur, dass ich das (interne) Ziel nicht kenne. Die IP-Adresse taucht in meinem RackTables und Wiki nicht auf! Die dazugehörende Mac-Adresse ebenfalls nicht. Wo auch immer diese Pakete landen und beantwortet werden, es ist innerhalb des Heimnetzwerks, ich weiß nur noch nicht wo… 
Ich habe Zuhause eine VM mit einem Nginx. Aus historischen Gründen laufen die Websites dort auf Port 8080 (HTTPS).
Zusätzlich gibt es einen Redirect (server_name .example.net) von den Ports 80 (HTTP) und 443 (HTTPS) auf eben jenen Port 8080 mit HTTPS.
Kann sich das jemand erklären? Ich weiß nicht mehr, wo ich den Fehler suchen soll. Ich weiß nämlich definitiv nicht, woher der 404-er kommt. Vom Default-Listener jedenfalls nicht…
Leider kann ich nicht mit Sicherheit sagen, ob dieser Fehler schon immer existiert. Die VM wurde kürzlich von Debian Jessie auf Buster gebracht, ich bin vorhin nur zufällig drüber gestolpert.
20.04.2011
Jo mei, da waren wir halt alle noch jünger! (Und dümmer.)
Aber dass jedem Endgerät ein /64 zugeteilt werden soll, ist völliger Unsinn
Aber wir haben doch jetzt so viele Adressen bei IPv6! Da kann man zuteilen, soviel man möchte! Das reicht bis in alle Ewigkeit!!!!!!!111elf
Wozu brauche ich am Telefon einen ganzen 64er Präfix?
Tethering?
Bzw. wer sagt, dass die SIM-Karte in einem Smartphone steckt?
Warum ist denn Dualstack so schlimm?
Nichts, aber das Pflegen von zwei Stacks sowie Firewallregeln nervt auf Dauer. Das zieht sich ja ewig weiter, weil nahezu in jeder Software irgendwo Code schlummert, der IPv4/IPv6 getrennt behandelt. Wenn man auf das irgendwann verzichten könnte, wäre es schon ganz angenehm.
(Trotzdem wäre ich derzeit strikt dagegen, dass IPv4 abgeschaltet wird. So weit sind wir noch lange nicht. Leider.)
Wisst ihr was? In Wirklichkeit werden wir Dualstack nie los. Bevor IPv4 abgedreht wird, wird eher IPv6 abgeschaltet, weil es einen weiteren Nachfolger gibt.
Anmerkung: Das Cloud vLAN verwendet sowieso ein eigenes Interface und ist somit schön getrennt. Das ist halt nicht zu verwechseln mit Traffic, der das RZ nicht verlässt! Alles, was über das normale (öffentliche) Interface läuft, fällt auch unter die bekannten Limitierungen.
Funktioniert bei mir einwandfrei, scheint also kein generelles Problem zu sein…
Da kann Dir im Kundenforum wohl nicht geholfen werden: Sende ein kurze Mail an den Support! 
[…] ich würde gern meine Wixseite […]
Ich weiß, ich wiederhole mich seit Jahren, aber warum hat denen nie jemand gesagt, dass der Name am deutschen Markt lustig werden könnte?
Immerhin scheinen sie es mittlerweile mit Humor zu nehmen. Na dann…
(Bin schon wieder still. Der längste Faden kann jetzt wieder höchst professionell werden, wie immer halt.)
