Doku wiki反向代理超级缓存方案

这是网站建好之后的事情了，之前的内容参见这里。

首先，需要新建一个缓存用的空间，找个IO快的地方新建个文件夹分配给www-data用户，然后在nginx.conf这里配置：

## cache
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=rev_proxy_cache:50m inactive=600m max_size=1g;

/var/cache/nginx是文件夹地址，rev_proxy_cache是这个缓存区的名字。

然后，在网站设置中增加启用缓存的选项：

  location / {
    
    ...
	
    proxy_buffering on;
    #proxy_buffer_size 4k;
    #proxy_buffers 8 10M;
    #proxy_busy_buffers_size 20M;
    #proxy_max_temp_file_size 0;
    proxy_cache rev_proxy_cache;
    proxy_cache_valid  200 302 304;
    proxy_cache_key $host$uri$is_args$args;

  }

这样搞一下之后，大部分东西就进缓存了（但偏偏核心页面内容——虽然文件不大——没有被缓存），可以通过在server部分加一行add_header X-Cache-Status $upstream_cache_status;，然后检查响应头中的X-Cache-Status字段来检查缓存生效情况。

对于服务器在家，靠公网中转的情况，一个比较好的缓存模式时：让公网尽量多的缓存东西，甚至在家里服务器挂掉时也能继续提供有限的服务。为此，可以添加这么几行：

  location / {
    
    ...
	
    proxy_buffering on;
    #proxy_buffer_size 4k;
    #proxy_buffers 8 10M;
    #proxy_busy_buffers_size 20M;
    #proxy_max_temp_file_size 0;
    proxy_cache rev_proxy_cache;
    proxy_cache_valid  200 302 304;
    proxy_cache_key $host$uri$is_args$args;

    proxy_cache_use_stale error timeout http_500 http_502 http_503 http_504;
    proxy_cache_background_update on;
  }

但是，上面几行依然没有解决全部问题，因为doku的核心页面在向外传输时，会被加上Cache-control: no-cache no-store的header，进而使得nginx不缓存这部分内容。从doku来看，这对于保持页面正确是必要的，但对于上述目标是个障碍。

此时，可以考虑再加一行很强力的命令：

    proxy_ignore_headers Expires Cache-Control Set-Cookie Vary;

意思是在决策缓存与否时不参考这几个header。实测效果惊人，但有一个很强的副作用：没法登陆了！因为登陆后页面跟登陆前页面地址是一样的，被缓存了嘛……

但是可以继续走偏门：如果域名控制权在你手里，可以另外新建一个子域名，把上述缓存很好的nginx配置文件复制一份，绑定到这个新域名上，然后删去其中有关强力缓存的部分（可以保留普通缓存）。这样你就有了一个不带缓存的版本，用于自己管理用。

注意：如果这样搞的话，有两个注意事项：

1. 一定要在开工之前把doku后台配置中的baseurl设置为空，让它自动检测，否则这个管理专用域名很容易在各种地方跳转去前台，甚至修改配置后都要手动改一下域名才能设置成功。
2. 如果做了SSL，一定要做http到https的自动跳转，以及在nginx中add_header Strict-Transport-Security，因为往往后台是不加密的，doku在没有baseurl时给出的是http开头的链接，比较影响体验。