如何清除nginx的缓存?


250

我使用nginx作为前端服务器,我修改了CSS文件,但是nginx仍在使用旧文件。

我试图重新启动nginx,但没有成功,我已经用Google搜索,但是找不到清除它的有效方法。

有些文章说我们只能删除缓存目录:var/cache/nginx,但是我的服务器上没有这样的目录。

我现在应该怎么办?


1
有关Nginx配置的更多详细信息将有很大帮助。您在使用proxy_cache吗?
亚历山大·阿扎罗夫

不,我只是使用默认配置,我搜索了string cache,但未在配置文件中找到它
Freewind

5
Nginx默认不缓存。
亚历山大·阿扎罗夫

30
您是否在virtualbox / vargant虚拟机中运行?如果是这样,请尝试关闭sendfile,因为它们不能一起播放。
kolbyjack 2011年

5
您确定缓存位于nginx端吗?您是否已使用curl等工具验证了行为?通常,这样的问题只是客户端缓存不请求更新的资源,因为有人告诉您,旧资源在maximize max到期之前将长期有效。或类似的东西。
kolbyjack 2011年

Answers:


185

我遇到了完全相同的问题-我在Virtualbox中运行了Nginx。我没有打开缓存。但是看起来像是sendfile设置onnginx.conf,这就是造成问题的原因。@kolbyjack在上面的评论中提到了它。

当我关闭电源时sendfile-工作正常。

这是因为:

Sendfile用于“在一个文件描述符和另一个文件描述符之间复制数据”,当在虚拟机环境中运行或至少通过Virtualbox运行时,显然存在一些实际麻烦。在nginx中关闭此配置会导致通过其他方法提供静态文件,您的更改将立即得到体现,而不会出现任何问题

与此错误相关:https : //www.virtualbox.org/ticket/12597


7
请参考此链接
刘德华

就我而言,替代解决方法是为这些文件类型打开gzip。无论哪种方式都可以解决问题。
2014年

非常感谢您和kolbyjack的回答。救了我一命。
T1000 2015年

1
我使用了以下“ sudo vim /etc/nginx/nginx.conf”并将“ sendfile on”更改为“ sendfile off”
KorayGüclü15年

12
我关闭了sendfile。没运气。
marukobotto

109

您还可以使用逐个文件地绕过/重新缓存

proxy_cache_bypass $http_secret_header;

作为奖励,您可以返回此标头,以查看是否从缓存(将返回“ HIT”)或从内容服务器(将返回“ BYPASS”)获得它。

add_header X-Cache-Status $upstream_cache_status;

要使缓存文件过期/刷新,请使用curl或任何其他客户端向缓存页面发出请求。

curl http://abcdomain.com/mypage.html -s -I -H "secret-header:true"

这将返回该项目的新副本,并且还将替换缓存中的内容。


7
为什么我只能对此投票一次?我想做个专案:)
Spock 2015年

2
当新页面也可缓存时,这只能更新缓存的页面。如果您删除了一个页面(后端现在提供了404或其他错误),则该页面现在将发送Set-Cookie或“ Content-Control:private”标头,因此不会使“缓存的内容”无效。
rbu

3
此“ add_header X缓存状态$ upstream_cache_status;” 是一个很酷的功能!
Maxim Masiutin

1
非常感谢。关于缓存失效的一个很好的技巧,关于nginx的教程很少
Ivan Semochkin

4
自您发布以来,这已经改变了吗?我可以使用“ secret-header”成功获得一个新副本,但是一旦删除
该报

60

除非您通过proxy_cache_path配置了一个缓存区域,然后使用了它(例如在一个位置块中),否则通过: proxy_cache不会缓存任何内容。

但是,如果您这样做了,那么根据nginx的作者说,只需从缓存目录中删除所有文件就足够了。

最简单的方法: find /path/to/your/cache -type f -delete


删除文件后,我在错误日志中得到了此信息:[crit] 1640#0: unlink() "/path/to/cache/85/1cc5328db278b328f2c200c65179ad85" failed (2: No such file or directory)
Collin Anderson

重复一次还是一次?这不应该是一个实际的问题。这可能只是意味着缓存管理器试图删除您已经删除的文件。如果您反复收到消息,也许重新加载nginx(nginx -s reload)可能会有所帮助。(不确定是否
还会

1
是的,每当我部署更改时,我都会通过脚本自动清除网站的缓存,而重新加载nginx也无法解决该问题。
Collin Anderson

即使您不使用代理内容,Nop Nginx也会缓存某些内容,但这是Nginx + VirtualBox的错误。
Thomas Decaux

1
听起来很模糊。您能详细说明一下吗?似乎与这里的主题无关。
Gnarfoz

20

您可以删除Nginx的缓存目录,也可以搜索特定文件:

grep -lr 'http://mydomain.pl/css/myedited.css' /var/nginx/cache/*

并仅删除一个文件以Nginx刷新它们。


1
要获得准确的匹配,您可以在搜索词后附加$。喜欢grep -lr 'http://mydomain.pl/css/myedited.css$' /var/nginx/cache/*
张继峰2014年

1
不幸的是,我得到以下输出,grep: /var/nginx/cache/*: No such file or directory我正在使用Ubuntu 14.04.3 LTS和nginx / 1.8.1。任何想法?
b00r00x0

尝试以下操作在/ var / nginx / cache下的grep文件:sudo find /var/nginx/cache -type f -exec grep -l '/css/myedited.css' {} \;
jaybrau

我相信它是/ var / cache / nginx / *(路径中nginx之前的目录缓存)
Randy Lam

15

这个问题有两个答案。

  • 一个用于nginx作为反向缓存
  • 另一个用于通过标头输入清除浏览器缓存(此)

用:

expires modified +90d;

例如:

location ~* ^.+\.(css|js|jpg|gif|png|txt|ico|swf|xml)$ {
    access_log off;
    root /path/to/htdocs;
    expires modified +90d;
}

我尝试了这种实现方式,因为我遇到了类似的问题。但是,进行更改后-它显示默认的Nginx页面。我正在使用Niginx作为具有代理的LB,是否需要更改root?
亚伦

10

我发现这很有用

grep -lr 'jquery.js' /path/to/nginx/cache/folder/* | xargs rm

搜索,如果找到,则删除。


9

在我的nginx安装中,我发现必须去:

/opt/nginx/cache

sudo rm -rf *

在该目录中。如果您知道您的nginx安装路径,并且可以找到缓存目录,则同样可以使用。请小心使用该rm -rf命令,如果您在错误的目录中,则可以删除整个硬盘。


2
之后您需要重新启动NGINX
Eliel Haouzi

那是最糟糕的部分
kidz

9

我运行了一个非常简单的bash脚本,该脚本花了所有10秒钟来完成工作,并在完成后向我发送邮件。

#!/bin/bash
sudo service nginx stop
sudo rm -rf /var/cache/nginx/*
sudo service nginx start | mail -s "Nginx Purged" me@gmail.com
exit 0

8

我也有这个问题。

  • 找不到任何Nginx /缓存文件夹
  • sendfile已关闭

我的域使用cloudflare.com进行DNS(优质服务!)。啊哈!在那里:

cloudflare.com->缓存->清除缓存(我清除了所有内容),这解决了我的问题!


2
这将清除Cloudflare的边缘缓存。它不会清除您自己服务器上的Nginx缓存。
mahemoff

作为建议,我认为这是一个有效的答案。
费尔南多·科什

这是一个很好的答案。我在挖掘几个小时,为什么仍在缓存某些文件,却无法猜测这是CloudFlare的“故障”。谢谢!
undefinedman '18

6

我们有一个非常大的Nginx缓存(千兆字节),我们有时需要擦除它。我制定了一个脚本,该脚本可以立即清除缓存(就Nginx而言),然后删除缓存目录,而不会导致主应用程序出现磁盘I / O短缺的情况。

综上所述:

  1. 将缓存文件夹移动到新位置(在同一文件系统上!)(这不会破坏任何打开的文件描述符)
  2. 重新创建原始的缓存文件夹,为空
  3. 重新加载Nginx(正常重新加载,nginx允许老员工完成正在进行的请求)
  4. 删除旧的缓存数据

这是针对Ubuntu 16.04 LTS量身定制的脚本,缓存位于/mnt/nginx-cache

#!/bin/bash
set -e

TMPCACHE=`mktemp --directory --tmpdir=/mnt nginx-cache-XXXXXXXXXX`
TMPTEMP=`mktemp --directory --tmpdir=/mnt nginx-temp-XXXXXXXXXX`

# Move the old cache folders out of the way
mv /mnt/nginx-cache $TMPCACHE
mkdir -p /mnt/nginx-cache
chmod -R 775 /mnt/nginx-cache
chown www-data:www-data /mnt/nginx-cache

mv /mnt/nginx-temp $TMPTEMP
mkdir -p /mnt/nginx-temp
chmod -R 775 /mnt/nginx-temp
chown www-data:www-data /mnt/nginx-temp

# Tell Nginx about the new folders.
service nginx reload

# Create an empty folder.
rm -rf /mnt/empty
mkdir -p /mnt/empty

# Remove the old cache and old temp folders w/o thrashing the disk...
# See http://serverfault.com/questions/546177/how-to-keep-subtree-removal-rm-rf-from-starving-other-processes-for-disk-i
# Note: the `ionice` and `nice` may not actually do much, but why not?
ionice -c 3 nice -19 rsync -a --delete /mnt/empty/ $TMPCACHE
ionice -c 3 nice -19 rsync -a --delete /mnt/empty/ $TMPTEMP
rm -rf $TMPCACHE
rm -rf $TMPTEMP

rm -rf /mnt/empty

如果有帮助,请使用以下Nginx配置:

upstream myapp {
    server localhost:1337 fail_timeout=0;
}

proxy_cache_path /mnt/nginx-cache/app levels=2:2:2 keys_zone=app_cache:100m inactive=1y max_size=10g;
proxy_temp_path  /mnt/nginx-temp/app;

server {
    listen   4316 default;
    server_name  myapp.com;

    location / {
        proxy_pass http://appserv;
        proxy_cache app_cache;
        proxy_cache_valid 200 1y;
        proxy_cache_valid 404 1m;
    }
}

5

对于那些其他解决方案不起作用的用户,请检查您是否正在使用DNS服务,例如CloudFlare。在这种情况下,请激活“开发模式”或使用“清除缓存”工具。


5

请注意,如果您的应用未在触发该请求的特定请求中返回可缓存的响应,则proxy_cache_bypass可能会给您造成很大的伤害。

例如,如果您的应用程序在每个第一个请求中发送一个cookie,那么一个通过curl触发proxy_pass_bypass的脚本可能会在响应中获取该cookie,而nginx 不会使用该响应来刷新缓存的项目。


3
find /etc/nginx/cache_folder -type d -exec rm -rvf {} \;
mkdir /etc/nginx/cache_folder
service nginx restart

请注意正确指定正确的路径。


3

对于那些尝试删除nginx缓存文件的人,不管它没有起作用还是间歇性地起作用,请查看open_file_cache的设置。如果启用了此功能并将其配置为长时间缓存文件描述符,那么即使从磁盘删除文件,Nginx仍可能会看到缓存文件的版本。我不得不将open_file_cache_valid减少为1s(我不确定这是否与完全禁用文件缓存基本相同)。


2

在我的服务器上,nginx缓存文件夹位于 /data/nginx/cache/

所以我只删除了它: sudo rm -rf /data/nginx/cache/

希望这对任何人都有帮助。


2

如果要清除特定文件的缓存,则可以使用proxy_cache_bypass指令。这就是你的做法

location / {
    proxy_cache_bypass $cookie_nocache $arg_nocache;
    # ...
}

现在,如果要绕过缓存,则可以通过传递nocache参数来访问文件

http://www.example.com/app.css?nocache=true


1
我想这可能会用来攻击和消耗您网站上的带宽。
马塞洛·阿吉莫维尔(MarceloAgimóvel),

1
这不是app.css?nocache=true在原始文件(不带查询)保留在高速缓存(app.css)中的同时简单地绕过当前请求()的高速缓存吗?
adrianTNT

1

您可以像下面这样在nginx.conf中添加配置。

...
http {
proxy_cache_path  /tmp/nginx_cache levels=1:2 keys_zone=my-test-cache:8m max_size=5000m inactive=300m;

server {
    proxy_set_header X- Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $http_host;
    proxy_cache my-test-cache;
    proxy_cache_valid  200 302  1m;
    proxy_cache_valid  404      60m;
    proxy_cache_use_stale   error timeout invalid_header updating;
    proxy_redirect off;

    ....
}
...
}

从上面开始,在/ tmp /中动态创建一个名为“ nginx_cache”的文件夹以存储缓存的内容。


1

有一种正确的方法是只删除与任何KEY匹配的缓存文件。例如:

grep -lr 'KEY: yahoo' /var/lib/nginx/cache | xargs rm -rf

如果在nginx.conf中设置了,它将删除所有与KEY“ yahoo / *”匹配的缓存文件:

proxy_cache_key $host$uri;

1

我们使用nginx缓存很多东西。缓存目录中有成千上万的项目。为了找到并删除项目,我们开发了一些脚本来简化此过程。您可以在下面找到此脚本的存储库:

https://github.com/zafergurel/nginx-cache-cleaner

这个想法很简单。创建缓存的索引(带有缓存键和相应的缓存文件)并在该索引文件中搜索。它确实帮助我们加快了查找项目的速度(从几分钟到亚秒级)并相应地将其删除。


1

以我touch为例,该Css文件使它看起来像资源已更改(实际上touch除了更改上次修改时间外,实际上对该文件没有任何作用),因此浏览器和Nginx将应用最新资源


0

我遇到了类似的问题:

系统设置和问题:( 在virtualbox上,我正在使用ubuntu和nginx进行网络托管-PHP网页刷新没有反映对外部CSS文件的更改)。我正在Windows计算机上开发网站,并通过共享文件夹将文件传输到nginx。似乎Nginx不会对css文件进行更改(以任何方式刷新都无济于事。更改css文件名只是有效的方法)

解决方案: 在VM上找到共享文件(在我的情况下为CSS文件)。用nano打开,然后与Windows共享中的文件进行比较(它们看起来相同)。在VM上使用nano保存共享文件。现在,所有更改都将反映在浏览器中。不知道为什么这行得通,但就我而言确实如此。

更新:重新启动VM服务器后,问题返回。遵循解决方案下的说明,使CSS再次响应更新


-1

以我为例,它是/etc/php/7.2/fpm/php.ini(Ubuntu)中启用的opcache:

opcache.enable=1

将其设置为0将使服务器加载最新版本的(php)文件。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.