VK28.01

So, das war es. Nach einem Reboot kommt nun das:

So, nachdem ich nun entsprechend der Release Notes die Einstellungen gerade gemacht habe, zeigt sich im Syslog folgende Warnung; und dies mehrfach. Googlet man danach, findet man mein ursprüngliches Fehlerbild, die Nichterreichbarkeit des Servers. 🤷‍♂️

Wenn man weiß, was man sucht, sicherlich. Ist nicht mein Hometurf... Wäre ja schön, wenn es das wäre.

Hm, ja, der AdGuard läuft auf einer eigenen IP. Eigentlich dachte ich, ich hätte die Einstellungen korrekt gemacht, aber gerade gesehen, dass ich das "Settings > Network Settings > eth0 > Enable Bridging = No (this will automatically enable macvlan)" nicht gesetzt hatte. Ich habe das mal korrigiert. Da ich die Fritz!Box ersetzt habe, wäre nun auch ein Wechsel zu IPvlan eine Option.

Danke für die Punkte. Memtest hatte ich schon mal durchlaufen lassen. Ohne Befund. Bios werde ich mal updaten, das hatte ich nicht auf dem Radar. Tastatur&co hatte ich nicht probiert, weil der Server ziemlich "eingebaut" ist. Was mir noch aufgefallen ist, dass der Stromverbrauch während der "nicht Erreichbarkeit" hoch war und das konstant. Üblicherweise idelt der Server bei 11 Watt rum, während der "nicht Erreichbarkeit" lag der Verbrauch bei 26 Watt; und das über die ganze Zeit und das obwohl die Platten, gehörmäßig, nicht gedreht haben.

Ich brauche mal Hilfe. Ich habe hier ein 6.12.4 Unraid laufen. Vor einer Woche ist er das erste mal nicht mehr erreichbar gewesen. Der Server war nicht mehr zu pingen, die Ethernet-Schnittstelle war tot. Geholfen hat dann nur ein Reset. Nun ist es gerade ein weiteres Mal passiert. Der Server hat mehr oder weniger vor sich hin geidelt und ist dann eingefroren. Ich habe mir den Syslog angeschaut, aber nichts gesehen, was ich mit dem Absturz in Verbindung bringen kann. Vielleicht kann mal bitte jemand schauen, ob etwas auffälliges vorliegt. Das erste Mal war im Urlaub und ich hatte keine Zugriff auf die Daten von extern...wenn ich das System nicht zuverlässig bekomme, muß es raus. Das geht nicht. syslog-192.168.0.125.log

Same here with: ASUSTeK COMPUTER INC. PRIME B460M-A , Version Rev 1.xx American Megatrends Inc., Version 1605 Intel® Core™ i3-10105 CPU @ 3.70GHz Sensor-Detect: Intel digital thermal sensor... Success! (driver `coretemp') Found `Nuvoton NCT6798D Super IO Sensors' Success! (address 0x290, driver `nct6775') Processor&Mainboard Sonsors are working like a charm...Fan array Sensor is displayed "none" within the System-Temp-Plugin. Consequently the Auto-Fan-Plugin does not work either.

Nach einem Neustart hat sich die rote Fahne verändert: Aug 13 00:36:54 Tower nginx: 2023/08/13 00:36:54 [error] 14199#14199: *115 limiting requests, excess: 20.344 by zone "authlimit", client: 192.168.0.68, server: , request: "GET /login HTTP/1.1", host: "192.168.0.125:5000", referrer: "http://192.168.0.125:5000/Dashboard" der Eintrag ist x-fach vorhanden. Der erstgenannte Eintrag/Fehler ist nicht mehr vorhanden.

Nachdem ich heute meine Cache-Pool auf ZFS umgestellt habe, zickt der Server. Nach der Umstellung liefen einige Container nicht mehr und ich mußte aus dem Backup wiederherstellen. Bei der Suche nach dem Fehler bin ich über eine rote Fahne im Log gestolpert. Im Log habe ich das Folgende gefunden: Aug 13 00:02:30 Tower kernel: traps: node[19556] trap int3 ip:1c044d2 sp:7ffd51a85e90 error:0 in node[400000+4579000] Aug 13 00:02:33 Tower kernel: traps: node[19738] trap int3 ip:1c044d2 sp:7ffd038494e0 error:0 in node[400000+4579000] Aug 13 00:02:36 Tower kernel: traps: node[19937] trap int3 ip:1c044d2 sp:7ffc798da770 error:0 in node[400000+4579000] Aug 13 00:02:39 Tower kernel: traps: node[20153] trap int3 ip:1c044d2 sp:7fff6d2f52c0 error:0 in node[400000+4579000] Aug 13 00:02:42 Tower kernel: traps: node[20399] trap int3 ip:1c044d2 sp:7ffe067e5b70 error:0 in node[400000+4579000] Aug 13 00:02:45 Tower kernel: traps: node[20519] trap int3 ip:1c044d2 sp:7fff211af690 error:0 in node[400000+4579000] Aug 13 00:02:48 Tower kernel: traps: node[20696] trap int3 ip:1c044d2 sp:7ffd6f2b73a0 error:0 in node[400000+4579000] Aug 13 00:02:50 Tower kernel: traps: node[20876] trap int3 ip:1c044d2 sp:7ffca9c26a70 error:0 in node[400000+4579000] Aug 13 00:02:53 Tower kernel: traps: node[21057] trap int3 ip:1c044d2 sp:7fffaeb94e50 error:0 in node[400000+4579000] Aug 13 00:02:56 Tower kernel: traps: node[21192] trap int3 ip:1c044d2 sp:7ffd2f07ff60 error:0 in node[400000+4579000] Aug 13 00:02:59 Tower kernel: traps: node[21381] trap int3 ip:1c044d2 sp:7ffcb8b13ef0 error:0 in node[400000+4579000] Aug 13 00:03:02 Tower kernel: traps: node[21559] trap int3 ip:1c044d2 sp:7ffe2c3afd10 error:0 in node[400000+4579000] Aug 13 00:03:05 Tower kernel: traps: node[21768] trap int3 ip:1c044d2 sp:7ffc78b70000 error:0 in node[400000+4579000] Aug 13 00:03:08 Tower kernel: traps: node[21990] trap int3 ip:1c044d2 sp:7ffd389ed140 error:0 in node[400000+4579000] Aug 13 00:03:11 Tower kernel: traps: node[22127] trap int3 ip:1c044d2 sp:7ffecc5ff1a0 error:0 in node[400000+4579000] Aug 13 00:03:14 Tower kernel: traps: node[22312] trap int3 ip:1c044d2 sp:7ffc42b94ce0 error:0 in node[400000+4579000] Aug 13 00:03:17 Tower kernel: traps: node[22454] trap int3 ip:1c044d2 sp:7fffe571ad20 error:0 in node[400000+4579000] Aug 13 00:03:20 Tower kernel: traps: node[22688] trap int3 ip:1c044d2 sp:7ffc4c1357d0 error:0 in node[400000+4579000] Aug 13 00:03:22 Tower kernel: traps: node[22807] trap int3 ip:1c044d2 sp:7ffdf42d1fc0 error:0 in node[400000+4579000] Aug 13 00:03:25 Tower kernel: traps: node[23004] trap int3 ip:1c044d2 sp:7ffc0413dcb0 error:0 in node[400000+4579000] Aug 13 00:03:28 Tower kernel: traps: node[23190] trap int3 ip:1c044d2 sp:7ffde779fab0 error:0 in node[400000+4579000] Aug 13 00:03:31 Tower kernel: traps: node[23325] trap int3 ip:1c044d2 sp:7ffc895b0480 error:0 in node[400000+4579000] Aug 13 00:03:34 Tower kernel: traps: node[23650] trap int3 ip:1c044d2 sp:7ffcf00927b0 error:0 in node[400000+4579000] Aug 13 00:03:37 Tower kernel: traps: node[23765] trap int3 ip:1c044d2 sp:7ffdecf35e10 error:0 in node[400000+4579000] Aug 13 00:03:40 Tower kernel: traps: node[23970] trap int3 ip:1c044d2 sp:7ffc08fd0400 error:0 in node[400000+4579000] Aug 13 00:03:43 Tower kernel: traps: node[24090] trap int3 ip:1c044d2 sp:7ffc3f6382d0 error:0 in node[400000+4579000] Aug 13 00:03:46 Tower kernel: traps: node[24294] trap int3 ip:1c044d2 sp:7ffc8e26d800 error:0 in node[400000+4579000] Aug 13 00:03:49 Tower kernel: traps: node[24448] trap int3 ip:1c044d2 sp:7ffd81900150 error:0 in node[400000+4579000] Aug 13 00:03:52 Tower kernel: traps: node[24671] trap int3 ip:1c044d2 sp:7ffe50e5e4b0 error:0 in node[400000+4579000] Aug 13 00:03:55 Tower kernel: traps: node[24880] trap int3 ip:1c044d2 sp:7fff56f06960 error:0 in node[400000+4579000] Aug 13 00:03:57 Tower kernel: traps: node[24989] trap int3 ip:1c044d2 sp:7fff4b5b7660 error:0 in node[400000+4579000] Aug 13 00:04:00 Tower kernel: traps: node[25185] trap int3 ip:1c044d2 sp:7fff17226a40 error:0 in node[400000+4579000] Aug 13 00:04:03 Tower kernel: traps: node[25372] trap int3 ip:1c044d2 sp:7fff40981100 error:0 in node[400000+4579000] Aug 13 00:04:06 Tower kernel: traps: node[25587] trap int3 ip:1c044d2 sp:7ffe36ca9880 error:0 in node[400000+4579000] Aug 13 00:04:09 Tower kernel: traps: node[25728] trap int3 ip:1c044d2 sp:7ffcd832c940 error:0 in node[400000+4579000] Aug 13 00:04:12 Tower kernel: traps: node[25941] trap int3 ip:1c044d2 sp:7ffccc666b60 error:0 in node[400000+4579000] Aug 13 00:04:15 Tower kernel: traps: node[26121] trap int3 ip:1c044d2 sp:7ffdc7c81240 error:0 in node[400000+4579000] Aug 13 00:04:18 Tower kernel: traps: node[26239] trap int3 ip:1c044d2 sp:7fffe3c00770 error:0 in node[400000+4579000] Aug 13 00:04:21 Tower kernel: traps: node[26482] trap int3 ip:1c044d2 sp:7ffcdedd06d0 error:0 in node[400000+4579000] Aug 13 00:04:24 Tower kernel: traps: node[26596] trap int3 ip:1c044d2 sp:7ffd4435e560 error:0 in node[400000+4579000] Aug 13 00:04:27 Tower kernel: traps: node[26799] trap int3 ip:1c044d2 sp:7fff119611c0 error:0 in node[400000+4579000] Aug 13 00:04:30 Tower kernel: traps: node[26921] trap int3 ip:1c044d2 sp:7ffede4990a0 error:0 in node[400000+4579000] Aug 13 00:04:33 Tower kernel: traps: node[27103] trap int3 ip:1c044d2 sp:7fff29704a10 error:0 in node[400000+4579000] Aug 13 00:04:36 Tower kernel: traps: node[27343] trap int3 ip:1c044d2 sp:7ffe03360020 error:0 in node[400000+4579000] Aug 13 00:04:39 Tower kernel: traps: node[27464] trap int3 ip:1c044d2 sp:7ffd291dac00 error:0 in node[400000+4579000] Aug 13 00:04:42 Tower kernel: traps: node[27664] trap int3 ip:1c044d2 sp:7ffd90afe7d0 error:0 in node[400000+4579000] Aug 13 00:04:45 Tower kernel: traps: node[27807] trap int3 ip:1c044d2 sp:7fff46720f80 error:0 in node[400000+4579000] Aug 13 00:04:48 Tower kernel: traps: node[27992] trap int3 ip:1c044d2 sp:7fff16058f10 error:0 in node[400000+4579000] Aug 13 00:04:51 Tower kernel: traps: node[28226] trap int3 ip:1c044d2 sp:7fff45d27d00 error:0 in node[400000+4579000] Aug 13 00:04:54 Tower kernel: traps: node[28335] trap int3 ip:1c044d2 sp:7ffce2279ac0 error:0 in node[400000+4579000] Aug 13 00:04:57 Tower kernel: traps: node[28548] trap int3 ip:1c044d2 sp:7ffe5f89d4a0 error:0 in node[400000+4579000] Aug 13 00:05:00 Tower kernel: traps: node[28685] trap int3 ip:1c044d2 sp:7ffd1101a9c0 error:0 in node[400000+4579000] Aug 13 00:05:03 Tower kernel: traps: node[28897] trap int3 ip:1c044d2 sp:7fff87ce2230 error:0 in node[400000+4579000] Aug 13 00:05:06 Tower kernel: traps: node[29082] trap int3 ip:1c044d2 sp:7ffcb525fda0 error:0 in node[400000+4579000] Aug 13 00:05:09 Tower kernel: traps: node[29306] trap int3 ip:1c044d2 sp:7ffda7933d30 error:0 in node[400000+4579000] Aug 13 00:05:12 Tower kernel: traps: node[29489] trap int3 ip:1c044d2 sp:7ffff1f686a0 error:0 in node[400000+4579000] Aug 13 00:05:15 Tower kernel: traps: node[29608] trap int3 ip:1c044d2 sp:7fffa2d6fd90 error:0 in node[400000+4579000] Aug 13 00:05:18 Tower kernel: traps: node[29847] trap int3 ip:1c044d2 sp:7fff444a9a20 error:0 in node[400000+4579000] Aug 13 00:05:21 Tower kernel: traps: node[30031] trap int3 ip:1c044d2 sp:7ffe370553c0 error:0 in node[400000+4579000] Aug 13 00:05:24 Tower kernel: traps: node[30226] trap int3 ip:1c044d2 sp:7ffd97870250 error:0 in node[400000+4579000] Aug 13 00:05:27 Tower kernel: traps: node[30360] trap int3 ip:1c044d2 sp:7ffe35cbce10 error:0 in node[400000+4579000] Aug 13 00:05:30 Tower kernel: traps: node[30542] trap int3 ip:1c044d2 sp:7fffc65f71b0 error:0 in node[400000+4579000] Aug 13 00:05:33 Tower kernel: traps: node[30719] trap int3 ip:1c044d2 sp:7ffe6e59be50 error:0 in node[400000+4579000] Aug 13 00:05:35 Tower kernel: traps: node[30895] trap int3 ip:1c044d2 sp:7ffe3cd21340 error:0 in node[400000+4579000] Aug 13 00:05:38 Tower kernel: traps: node[31077] trap int3 ip:1c044d2 sp:7ffd46763ff0 error:0 in node[400000+4579000] Aug 13 00:05:41 Tower kernel: traps: node[31202] trap int3 ip:1c044d2 sp:7ffc3e40bbf0 error:0 in node[400000+4579000] Aug 13 00:05:44 Tower kernel: traps: node[31391] trap int3 ip:1c044d2 sp:7ffc0a24a420 error:0 in node[400000+4579000] Aug 13 00:05:47 Tower kernel: traps: node[31523] trap int3 ip:1c044d2 sp:7ffc8e5a96d0 error:0 in node[400000+4579000] Aug 13 00:05:50 Tower kernel: traps: node[31766] trap int3 ip:1c044d2 sp:7fff2662a0b0 error:0 in node[400000+4579000] Aug 13 00:05:53 Tower kernel: traps: node[31930] trap int3 ip:1c044d2 sp:7ffdb55d2fb0 error:0 in node[400000+4579000] Aug 13 00:05:56 Tower kernel: traps: node[32066] trap int3 ip:1c044d2 sp:7ffd30ddd4f0 error:0 in node[400000+4579000] Aug 13 00:05:59 Tower kernel: traps: node[32236] trap int3 ip:1c044d2 sp:7fff7c1d3790 error:0 in node[400000+4579000] Aug 13 00:06:02 Tower kernel: traps: node[32352] trap int3 ip:1c044d2 sp:7ffe76f5e300 error:0 in node[400000+4579000] Aug 13 00:06:05 Tower kernel: traps: node[32613] trap int3 ip:1c044d2 sp:7ffd9ab62580 error:0 in node[400000+4579000] Abgesehen von der Cache-Umstellung habe ich nichts geändert. syslog-192.168.0.125.log

ich möchte lösen: geht vollumfänglich

Hallo, nachdem ich eine Reihe von Containern auf Host bzw. Bridge umgestellt habe, ist der letzte verbliebe Docker, der NPM. NPM ist für mich ein one trick pony und ist für das Vaultwarden Zertifikat zuständig. Ich bin mir unsicher, ob es grundsätzlich geht und wie der Weg ist. Aktuell läuft der NPM auf br0 und hat die IP 192.168.02. Entsprechend verweist meine Domain auf eben jene 192.168.0.02. Da ich lediglich lokal bzw. via VPN auf Vaultwarden zugreife, braucht es keine Weiterleitungen im Router. Dns challenge funktioniert. Im NPM wird dann auf den Vaultwarden Docker weiter geleitet. Vaultwarden läuft im Bridge Mode und hat, wie auch der Unraid Server, die 192.168.0.125. Fragestellungen: Host oder Bridge für NPM? Umstellung des Server Ports, weg von der 80 und(?) 443 Umstellung der Verweises der Domain auf die Sever IP (192.168.0.125)? Geht das, habe ich etwas übersehen? Geht das so? Einen sonnigen Sonntag!

Danke, ich hab es schon befürchtet. 6.11 wird der einfachere Weg sein. Hoffentlich löst ein baldiges Update das Problem. Auf Dauer ohne aktuelle Patches, erzeugt ein massives Störgefühl.

Hallo, ich habe seit ein paar Tagen das Thema, dass der Unraid Server (6.12.2) in unregelmäßigen Abständen einfriert und nicht mehr zu erreichen ist; weder über die GUI erreichbar, noch via Terminal gepingt werden kann. Resette ich ihn, moppert er beim ersten Start beim Start von Container herum; insbesondere Nginx meldet beim Aufruf von Vaultwarden "bad Gateway". Ein weiterer Reset löst das Docker-Problem bis zum nächsten Absturz. Da ich eine Fritz!Box habe (die ich nicht tauschen kann), läuft Docker auf macvlan. Vor den Wechsel auf 6.12 hatte ich keine derartigen Probleme. Ich habe im Log folgende Warnungen bzw. Fehler gefunden: gestern: Jul 4 18:14:07 Tower kernel: BTRFS info (device loop2): using crc32c (crc32c-intel) checksum algorithm Jul 4 18:14:07 Tower kernel: BTRFS info (device loop2): using free space tree Jul 4 18:14:07 Tower root: mount: /var/lib/docker: can't read superblock on /dev/loop2. Jul 4 18:14:07 Tower root: dmesg(1) may have more information after failed mount system call. Jul 4 18:14:07 Tower root: mount error Jul 4 18:14:07 Tower kernel: BTRFS info (device loop2): enabling ssd optimizations Jul 4 18:14:07 Tower kernel: BTRFS info (device loop2): start tree-log replay Jul 4 18:14:07 Tower kernel: BTRFS warning (device loop2): log replay required on RO media Jul 4 18:14:07 Tower kernel: BTRFS error (device loop2): open_ctree failed Jul 4 18:14:07 Tower emhttpd: shcmd (52854): exit status: 1 heute: Jul 5 17:17:27 Tower kernel: docker0: port 5(veth49b268b) entered blocking state Jul 5 17:17:27 Tower kernel: docker0: port 5(veth49b268b) entered forwarding state Jul 5 17:17:40 Tower kernel: pcieport 0000:00:1c.4: AER: Corrected error received: 0000:00:1c.4 Jul 5 17:17:40 Tower kernel: pcieport 0000:00:1c.4: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID) Jul 5 17:17:40 Tower kernel: pcieport 0000:00:1c.4: device [8086:a394] error status/mask=00000001/00002000 Jul 5 17:17:40 Tower kernel: pcieport 0000:00:1c.4: [ 0] RxErr Jul 5 17:21:15 Tower ool www[26466]: /usr/local/emhttp/plugins/dynamix/scripts/rsyslog_config Jul 5 17:21:17 Tower rsyslogd: [origin software="rsyslogd" swVersion="8.2102.0" x-pid="26575" x-info="https://www.rsyslog.com"] start Jul 5 17:21:38 Tower kernel: pcieport 0000:00:1c.4: AER: Corrected error received: 0000:00:1c.4 Jul 5 17:21:38 Tower kernel: pcieport 0000:00:1c.4: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID) Jul 5 17:21:38 Tower kernel: pcieport 0000:00:1c.4: device [8086:a394] error status/mask=00000001/00002000 Jul 5 17:21:38 Tower kernel: pcieport 0000:00:1c.4: [ 0] RxErr Anbei auch noch ein Sylog, indem ich aber nichts relevantes sehe. Ich habe derweil das Dockimage neu angelegt und den USB Port auf einen 2.0 Port gewechselt. Ohne Erfolg. Der PCI-Bus Fehler oben gibt mir zu denken, da ich vor ein paar Wochen einen 2.5Ethernet-PCI Karte eingebaut habe....aber das ist auch nur stochern im Neben syslog-20230705-172532.txt

Alles Warten half nicht. Schlussendlich ein neues Zertifikat erstellt.

Die 9h waren wohl zu wenig. Werde nun mal versuchen, Nginx 24h deaktiviert zu lassen. Mal schauen, ob ich dann nicht mehr in die Sperre laufe.

Alles klar, danke, das werde ich versuchen und mal nen Bug-Report schreiben!

1. Jupp 2. Jupp, Port 80 ist im Router zu gewesen. 3. So, wie ich das verstehe, siehe 2 "customer service to find out if the limitation of requests can be increased". Ist das nicht die Fehlermeldung meines Providers? Kann ja eigentlich nicht sein, dass da eine Anfrage für das Zertifikat kommt, weil Port 80 zu ist? Nach dem Öffnen des Ports 80 im Router laufe ich anscheinend aufgrund der "limitation of requests" in den gleichen Fehler. "ailed to renew certificate npm-10 with error: Unexpected error determining zone identifier for bit.meinedom.de: More than 180 requests per minute. Please wait and retry later. Please contact our customer service to find out if the limitation of requests can be increased. (4013) All renewals failed. The following certificates could not be renewed: /etc/letsencrypt/live/npm-10/fullchain.pem (failure) 1 renew failure(s), 0 parse failure(s) Wo liegt mein Fehler, klär mich auf

Was ich dann aber nicht verstehe: "error: Command failed: certbot renew --non-interactive --quiet --config "/etc/letsencrypt.ini" --preferred-challenges "dns,http" --disable-hook-validation Failed to renew certificate npm-10 with error: Unexpected error determining zone identifier for meine.domain.de More than 180 requests per minute. Please wait and retry later. Please contact our customer service to find out if the limitation of requests can be increased. (4013)" Wie kommt es dann zu den Requesten? kommen die nicht via http?

Hallo, nachdem Vaultwarden nun seit ein paar Monaten stabil und zur vollsten Zufriedenheit läuft, steht nun eine Aktualisierung des Letsencrypt Zertifikats an. Ich habe versucht, nachdem ich per eMail benachrichtigt wurde, über die Nginx Maske zu erneuern, habe aber einen "internal error" innerhalb Nginx gemeldet bekommen. Initial hat es also nicht funktioniert und derweil moppert anscheinend Netcup, wegen zu vieler Anfragen. Ich habe Vaultwarden ohne eine routenseitige Freigabe von Port 80/443 laufen, was problemlos funktioniert Kann es sein, dass ich diese Ports zum aktualisieren des Zertifikates öffnen muß?

Du hast recht, CPUs gehen nicht mehr schlafen! Danke für den Tipp. Schade, aber für das "onetrickpony" passen dann Kosten-Nutzen nicht mehr. Thx

Hallo, ich bin verwundert und frage mich, ob das normal ist und nur meine Erwartung schief. Ausgangssituation: i3, 16gb, 2xSSD cache, 4xHdd, usb-card reader, docker (pi-hole, syncthing, ocrmypdf, oscam, TVH, jellyfin, vaultwarden, etc.) Das Stundenmittel über den Tag liegt bei ca. 13 Watt. Ziemlich prima, wie ich finde. Da ich meinen Dokumentenscanner gerne über eine VM mit Win10 "SMB" fähig machen will, habe ich das entsprechend eingerichtet (2CPUs zugewiesen) Für Stirnrunzeln sorgt aber, dass der Verbrauch, wenn Win10 auf dem Anmeldeschirm vor sich hin idelt, um 15 Watt hoch geht. Die VM liegt dabei auf dem Cache SSD und irgendwelche Indexierungen von Win10 sind auch abgeschlossen. Ist das normal?

Die „Hugedomain-Nummer“ ist nach wie vor da, wenn ich den Curl mache Die Domain ist mir vollkommen unbekannt und taucht im übrigen natürlich nirgendwo im PiHole auf….

Es ist vollbracht! 🥳 Nachdem ich mich nach vielen weiteren erfolglosen Versuchen komplett in der Sackgasse wähnte, habe ich das ganze nochmals komplett neu, inkl. neuer Subdomain auf anderer Domain auf dem Reserveserver gemacht, auch erfolglos. Einziger offener Punkt war, den PiHole komplett aus dem Spiel zu nehmen und es nochmals auf dem Hauptserver zu probieren. Ging sofort!! Wenn ich meine Malereien so im Nachgang betrachte, habe ich mir eine Reihe von (überflüssigen)Schleifen eingebaut, was den DNS angeht. Da das leicht willen- und kenntnisslose initiale einrichten von PiHole den gewünschten Effekt hatte, die Werbung war weg, hab ich nicht weiter ins Detail geschaut. Ich habe das ganze dann nochmal mit sauber gemacht und siehe da, es läuft alles perfekt. @Archonw&@mgutt ganz herzlichen Dank für die Hilfe und Denkanstöße! Ne Menge gelernt. Nochmals Danke!

Connected to bit.meinedomain.com (3.x.x.x) port 80 (#0) > GET / HTTP/1.1 > Host: bit.meinedomain.com > User-Agent: curl/7.84.0 > Accept: */* > * Mark bundle as not supporting multiuse < HTTP/1.1 302 Found < content-length: 0 < date: Sat, 17 Dec 2022 09:08:09 GMT < location: https://www.hugedomains.com/domain_profile.cfm?d=meindomain.com < * Connection #0 to host bit.meindomain.com left intact * Clear auth, redirects to port from 80 to 443 * Issue another request to this URL: 'https://www.hugedomains.com/domain_profile.cfm?d=meindomain.com' * Trying 0.0.0.0:443... * connect to 0.0.0.0 port 443 failed: Connection refused * Failed to connect to www.hugedomains.com port 443 after 8 ms: Connection refused * Closing connection 1 curl: (7) Failed to connect to www.hugedomains.com port 443 after 8 ms: Connection refused

Guten Morgen!