问题
is there a way to trace which file causes a redirection? My website redirects from non-www to www version with a 302 redirect, eventhough I defined a 301 redirect in my htaccess. The file seems to be ignored.
RewriteEngine On
RewriteCond %{HTTP_HOST} ^dreadfactory\.de$ [NC]
RewriteRule ^(.*)$ http://www.dreadfactory.de/$1 [R=301,L]
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
Even if I change the rule to a .com ending, I'm still redirected to www.dreadfactory.de. So it seems, that the file is completely ignored. I tried to disable every plugin and the theme one by one and I checked the core files for changes.
Is there any way to trace from which position/file the redirect is called?
- UPDATE:
I just discovered some more redirect issues: all non-www urls are redirected to the root of the website. "dreadfactory.de/angebot" is redirected to "www.dreadfactory.de". That's quite unusual and I have not yet discovered why that is happening...
回答1:
I would suggest you to add this in your VirtualHost/htaccess. To log the activities of mod_rewrite. It Will be helpful for debugging and higher the RewriteLogLevel better for debugging.
RewriteEngine On
RewriteLog "/path/to/your/rewrite.log"
RewriteLogLevel 3
From RewriteLogLevel Docs:
To disable the logging of rewriting actions simply set Level to 0. This disables all rewrite action logs. Using a high value for Level will slow down your Apache server dramatically! Use the rewriting logfile at a Level greater than 2 only for debugging!
I would suggest you to use RewriteLogLevel 9. But do reduce the level after you are done debugging.
回答2:
Set up an evironment dumping target containing the script
<?php
phpinfo(INFO_ENVIRONMENT);
and build up your rules step by step dumping any intermediates to environment flags which you can collect using [E=TEST:%1%{HTTP},E=TEST2:whateverparametersorexpressions] on the RewriteRule, but remember that the patterns and rules must match to store the interpolated string to the env variable. Then break off and do an internal redirect to the env info script. You'll find the variables on the current pass are in REDIRECT_*, and the previous pass in REDIRECT_REDIRECT_* etc.
It takes some getting used to but its the only way to debug .htaccess-based rewrtie logic if you don't have access to rewrite logs.
It will also help you to spot the sometime blindly obvious -- like your first condition will succeed if %{HTTP_HOST} != dreadfactory.de (which is clearer way of writing this.) including www.dreadfactory.de.
Also use a full phpinfo to find out where the apache config is (say /etc/httpd) and exec a tar -C etc -czf somewhereyouvegotFTPaccess/httpd.tar.gz httpd then review this to make sure that your HSP isn't doing something to muck things up for you.
Sorry but there's no easy answer to this one for shared hosting users. I've build a VM where I've got root access and which mirrors my HSP config for my testing -- and even then I still occasionally need to get up to this sort of trick.
回答3:
Problem solved. Turns out, the problem was not htaccess connected. The DNS entries were messed up.
来源：https://stackoverflow.com/questions/9069455/trace-redirection-source