zusätzlich kommt jetzt auch noch nginx-error 504 dazu (siehe Anhang) ...
die zugehörige Meldung (hier anonymisiert) im "proxy_error_log" ist:
fast gleichzeitig auf mehreren verschiedenen (sub-) hosts meines webhosting 4000
Meldungen an den Support habe ich schon abgesetzt.
bei mir tritt der Fehler jetzt exakt so wie oben im Eingangspost beschrieben wieder auf 
im proxy_error_log schön zu sehen ...
derzeit ist ja das Webmail (roundcube) über z.B.
https://webmail01.webhosting.systems bzw. https://webmail01.netcup.net
erreichbar.
jetzt erscheint auf https://webmail01.webhosting.systems eine Fehlermeldung:
"webmail01.webhosting.systems verwendet ein ungültiges Sicherheitszertifikat. Das Zertifikat ist nur gültig für webmail01.netcup.net."
also jetzt doch wieder nur https://webmail01.netcup.net benutzen ?
(dass ich roundcube o.äh. auf meinem webspace ggf. auch selber installieren kann ist mir klar, das möchte ich aber nicht)
derzeit ist ja das Webmail (roundcube) über z.B.
https://webmail01.webhosting.systems bzw. https://webmail01.netcup.net
erreichbar.
Wird es irgendwann eine Lösung geben, mit der man auch seine eigenen Domains verwenden kann nach dem Muster
"https://webmail.meineDomain.tld" ?
(oder kann man das mit Bordmitteln irgendwie machen ? -> Weiterleitung ? -> im frame anzeigen lassen ? -> o.äh.)
(dass ich roundcube o.äh. auf meinem webspace ggf. auch selber installieren kann ist mir klar, das möchte ich aber nicht)
früher konnte man sich über den Support die Adresse "http://webmail.meineDomain.tld" freischalten lassen,
aber in Zeiten von SSL/https ist das wohl nicht mehr angebracht ...
(ich nutze Webhosting 4000)
Ich hab's raus gefunden:
man muss den Link "Webstatistik für SSL/TLS" benutzen 
dieses Problem besteht nach wie vor ...
läuft das bei Euch ?
Nachfrage:
kann man dann auch dauerhaft(?)
https://webmail01.webhosting.systems
verwenden statt:
Post- ein und Ausgangsserver fpr POP3 und IMAP Clients bleiben aber nach dem Schema:
so wie bisher, oder ?
Das ist seit ein paar Tagen neu, nachdem das CCP auf Google‘s Malware-Liste stand
Im Zuge des Malware-"blacklistings" der netcup.net-Domain
ah,
die Geschichte, ich hörte davon ...
Also, wenn das jetzt so bleibt -> 
geht das jetzt mittlerweile / hat sich da was getan ?
denn:
ich kann jetzt (herausgefunden über das CCP2 Beta) auch aufrufen:
https://xxxxx.webhosting.systems/smb/web/view
bzw. Login-Seite:
https://xxxxx.webhosting.systems/login_up.php
also ganz ohne Port 8443 usw...
( bisher: https://xxxxx.netcup.net:8443 )
oder ging das schon immer (zumindest übers CCP) und ich hab's nicht gemerkt ?
*(xxxxx = dein Server-(Hosting)-Name)
Vorschlag: Angenommen es gäbe einen zentralen Proxy bei netcup ("webhostingproxy.de"), dieser hat dann für jeden Hosting-Node einen eigenen Ordner, welcher dann auf die Maschinen mit deren abweichendem Port tunnelt. Das Interface auf einem der Nodes wäre also erreichbar unter z.B. "webhostingproxy.de/node13". Alternativ auch "node13.webhostingproxy.de". Meiner Meinung nach kein Hexenwerk und durchaus auch gut zu automatisieren, wenn neue Nodes dazukommen.
Ja genau,
so würde ich mir das auch wünschen ...
Hallo,
gibt es mittlerweile eine Lösung (oder Workaraund) um das WCP über einen anderen Port als 8443 aufzurufen ?
Es geht mir um die Nutzung von unterwegs aus bzw. vom Arbeitgeber usw... wo diese Ports meistens nicht freigeschaltet sind, sondern nur die Standard-Ports welche man beim Browsen so braucht ...
Könnte netcup hier nicht eine Art Proxy einrichten ?
Wir würden den Sachverhalt gerne prüfen und bitten Sie ein Support Ticket mit dem entsprechenden Webhosting und der betroffenen Domain zu eröffnen. Wir schauen uns das gerne an!
wie schon im Eingangs-Post geschrieben, habe ich dazu bereits am 11.05.2018 12:58 ein Ticket angelegt --> [NC#2018051110003666]
(bisher (3 Tage später) noch keine Antwort bis auf die automatische(?) Standard-Antwort: "Ich habe Ihre Anfrage soeben an unsere Kollegen der entsprechenden Abteilung zur Bearbeitung weiter geleitet.... usw...")
mir ist noch folgendes aufgefallen,
offensichtlich tritt der Fehler bei mir gehäuft um 11min. nach jeder vollen Stunde und um 41 min. nach jeder vollen Stunde auf (kein Scherz),
das gibt auch das "proxy_error_log" her ...
vielleicht läuft da gerade irgend ein cron o.äh. bei netcup ? (ich selbst benutze keine crons derzeit)
habe genau das selbe Problem aktuell bei meinem Webhosting 8000.
schau mal bitte in dein logfile "proxy_error_log"
hallo,
ich habe Webhosting 4000,
und sehe ab und zu bei Aufruf meiner Seiten eine weiße Seite mit "502 Bad Gateway nginx" (auch verschiedene Besucher der Seiten haben mir davon berichtet).
drückt man F5 reload im Browser erscheint es noch mal,
wartet man 25 - 30 sek. und drückt dann F5 reload im Browser ist alles wieder normal.
Alle meine Seiten benutzen "fastCGI over apache" so dass ich doch eigentlich gar kein nginx im Einsatz habe (?)
Ich weiß aber, dass netcup beim Webhosting einen nginx proxy benutzt (wofür auch immer),
und im logfile "proxy_error_log" finden sich auch jede Menge Fehlermeldungen nach dem Muster:
" 2018/05/13 15:41:50 [error] 20379#0: *5240056 connect() failed (111: Connection refused) while connecting to upstream, client: ..."
sowie:
" 2018/05/13 15:11:47 [error] 20379#0: *5218849 peer closed connection in SSL handshake (104: Connection reset by peer) while SSL handshaking to upstream, client ... "
Hat jemand von Euch schon mal so etwas gehabt ?
(habe vor 2 Tagen schon eine Supportanfrage erstellt, leider noch keine Antwort)
Bei den neuesten Webhosting Tarifen sollte keine downtime entsteht, da diese als HA Cluster aufgebaut sind.
hmmmm .... schön wär's ...
mein (neues) Webhosting 4000 ist seit fast 2 Stunden down ...
inkl. der Verwaltungsoberfläche (neues WCP),
und auch das CCP findet das Hosting nicht mehr, es wird angezeigt: "Ein Fehler ist aufgetragen bei WebhostingOnyxHelper::getSession"
vielen Dank für das Update
QuoteDie letzten Nodes der Webhosting-Cloud sind gerade dabei neu zu starten.
mit wie viel downtime für das Webhosting ist hier ca. zu rechnen -> eher Minuten oder eher Stunden ?
mein Webhosting af9aa ist gerade komplett down,
hat es etwas damit zu tun ?
mach ihr gerade die updates ?
ich stoße gerade auf ein Problem mit Subdomains, welche ich letzten Monat jeweils als reine Weiterleitungen im WCP eingerichtet hatte:
Mache (die Mehrzahl) dieser Subdomains leiten "www" Aufrufe "selbsttätig" weiter, also: http://www.sub.domain.tld --> http://sub.domain.tld (was ich eigentlich ziemlich gut finde),
andere Subdomains (sogar unter der gleichen Hauptdomain) tun das nicht, obwohl im WCP alles identisch eingestellt ist.
Was mache ich falsch ?
bei meinem neuen Webhosting 4000 funktionieren die Webstatistiken offensichtlich nicht richtig (?)
Wenn man den (Statistik-) Links aus dem WCP folgt,
dann gelangt man (nach Eingabe seiner (Hauptnutzer-FTP-) Zugangsdaten) auf eine Statistikseite gemäß dem Muster:
https://meineDomain.tld/plesk-stat/webstat/
dort ist bei jeder meiner Domains nur genau ein Tag erfasst,
wenn ich es richtig sehe ist es der Tag (z.B. 14.Sept.2017) an dem ich die entsprechende Domain in dem neuen WCP erstmalig eingerichtet habe.
dadurch sind die Monatsangaben ziemlich sinnfrei, wie z.B. für den gesamten September:
----------------------
Monthly Statistics for September 2017:
Total Hits 1051
...
Hits per Day 1051
----------------------
wie kann das sein ?
läuft das bei Euch ?
