跟踪重定向源

发布于 2024-12-29 21:19:36 字数 776 浏览 2 评论 0原文

有没有办法跟踪哪个文件导致重定向？我的网站通过 302 重定向从非 www 重定向到 www 版本，尽管我在 htaccess 中定义了 301 重定向。该文件似乎被忽略。

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

即使我将规则更改为 .com 结尾，我仍然会被重定向到 www.dreadfactory.de。所以看起来该文件被完全忽略了。我尝试一一禁用每个插件和主题，并检查核心文件是否有更改。

有什么方法可以跟踪从哪个位置/文件调用重定向？

更新：

我刚刚发现了更多重定向问题：所有非 www 网址都被重定向到网站的根目录。 “dreadfactory.de/angebot”被重定向到“www.dreadfactory.de”。这很不寻常，我还没有发现为什么会发生这种情况......

原文

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...

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

桃气十足 2025-01-05 21:19:36

我建议您将其添加到您的 VirtualHost/htaccess 中。记录 mod_rewrite 的活动。这将有助于调试，并且 RewriteLogLevel 越高，调试效果越好。

RewriteEngine On
RewriteLog "/path/to/your/rewrite.log"
RewriteLogLevel 3

来自 RewriteLogLevel ^文档：

要禁用重写操作的日志记录，只需将级别设置为 0。这将禁用所有重写操作日志。
使用较高的 Level 值会显着降低 Apache 服务器的速度！使用级别大于 2 的重写日志文件仅用于调试！

我建议您使用RewriteLogLevel 9。但调试完成后一定要降低级别。

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.

回复收藏 0 原文

长途伴 2025-01-05 21:19:36

设置包含脚本的环境转储目标

<?php
phpinfo(INFO_ENVIRONMENT);

，并逐步构建规则，将任何中间体转储到环境标志，您可以使用 [E=TEST:%1%{HTTP},E=TEST2:whateverparametersorexpressions]< /code> 在 RewriteRule 上，但请记住模式和规则必须匹配才能将内插字符串存储到 env 变量。然后中断并对 env info 脚本进行内部重定向。您会发现当前传递的变量位于 REDIRECT_* 中，前一个传递位于 REDIRECT_REDIRECT_* 等中。

这需要一些时间来适应，但如果您没有访问权限，这是调试基于 .htaccess 的 rewrtie 逻辑的唯一方法重写日志。

它还可以帮助您发现有时盲目明显的情况 - 例如，如果 %{HTTP_HOST} != dreadfactory.de （这是更清晰的编写方式。），您的第一个条件就会成功，包括 www.dreadfactory.de。

还可以使用完整的 phpinfo 找出 apache 配置的位置（例如 /etc/httpd）并执行 tar -C etc -czf SomethingyouvegotFTPaccess/httpd.tar.gz httpd 然后查看此内容以确保你的 HSP 并没有做任何事情来把事情搞砸。

抱歉，对于共享主机用户来说，这个问题没有简单的答案。我已经构建了一个虚拟机，我可以在其中获得 root 访问权限，并镜像我的 HSP 配置以进行测试 - 即使如此，我仍然偶尔需要尝试这种技巧。

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.

回复收藏 0 原文