IE访问WordPress多站点子站时内容不更新问题求助

这问题我之前帮客户排查过类似的，IE的缓存机制和重定向处理逻辑确实和Chrome、Firefox这些现代浏览器不太一样，咱们一步步拆解原因和解决方案：

为什么只有IE会返回304？ #

304状态码表示“请求的资源未修改，使用本地缓存”，而其他浏览器收到的301是永久重定向，核心差异出在这几个点：

• IE缓存策略更激进：尤其是针对带登录Cookie的请求，IE会优先依赖本地缓存，当服务器端的缓存验证字段（比如Last-Modified、ETag）匹配时，直接返回304，跳过了本该触发的301重定向。
• 多站点重定向规则的UA兼容性：你的服务器（Apache/Nginx）重定向规则可能对IE的User-Agent处理存在漏洞，没有正确触发301，反而让缓存逻辑优先生效。
• URL生成逻辑的解析差异：登录后子站页面生成的链接可能因为IE对根路径/相对路径的解析逻辑不同，指向了主站的对应页面，而主站该页面刚好有缓存记录，返回304。

无需修改子站URL的解决方案 #

下面几个方案按优先级尝试：

1. 给登录用户的页面强制禁用缓存 #

在子站的functions.php中添加以下代码，让登录后的页面强制IE不缓存，从根本上避免304触发：

function disable_ie_cache_for_logged_in_users() {
    if (is_user_logged_in()) {
        // 强制禁用所有缓存
        header("Cache-Control: no-cache, no-store, must-revalidate");
        header("Pragma: no-cache");
        header("Expires: 0");
    }
}
add_action('init', 'disable_ie_cache_for_logged_in_users');

2. 检查并修复多站点的重定向规则 #

Apache（.htaccess）

确认你的多站点重定向规则完整且正确，确保所有请求都被正确路由到子站，示例规则如下：

RewriteEngine On
RewriteBase /

# 优先处理子站路径
RewriteRule ^sub-installation/(.*)$ sub-installation/$1 [L]

RewriteRule ^index\.php$ - [L]
RewriteRule ^wp-admin$ wp-admin/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^(wp-(content|admin|includes).*) $1 [L]
RewriteRule ^(.*\.php)$ $1 [L]
RewriteRule . index.php [L]

重点是添加优先匹配子站路径的规则，确保IE的请求不会被主站的缓存逻辑拦截。

Nginx

在Nginx的server配置块中，添加针对子站的路由规则，确保返回301而不是触发缓存：

location /sub-installation {
    try_files $uri $uri/ /sub-installation/index.php?$args;
    # 强制添加缓存禁用头给登录用户
    add_header Cache-Control "no-cache, no-store, must-revalidate" if $http_cookie~*"wordpress_logged_in_";
}

3. 强制IE使用最新文档模式 #

IE的兼容模式可能导致URL解析错误，在子站的<head>最顶部添加以下标签，强制IE用最新的渲染模式：

<meta http-equiv="X-UA-Compatible" content="IE=edge">

4. 验证WordPress多站点的URL配置 #

登录WordPress后台，进入子站的设置 -> 常规，确认：

• 站点地址（URL）：https://example.com/sub-installation
• WordPress地址（URL）：https://example.com/sub-installation
  如果用WP CLI，也可以快速检查所有站点的配置：

wp site list

确保子站的URL没有使用相对路径或错误的根地址。

验证方法 #

打开IE的F12开发者工具，切换到Network标签，勾选“禁用缓存”，然后重新登录子站测试。如果此时不再出现304且内容正常更新，说明缓存是核心问题，方案1即可解决。

内容的提问来源于stack exchange，提问作者Mark Pedersen