共计 1137 个字符，预计需要花费 3 分钟才能阅读完成。
nginx 下反向代码 apache 下的 wordpress 启用证书后的数据流大体如下：
因为 wordpress 在接管到申请后会进行：以后申请信息是否与数据库中设置的以后网站地址相一致。从而导致在进行数据转发时因为在 nginx 层面产生了 https 与 http 的转换，进而导致了 301 的问题。对应下面的数据流，对应的流程如下：
如果把 wordpress 中的网站地址变更为：http://www.codedemo.club，则因为在判断协定的时候 http 与 http 雷同，则不会产生 301 的谬误。但因为 wordpress 外部发送动态资源地址时，地址上退出了网站前缀，比方发送的 CSS 地址为：http://www.codedemo.club/sytle.css，而非 /sytle.css。这将触发一个浏览器的一个爱护机制 —- 浏览器 阻止：在一个 https 的页面上调用 http 申请。
吐个槽：话说学校某教学相干的零碎正是因为在 https 页面上加载了 http 插件，从而导致一些 EXCEL 的导出无奈失常工作了。
解决方案
联合上文形容以及在因为定制端口导致的 301 重定向问题
一文中的剖析，得出以下论断：若要防止 wordpress 的 301 问题，则必须保障转发给 wordpress 的 域是雷同的。
又因为 域雷同的三要素是：协定、域名、端口号。所以最终的论断是：若要防止 wordpress 的 301 问题，则必须保障转发给 wordpress 的 协定、域名、端口号 都是雷同的。
nginx+apache 全面启用 https
在 apache 中启用 https，nginx 在进行转发时将数据按 apache 的证书进行加密后，传给 apache 服务：
以上便保障了拜访 wordpress 时协定也是 https 的。
这个计划最大的问题在于须要别离对 nginx、apache 配置证书。nginx 在进行数据转发时，进行了数据的解密与加密，apache 又从新对数据进行了一次解密。从效率上来讲必定是最低的，当然也是最不值得举荐的计划。
批改 wordpress 源码
另一种计划是在 nginx 将以后协定通过 header 转发。wordpress 判断转发的 header 信息中协定是否为 https。如果为 https 则重置零碎变量，从而让 wordpress 误认为以后的 http 申请为 https 申请：
修改文件为：wp-config.php
define('WP_DEBUG', false);
+ if ($_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https' )
+ {+ $_SERVER['HTTPS'] = 'on';
+ $_SERVER['SERVER_PORT'] = 443;
+ }
本计划须要对 wordpress 源码进行批改，尽管解决了问题，但仍有待欠缺。
