{"id":1180,"date":"2026-03-25T12:25:20","date_gmt":"2026-03-25T09:25:20","guid":{"rendered":"https:\/\/allinonewpsettings.com\/blog\/?p=1180"},"modified":"2026-08-04T21:56:30","modified_gmt":"2026-08-04T21:56:30","slug":"wordpress-wp-admin-weiterleitungsschleife","status":"publish","type":"post","link":"https:\/\/allinonewpsettings.com\/blog\/de\/wordpress-wp-admin-weiterleitungsschleife\/","title":{"rendered":"wp-admin-Weiterleitungsschleife nach dem Login beheben"},"content":{"rendered":"

Ein Administrator gibt g\u00fcltige Zugangsdaten ein, erreicht kurz wp-admin<\/code> und landet wieder beim Login. Die \u00f6ffentliche Website funktioniert. Der Proxy greift intern per HTTP auf WordPress zu, obwohl der Besucher HTTPS verwendet; mehrere Ebenen versuchen deshalb, einen vermeintlich falschen Zustand zu korrigieren.<\/p>\n

Das Kennwort muss nicht die Ursache sein. Zeichnen Sie zuerst Weiterleitungen und Cookie-\u00dcberg\u00e4nge auf und suchen Sie die erste Antwort, die dem vorgesehenen Host, Protokoll, Anmeldestatus oder Pfad widerspricht.<\/p>\n

\nInhaltsverzeichnis<\/strong><\/p>\n
    \n
  1. Was das Thema bedeutet<\/a><\/li>\n
  2. Ein realistisches WordPress-Beispiel<\/a><\/li>\n
  3. Warum es wichtig ist und wann es eingesetzt wird<\/a><\/li>\n
  4. Der einfache Weg f\u00fcr Einsteiger<\/a><\/li>\n
  5. Der technische Weg<\/a><\/li>\n
  6. Risiken, h\u00e4ufige Fehler, Backup und R\u00fcckweg<\/a><\/li>\n
  7. Wie AIOWS unterst\u00fctzt: AIOWS Login Manager<\/a><\/li>\n
  8. Passende AIOWS-Artikel<\/a><\/li>\n
  9. Fazit und empfohlener Weg<\/a><\/li>\n
  10. Offizielle Quellen<\/a><\/li>\n<\/ol>\n<\/div>\n

    Was das Thema bedeutet<\/h2>\n

    Eine wp-admin<\/code>-Schleife entsteht, wenn Login, Verwaltung, kanonische URL-Logik, Proxy, Cache oder Sicherheitsregel den Browser wiederholt zwischen Adressen senden, statt das angemeldete Dashboard auszuliefern.<\/p>\n

    Zu jeder Antwort geh\u00f6ren Status, Location<\/code> und Set-Cookie<\/code>. An der folgenden Anfrage l\u00e4sst sich erkennen, ob der Browser das Authentifizierungs-Cookie f\u00fcr die erwartete sichere Domain und den richtigen Pfad zur\u00fcckgesendet hat.<\/p>\n

    Ein realistisches WordPress-Beispiel<\/h2>\n

    Im Beispiel sendet der Browser die Zugangsdaten per HTTPS und WordPress setzt ein sicheres Authentifizierungs-Cookie. Der Proxy leitet die n\u00e4chste Anfrage intern als HTTP weiter, ohne das vertrauensw\u00fcrdig erkannte urspr\u00fcngliche Protokoll zu \u00fcbermitteln. WordPress setzt erneut zur Weiterleitung an.<\/p>\n

    Die korrekte HTTPS-Erkennung f\u00fcr genau diesen Proxy beseitigt den Widerspruch. Danach werden direkter wp-admin<\/code>-Aufruf, Logout, Passwort-Reset und eine neue Sitzung gepr\u00fcft, bevor der alte Redirect aus dem Cache verschwindet.<\/p>\n

    Warum es wichtig ist und wann es eingesetzt wird<\/h2>\n

    Eine Admin-Schleife verhindert dringende Wartungsarbeiten und weist oft auf einen gr\u00f6\u00dferen Fehler bei kanonischen URLs oder der Proxykonfiguration hin. Sie wird als Folge konkreter Antworten untersucht, nicht als unbestimmtes Browser- oder Kennwortproblem.<\/p>\n

    Halten Sie Hostingzugang, Backup und jede noch funktionierende Administratorsitzung bereit. Der Vergleich zwischen \u00f6ffentlichem Weg und autorisiertem Direktzugriff auf den Ursprung zeigt, ob der erste falsche Sprung am Edge, Server oder in WordPress entsteht.<\/p>\n

    Der einfache Weg f\u00fcr Einsteiger<\/h2>\n
      \n
    1. Sichern Sie WordPress- und Website-Adresse, Login-Konfiguration, Proxyeinstellungen und aktuelle Weiterleitungsregeln.<\/li>\n
    2. Erfassen Sie die gesamte Kette mit Status, Location<\/code>, Set-Cookie<\/code>, angefordertem Host und Protokoll sowie Cache-Hinweisen.<\/li>\n
    3. Pr\u00fcfen Sie, ob WordPress HTTPS und den kanonischen Host nur anhand der Angaben des bekannten Proxys erkennt.<\/li>\n
    4. Kontrollieren Sie Domain, Pfad und Secure-Attribut des Authentifizierungs-Cookies sowie seine R\u00fcckgabe bei der n\u00e4chsten Anfrage.<\/li>\n
    5. \u00c4ndern Sie eine zust\u00e4ndige Ebene und testen Sie danach g\u00fcltigen und ung\u00fcltigen Login, wp-admin<\/code>, Logout, Reset, abgelaufene Sitzung und eigenen Loginpfad.<\/li>\n<\/ol>\n

      Der technische Weg<\/h2>\n

      Ber\u00fccksichtigen Sie Unterordnerinstallationen, Multisite-Zuordnungen, alternative Hosts, mobile Zugriffe und jeden Cache f\u00fcr 301-, 302- oder Loginantworten. Umgehen Sie jeweils nur einen vermuteten Erzeuger auf unterst\u00fctzte, umkehrbare Weise.<\/p>\n

      Zeichnen Sie die Kette als gerichtete Spr\u00fcnge und benennen Sie den Erzeuger. Funktioniert nur der direkte Ursprung, liegt der n\u00e4chste Pr\u00fcfschritt bei Edge oder Proxy; verhalten sich beide Wege gleich, folgen Server und WordPress.<\/p>\n

      Risiken, h\u00e4ufige Fehler, Backup und R\u00fcckweg<\/h2>\n

      Vertrauen Sie keinen beliebigen Client-Headern, \u00e4ndern Sie Kennw\u00f6rter nicht ohne entsprechenden Befund und leeren Sie nicht alle Caches vor der Zuordnung. Ungepr\u00fcfte \u00c4nderungen an home<\/code> oder siteurl<\/code> verschieben m\u00f6glicherweise auch die \u00f6ffentliche Website.<\/p>\n

      Stellen Sie den letzten funktionierenden Zustand wieder her, wenn die Kette l\u00e4nger wird, \u00f6ffentliche kanonische URLs wandern, Cookies offengelegt werden oder der Administratorzugang verloren geht. Entfernen Sie erst nach der Korrektur gezielt die veraltete Cacheantwort.<\/p>\n

      \n

      Wie AIOWS unterst\u00fctzt:<\/p>\n

      AIOWS Login Manager<\/h2>\n

      Der AIOWS Login Manager macht unterst\u00fctzte Einstellungen f\u00fcr Login-Schutz und eigene Zugangswege in WordPress sichtbar. Pr\u00fcfen Sie diese Ebene als m\u00f6glichen Redirect-Erzeuger und lassen Sie unabh\u00e4ngige Regeln unver\u00e4ndert.<\/p>\n

      Bevor eine verd\u00e4chtige Einstellung deaktiviert wird, muss eine offene Administratorsitzung oder ein dokumentierter serverseitiger Notfallzugang bestehen. Anschlie\u00dfend werden Administrator und normaler Benutzer, richtige und falsche Zugangsdaten, Passwortwiederherstellung sowie eigener und Standardpfad in einem neuen privaten Browserfenster getestet.<\/p>\n

      Proxy-TLS-Erkennung, Cookievorgaben anderer Ebenen, CDN-Caches und Webserverweiterleitungen kann AIOWS nicht reparieren. Das Modul h\u00e4lt jedoch die WordPress-seitigen Loginregeln nachvollziehbar und umkehrbar.<\/p>\n

      AIOWS Login Manager ansehen<\/a>AIOWS-Tarife vergleichen<\/a><\/p>\n<\/section>\n

      Passende AIOWS-Artikel<\/h2>\n