Aufruf einer URL (bei all-inkl gehostet) schlägt NUR von Strato aus fehl

P

PhilippR

New Member
Hallo Zusammen,

ich hoffe, dass dieses Forum richtig ist für Fragen dieser Art. Falls nicht dürft ihr mir gerne einen Tipp geben, wo ich damit richtig aufgehoben bin.

Zu meinem Problem:
ich versuche, von einem PHP-Sript auf Server A (bei Strato gehosted) mittels GET eine öffentlich Zugängliche URL auf Server B (bei all-inkl gehosted) aufzurufen. In Zeiten von RESTApis etwas sehr normales.

Anfänglich ging das auch gut, nach einigen Aufrufen (ca. 10-20, ich habe leider nicht mitgezählt) enden die Anfragen in einem Timeout.
Das geschieht nur von Server A aus, von überall sonst erreiche ich die URL auf Server B problemlos.

Natürlich habe ich mich an beide Support-Teams gewendet. Beide sind der Meinung, dass das Verhalten für eine IP-Sperre spricht. Nur sagen auch beide, dass die jeweils andere IP bei Ihnen nicht gesperrt ist und das Problem auf der anderen Seite läge.

Nun habe ich sogar veranlasst, dass Server B umgezogen wird, um unter einer neuen IP erreichbar zu sein. Leider hat selbst das nichts am Problem geändert, alle Anfragen von Server A an die URL auf Server B enden im Timeout.

Hättet ihr mir noch Ideen, in welche Richtungen ich nach dem Problem suchen könnte? Ich bin mit meinem Latein langsam am Ende.

Vielen Dank & Grüße
Philipp
 
Hallo marce,

auf den Server B habe ich soweit Zugriff wie man Zugriff bei einem Hosting-Paket (in dem Fall all-inkl Premium) hat: Ich habe einen FTP-Zugang und Zugriff auf automatisch erstellte Logfiles, aber keine weiteren Berechtigungen.

Danke & Grüße
Philipp
 
PhilippR said:
Hättet ihr mir noch Ideen, in welche Richtungen ich nach dem Problem suchen könnte? Ich bin mit meinem Latein langsam am Ende.
Click to expand...

Du könntest den folgenden Test mal auf deinem Strato Server wiederholen. Denn soeben habe ich mal von einem Strato Server ein weget zum Server vom Provider all-inkl.com erfolgreich ausgeführt. Siehe folgendes Ergebnis:

wget https://all-inkl.com/
--2018-03-08 19:50:40-- https://all-inkl.com/
Auflösen des Hostnamen »all-inkl.com (all-inkl.com)«... 85.13.128.193
Verbindungsaufbau zu all-inkl.com (all-inkl.com)|85.13.128.193|:443... verbunden.
HTTP-Anforderung gesendet, warte auf Antwort... 200 OK
Länge: nicht spezifiziert [text/html]
In »»index.html«« speichern.
[ <=> ] 29.215 --.-K/s in 0s
2018-03-08 19:50:40 (186 MB/s) - »index.html« gespeichert [29215]

Das heißt schon mal, dass die IP-Adressen von Strato von beiden Providern nicht geblockt werden.
 
Ich habe vor sehr langer Zeit mal ein Webhosting bei einem Kölner Provider (sorry, ich mag Roß und Reiter jetzt nicht öffentlich benennen) gehabt.

Nach vielen unklaren Problemen habe ich dort mal die Apache-Konfig (soweit vom Webhosting aus einsehbar) analysiert und dabei u.a. ein aktiviertes mode_security mit aktivem Geoblock für China gefunden.
Soetwas kommt natürlich super, wenn der Kunde über dieses Webhosting daten für sein Joined Venture in China bereitstellen will. :(

Was ich damit sagen will: Manchmal kennt der 1st-Level-Support die Konfiguration gar nicht im Detail und weiß nichts von z.B. Anti-DDoS-Maßnahmen, die vielleicht erst nach dem 10. oder 20. API-Aufruf zuschlagen.
 
Hallo,

schonmal vielen Dank für die Antworten.

Ich vermute ehrlichgesagt, dass das Problem bei Strato hängt, der Support von all-inkl.com ist normalerweise extrem schnell und kompetent.

Einen Test habe ich noch durchgeführt:
In die andere Richtung (von Server B nach Server A) funktionieren sowohl GET als auch POST Anfragen.

Ich werde versuchen, die Serverkonfiguration vom Strato-Server so weit wie möglich einzusehen und dort nach dem Problem zu suchen.

Eine mögliche, und bei genauem Nachdenken sehr wahrscheinliche Ursache ist mir gerade aufgefallen:
Durch einen Fehler im HTML der Seite auf Server A (nicht meiner) hat der Browser die Seite auf Server A immer doppelt aufgerufen (aus der Firefox-Konsole):
Die Seite wurde neu geladen, weil die Zeichenkodierungs-Deklaration des HTML-Dokuments im Frame beim Vorverarbeiten der ersten 1024 Zeichen der Datei nicht gefunden wurde. Die Kodierungs-Deklaration muss in die ersten 1024 Zeichen der Datei verschoben werden.

Das hat logischerweise dazu geführt, dass, so lange es noch ging, in sehr kurzer Zeit (unter 1 Sekunde) die exakt gleiche Anfrage von Server A an Server B versendet wurde. Ich werde den Support fragen ob das die Sperre verursacht haben könnte.

Viele Grüße
Philipp
 
You must log in or register to reply here.
Back
Top