首页  >  问答  >  正文

为什么我的 .htaccess 和重写规则可能与建议的配置不同?

我继承了一个现有的(而且有很多问题)wordpress.org 网站,并且我很难理解前任所有者决定对 .htaccess 文件做出的选择/规则。

我一直在尝试用谷歌搜索它的不同部分并查看不同的文档,但有些部分我找不到答案

我使用了 htaccess 测试器,满足了一些规则,但很多规则不满足 测试人员无法检查“ifmodule”语句,也无法理解 CacheLookup on

# BEGIN LSCACHE
## LITESPEED WP CACHE PLUGIN - Do not edit the contents of this block! ##
<IfModule LiteSpeed>
RewriteEngine on
CacheLookup on
RewriteRule .* - [E=Cache-Control:no-autoflush]
RewriteRule \.litespeed_conf\.dat - [F,L]

### marker CACHE RESOURCE start ###
RewriteRule wp-content/.*/[^/]*(responsive|css|js|dynamic|loader|fonts)\.php - [E=cache-control:max-age=3600]
### marker CACHE RESOURCE end ###

### marker FAVICON start ###
RewriteRule favicon\.ico$ - [E=cache-control:max-age=86400]
### marker FAVICON end ###

### marker WEBP start ###
RewriteCond %{HTTP_ACCEPT} "image/webp"
RewriteRule .* - [E=Cache-Control:vary=%{ENV:LSCACHE_VARY_VALUE}+webp]
RewriteCond %{HTTP_USER_AGENT} iPhone.*Version/(\d{2}).*Safari
RewriteCond %1 >13
RewriteRule .* - [E=Cache-Control:vary=%{ENV:LSCACHE_VARY_VALUE}+webp]
### marker WEBP end ###

### marker DROPQS start ###
CacheKeyModify -qs:fbclid
CacheKeyModify -qs:gclid
CacheKeyModify -qs:utm*
CacheKeyModify -qs:_ga
### marker DROPQS end ###

</IfModule>
## LITESPEED WP CACHE PLUGIN - Do not edit the contents of this block! ##
# END LSCACHE
# BEGIN NON_LSCACHE
## LITESPEED WP CACHE PLUGIN - Do not edit the contents of this block! ##
## LITESPEED WP CACHE PLUGIN - Do not edit the contents of this block! ##
# END NON_LSCACHE


#Begin Really Simple Security
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{HTTPS} !=on [NC]
RewriteRule ^(.*)$ https://%{HTTP_HOST}/ [R=301,L]
</IfModule>

#End Really Simple Security
# BEGIN WordPress
# The directives (lines) between "BEGIN WordPress" and "END WordPress" are
# dynamically generated, and should only be modified via WordPress filters.
# Any changes to the directives between these markers will be overwritten.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

首先,测试人员说

RewriteEngine on

Only the last RewriteEngine line is taken into account

如果是这样,为什么要为每个标记部分添加它?我可以省略这个吗?

此外,许多 litespeed 规则都没有得到满足,但我也认识到有一些部分它无法理解/看到

似乎缺少 litespeed .htaccess 上设置的“示例规则”部分和重写规则

为什么他们可能会更改“建议”示例规则的某些部分?例如我的文件说

RewriteCond %{HTTP_ACCEPT} "image/webp"

(测试人员无法检查,因为该变量对其未知) 但示例重写规则包括[或]

RewriteCond %{HTTP_ACCEPT} "image/webp" [or]

另外,我不确定他们为什么决定包含 if 语句来检查哪个模块? (这些有什么优点,或者这些“ifmodule”标签可以删除吗?)

最后,这可能是一个愚蠢的问题 - “真正简单的 SSL”与/以前称为“真正简单的安全”相同吗? 如果是,我应该将 .htaccess 更新为非常简单的 SSL .htaccess 指南吗?

我希望这个帖子也可以帮助其他尝试配置其网站的人。

P粉505450505P粉505450505251 天前367

全部回复(1)我来回复

  • P粉032900484

    P粉0329004842024-01-17 13:07:16

    在我看来,他们决定安装许多不同的 WordPress 插件,每个插件都将自己的部分添加到 .htaccess 中。看起来没有人按照任何计划构建此配置。

    RewriteEngine On 被包含多次,因为每个插件都希望确保它已设置。拥有多个这样的语句除了占用空间和处理时间之外不会造成任何损害。

    IfModule 指令由插件添加,以便在未启用所需的 Apache 模块时站点不会立即收到“500 内部服务器错误”。如果没有模块,规则就没有任何效果,因此在您知道启用了哪些 Apache 模块的计算机上实现您自己的规则时,添加对模块的检查几乎没有意义。

    我的猜测是,这些规则是由旧版本的插件添加的,而不是手动编辑的。可能有人尝试自定义该文件,但情况不一定如此。

    我警告不要在 BEGINEND 注释之间进行大量编辑。插件将这些标记放在那里,以便它们可以在升级过程中替换自己的规则。您所做的任何更改都可能在某个时刻被覆盖。

    我建议查看该网站实际需要哪些 WordPress 插件。看起来可能安装了多个缓存插件,并且它们可能相互冲突。我首先会削减提供您所需功能的最少插件集。

    您应该升级所有插件以修补可能的安全漏洞,并确保每个插件的重写规则也更新为最新。

    回复
    0
  • 取消回复