Halkali Merkez Viertel Fatih Str. Ozgur Apt. No. 46, Kucukcekmece, Istanbul, 34303, TR
www und non-www sind technisch unterschiedliche Hosts. Eine Version muss als Canonical gewählt werden und die andere muss mit einer einzigen 301-Weiterleitung zum HTTPS-Canonical-Ziel weitergeleitet werden. Das Zertifikat muss beide Hosts abdecken, und Subdomains dürfen nicht versehentlich mit einem breiten regulären Ausdruck zur Hauptdomain weitergeleitet werden.
Türkei (Türkisch)
Germany (German)
Worldwide (English)
www.example.com -> example.com
301 Moved Permanently
SSL_ERROR_BAD_CERT_DOMAIN
Redirect loop
Canonical host mismatchwww und non-www sind technisch unterschiedliche Hosts. Eine Version muss als Canonical gewählt werden und die andere muss mit einer einzigen 301-Weiterleitung zum HTTPS-Canonical-Ziel weitergeleitet werden. Das Zertifikat muss beide Hosts abdecken, und Subdomains dürfen nicht versehentlich mit einem breiten regulären Ausdruck zur Hauptdomain weitergeleitet werden.
Erwarten Sie kein „.htaccess“-Ergebnis, ohne die Apache-, LiteSpeed-, Plesk-Proxy- oder NGINX-only-Struktur zu reservieren.
Sichern Sie die aktuelle Datei mit dem Datum; Suchen Sie die Anweisung und Zeile im Apache/LiteSpeed-Fehlerprotokoll.
Ändern Sie die Umleitungs-, Rewrite-, Header- und Zugriffsregeln nicht gleichzeitig.
Messen Sie Status, Standort, Inhaltstyp und Weiterleitungsanzahl mit Curl und überprüfen Sie die Cache-Ebenen separat.
Verwenden Sie keinen vom Benutzer stammenden Host-Header als Weiterleitungsziel.
Bedeutung: Die www- und non-www-Regeln leiten zueinander weiter.
Mögliche Ursache: Zwei Panel- oder zwei `.htaccess`-Regeln.
Bedeutung: Die TLS-Überprüfung schlägt fehl, bevor die Weiterleitung stattfindet.
Mögliche Ursache: Sertifika SAN listesinde www yok.
Bedeutung: Die Host-Bedingung ist zu breit gefasst.
Mögliche Ursache: Alle `*.example.com`-Subdomains werden zugeordnet.
Bedeutung: Protokoll und Host befinden sich in separaten Regeln.
Mögliche Ursache: Zuerst HTTPS, dann non-www.
Bedeutung: Die Home-/Website-URL zeigt auf einen anderen Canonical-Host.
Mögliche Ursache: Anwendungs-URL-Einstellung.
Bedeutung: Panel und `.htaccess` verwenden unterschiedliche Ziele.
Mögliche Ursache: Zwei Verwaltungspunkte.
Bedeutung: Edge und Origin zielen auf unterschiedliche Hosts.
Mögliche Ursache: Doppelte Weiterleitung.
Bedeutung: Host-Varianten können separate URL-Prefix-Propertys sein.
Mögliche Ursache: Normale Eigenalleertrennung.
Es wurden keine Datensätze gefunden, die diesem Ausdruck entsprechen.
for u in http://example.com https://example.com http://www.example.com https://www.example.com; do curl -sS -o /dev/null -w "$u -> %{http_code} %{url_effective} redirects:%{num_redirects}\n" -L "$u"; doneVergleicht alle grundlegenden URL-Varianten.
curl -sIL --max-redirs 10 http://www.example.com/path?x=1 | grep -iE '^HTTP|^location:'Zeigt die Weiterleitungskette mit Pfad und Query.
echo | openssl s_client -connect example.com:443 -servername www.example.com 2>/dev/null | openssl x509 -noout -ext subjectAltNameZeigt, ob das Zertifikat die www- und non-www-Hosts abdeckt.
grep -nE 'HTTP_HOST|SERVER_NAME|www\\.|example\\.com|R=301' .htaccessFindet die canonical Host-Regeln.
dig +short example.com A; dig +short www.example.com A; dig +short www.example.com CNAMEZeigt die DNS-Ziele für www und die Root-Domain.
curl -sL https://example.com/path | grep -ioE '<link[^>]+rel=["'"']canonical["'"'][^>]*>' | head -n 1Zeigt den Canonical-Host der Zielseite.
RewriteCond %{HTTP_HOST} www.example.com
RewriteRule ^ http://example.com%{REQUEST_URI} [R=301,L]RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP_HOST} !^example\.com$ [NC]
RewriteRule ^ https://example.com%{REQUEST_URI} [R=301,L]RewriteCond %{HTTP_HOST} !^www\.
RewriteRule ^ https://www.%{HTTP_HOST}%{REQUEST_URI} [R=301,L]RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP_HOST} !^www\.example\.com$ [NC]
RewriteRule ^ https://www.example.com%{REQUEST_URI} [R=301,L]RewriteCond %{HTTP_HOST} !^example\.com$
RewriteRule ^ https://example.com%{REQUEST_URI} [R=301,L]RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
RewriteRule ^ https://example.com%{REQUEST_URI} [R=301,L]RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]RewriteCond %{HTTP_HOST} ^(?:www\.)?example\.com$ [NC]
RewriteRule ^ https://example.com%{REQUEST_URI} [R=301,L]Die vollständige Host-Bedingung und das endgültige HTTPS-Ziel können in einem einzigen Regelsatz verwaltet werden.
DNS-Proxy und Edge-Redirect können mit Ursprungsregeln in Konflikt geraten.
Die Domain-Einstellungen der Anwendung und des Panels müssen mit dem gewählten Host übereinstimmen.
Nein. NGINX liest keine `.htaccess`-Dateien. Die Regel muss in eine `server`- oder `location`-Konfiguration übersetzt werden.
In der Regel nicht; Apache wertet die `.htaccess`-Datei bei jeder Anfrage aus. Für Änderungen am VirtualHost, an Modulen oder an AllowOverride ist jedoch ein Reload/Restart erforderlich.
Es sollte eine datierte Sicherung der vorhandenen Datei erstellt, das aktive Document Root überprüft und die Änderung in der Staging-Umgebung oder zu verkehrsschwachen Zeiten getestet werden.
In cPanel befindet es sich meist in `public_html`, in Plesk in `httpdocs`; Addon-Domains und Subdomains können ein anderes Document Root haben.
LiteSpeed unterstützt die meisten Regeln durch Apache-Kompatibilität; einige Modul- und Handler-Verhaltensweisen können abweichen.
Vollständige Direktive und Zeilenrekord im Apache/LiteSpeed-Fehlerprotokoll. Die Datei sollte gemäß dem Protokoll wiederhergestellt werden, anstatt sie zufällig zu löschen.
Domain sollte nicht direkt ohne Überprüfung von Domain, Dokumentenwurzel, Proxy, WordPress und Serverstruktur hinzugefügt werden. Beispiele sollten angepasst und getestet werden.
Wir untersuchen Umleitungs-, Umschreibe-, CORS-, Zugriffs- und 500 -Fehler mit Protokollen in cPanel-, Plesk-, LiteSpeed-, WordPress-, benutzerdefinierten PHP- und WISECP-Strukturen.