今天在调试一个其他问题时碰巧发现了一个奇怪的情况：根据我的 RewriteRule ，明明应该被 rewrite 到静态 HTML 缓存的请求，却在返回的 HTTP 头里看到了 PHP ！这个 rewrite 规则应该是经过测试的，怎么突然就失效了？
第一怀疑对象是自己手贱。毕竟是个人 VPS 上的 Apache 配置，也没有使用版本控制之类的，不能确定是不是改过什么。就排查了一下。结果发现 RewriteLogLevel 这个配置竟然无效了？一查才发现，原来 Apache 2.4 里把 rewrite 日志合并到了 error 中，只需要在错误日志里加上 rewrite:traceN 就行了（其中 N 是错误级别，4足够，8应该是最详细的）。盯着错误日志看了半天，发现一个“有趣”的现象——明明已经正确匹配、 rewrite 到了静态文件，却又接着发起了 sub request ，请求了 index.php ？！
为了更好说明问题，我把我的配置简化了一下，大概是这样：
新年的第一篇博客，感谢正在阅读的你。新年快乐！新年新气象，由于种种原因，我最后下定决心把博客整体迁移到 HTTPS 。简单记录一下过程。
申请的是 StartSSL 的免费版证书。体验很一般。整个网站响应缓慢，界面一股十年前的风格，还动不动丢失 session 必须重新来过，周末晚上也不提供服务。一开始使用了宿舍地址，被拒绝；人工沟通后被告知要使用个人的永久地址，折腾了好几次才办下来。不过也因此确定了一件事情：整个验证服务很多关键点上都是客服人工操作，直接回复发验证码过来的那个邮箱竟然在很短时间内就收到了客服的答复（赞一下效率）。不过还是觉得，有些地方明显是可以程序自动化的，期待今年夏季要上线的 Let’s Encrypt 。另外，鉴于 StartSSL 的用户体验，愿意掏一点点钱的话，可以去 namecheap 买最便宜的那个证书，一年也只要10刀，省心不少。
部署的话网上有很多文档了。首先（或者说，应该在申请证书的时候）应该自己先搞清楚一些公私钥体系的基本概念：根证书、 CA 、服务器证书、服务器私钥这些是什么东西。简单来说 HTTPS 的核心是一个公私钥加密系统，私钥必须保密存放在服务器上，公钥（证书）会被服务器传送给客户端使用。为了确保这一对密钥真的属于这个服务器，还构建了一套信用体系：浏览器内置了若干 Root CA ，这些 CA 可以信任（签署）其他下级 CA 或者是某个服务器证书。浏览器拿到服务器发来的证书时就会检查这个信任链。如果任何一环的签署有问题（甚至干脆就是自己给自己签发的），就会变成“不可信证书”。
mod_rpaf （Reverse Proxy Add Forward）是 Apache 2.2 及更低版本中一个很有用的第三方模块，主要用于后端 Web Server ，可以将请求的 remote ip 重写为指定的字段（例如 X-Forwarded-For 或者 X-Real-IP ）。很多网站目前都采用 nginx + Apache 的组合，这个模块可以使得转发对应用透明，应用按照普通方法即可获取到真实 IP ，不用修改代码来读取指定的 HTTP Header 。更优秀的是，这个模块对日志也是同样有用的—— access/error log 中记录的 IP 地址也会被修改为真实的 IP 。另外这个模块的自定义功能也很强大，可以任意指定使用哪一个 HTTP Header 字段、接受哪些前端转发 IP 等等。
然而正因为其强大，使得用户想当然地认为它在所有地方都有效，不曾想在 Apache 的访问控制（allow/deny 指令）中，该模块无效，访客 IP 仍旧是前端转发服务器的 IP ！这个行为没有在文档中明确说明。我因此差点弄出了一个严重的安全问题——为了监控服务器我开启了 server-status ，本想都允许网关服务器访问以便在一个地方统一收集数据，就写了类似 allow from gate 这样的东西，结果 server-status 就一下子“门户大开”，所有人都可以看到了（因为都是经过前端网关代理的）。这个“问题”对 mod_rpaf 而言没有解决方案（除非修改代码）。另一个类似功能的模块 mod_remoteip （Apache 2.4 自带，有 backport 到 2.2 的版本）可以使得 allow/deny 能够使用真实 IP 。