auf welchem Host läuft dieser SQUID?
Hast du evtl. im lokalem Netzwerk oder im Anti-Viren Programm einen Proxy, der evtl. TLS Terminiert um Pakete inspizieren zu können?
Ich habe eine Subdomain von einem anderen Anbieter über A-Record auf meinen Netcup-Server geleitet.
auf welchem Host läuft dieser SQUID?
Die Anfragen gehen an die Subdomain und in der Antwort steht als host die richtige IP von meinem Netcup-Server drin. Auf dem Server ist aber kein squid installiert.
Hast du evtl. im lokalem Netzwerk oder im Anti-Viren Programm einen Proxy, der evtl. TLS Terminiert um Pakete inspizieren zu können?
Nein.
Um welche Subdomain handelt es sich denn und wie sieht der Request aus, damit wir das hier mal nachstellen können und gucken wer darauf antwortet.
Habe ich noch nie gehört sowas. Google wohl auch nicht 
Höchstens sowas, wo eine Firewall/Router die Anfrage umbiegt:
https://blog.eq8.eu/article/pu…tch-vs-your-firewall.html
Scheint mir, als wäre ein Teil der Verbindungskette nicht in der Lage ordentlich mit PATCH requests umzugehen. Kannst du es mal aus einem anderen Netz probieren?
Siehst du den PATCH-Request im access_log des nginx (ggf. zu aktivieren)?
Wenn wirklich nur die PATCH-Methode des HTTP nicht funktioniert, alle anderen Methoden aber schon, ist eine Fehlkonfiguration in deinem Einflussbereich am wahrscheinlichsten (da obere OSI-Layer).
Ich habe NGINX als backend proxy für die API eingerichtet.
Für welche API denn?
Woher weißt du dass ein Squid antwortet?
Siehst du den PATCH-Request im access_log des nginx (ggf. zu aktivieren)?
Wenn wirklich nur die PATCH-Methode des HTTP nicht funktioniert, alle anderen Methoden aber schon, ist eine Fehlkonfiguration in deinem Einflussbereich am wahrscheinlichsten (da obere OSI-Layer).
Für welche API denn?
Woher weißt du dass ein Squid antwortet?
Der Request ist nicht im access log. Kann er ja auch gar nicht, da die Antwort ja vom squid-server kommt, der freundlicherweise einen Server-Header mit seinen Informationen sendet. Die API ist meine eigene.
Ich habe die Vermutung, dass mein Domainanbieter eine uraltversion von squid (2.7, neuste version von 2010) als DNS oder in Zusammenhang damit betreibt. Diese alte version kann keine PATCH-Anfragen verarbeiten und gibt einen 400-Fehler zurück. Wenn es stimmt wird es Zeit meinen Anbieter zu wechseln. Ich halte euch auf dem laufenden.
Das kann nicht mit dem DNS zusammenhängen, da die Namensauflösung auf einer ganz anderen Ebene stattfindet, als der HTTP-PATCH-Request.
Es ist aber möglich, dass z.B. der Netzanbieter, den du verwendest sich dazwischenschaltet.
Ich habe die Vermutung, dass mein Domainanbieter eine uraltversion von squid (2.7, neuste version von 2010) als DNS oder in Zusammenhang damit betreibt.
Dann gib uns doch mal die Domain (und den Request), damit wir das überprüfen können!
Dann kannst du aber unmöglich einen DNS A Record angelegt haben.
Ich kann nicht ändern was mir die Domainverwaltung anzeigt und sie zeigt an, dass ich einen A-Record angelegt habe. Das dieser nicht so funktioniert wie er eigentlich sollte oder das Domainverwaltung intern etwas anderes macht, dafür kann ich nichts, ich kann es auch nicht erklären, es ist mir auch egal. Ich möchte das meine Anwendung funktioniert und das tut sie jetzt auch. Wenn du mir das nicht glaubst, dann ist das dein Problem.
du kannst aber prüfen ob der DNS Server das tut was er soll. Mach doch mal eine host oder dig anfrage und schau dir an ob da die richtige IP raus kommt, oder ob da ggf ne IP von irgendeinem proxy des DNS anbieters kommt
Was zeigt denn ein DNS Lookup auf den Record? Dann weißt du ob dort ein Proxy im Spiel ist, oder nicht. Ggf. kann man das ja deaktivieren, oder du solltest dir andere autoritative DNS Server zulegen.
Evtl. hast du da noch einen alten Record erwischt mit einer hohen TTL.
Ich war gestern aber mit einem Surfstick online. Kann es damit zusammenhängen?
Ich war gestern aber mit einem Surfstick online. Kann es damit zusammenhängen?
Siehe zum Beispiel:
https://www.macuser.de/threads…ert-seiteninhalte.178999/
https://forum.ubuntuusers.de/t…rung-unter-opera-umgehen/
