WEB应用

Nginx通过二级目录(路径)映射不同的反向代理,规避IP+端口访问

这是我上一家公司的案例总结,发现躺在草稿箱好几个月了,今天得空就整理发布一下。 先说一下开发那边提来的2个case: ①、同一个域名需要反向代理到前台和后台(不同机器和端口); ②、需要采用IP+端口的模式,嵌入到APP作为DNS污染后的备选方案。 对于第①个问题,很好解决:通过区分二级目录来反代不同的节点即可,所以代码类似如下: 如上配置即可实现通过一个域名来反代不同的后端节点,用到的思路就是匹配二级目录来反代。 对于第②个问题,可能粗略一看,还没理解是个啥意思吧! 其实就是现在业界流行的一种防DNS污染的解决方案之一:手机APP里面除了通过域名来获取数据,还会额外嵌入一些备用的IP。APP在获取数据时,会先通过域名向服务器发起一个简单的校验请求,如果得到的不是预期数据,说明该网络环境下的DNS已被污染,比如被运营商劫持,请求A内容却给你展示B内容!这时候,APP将会启动备用预案,通过IP的方式来请求数据!很明显,这个做法可以有效避免恶心的DNS劫持了(看完这段是不是有所收获呢?)。 做法很简单,就是在APP中集成多个IP和端口作为备用的访问途径。 当开发GG找到我,提出的需求是: 需要实现公网IP+端口来访问,比如邮件API使用 http://192.168.1.10:125 Ps:公网服务器是多线的,那么就有多个IP,本文假设电信是192.168.1.10,联通是192.168.2.10,移动是192.168.3.10等 说白了就是要用端口来区分不同的API,此时如果我不深究,顺手可能会写出如下配置: 粗略一看,确实是可以实现开发GG的要求啊!再仔细一想,你会发现如此做法会开放越来越多的端口!运维成本以及辨识度低还只是其次,咱说好的安全第一呢? 经过思考和测试,我写出的最终配置如下: 最终实现的效果就是:你要通过IP请求邮件API,只要请求 http://192.168.1.1/mail_api/ 即可,而不需要开放多余端口。而且,后续要新增更多API,只需要定义不同的二级路径即可,这些二级路径的辨识度可比端口要好得多! Ps:正如代码中的注释,示例代码只用了一个 DemoBackend 节点配置,为的是分享另一个小技巧:当后端节点承载了多个站点而且都是监听80端口时(比如某些小公司同一个IIS服务器部署了N个站点),反向代理中的proxy_set_header参数,可以自定义传递一个host域名给后端节点,从而正确响应预期内容! 这段解释有点无力,还是拿实际例子举例吧! 我之前供职的公司节点用的是IIS服务器,前端用Nginx反向代理,IIS服务器上有多个站点,站点之间部分会通过 rewrite 规则联系起来。 打个比方:比如A网站有个专题内容(www.a.com/zt/)是通过IIS伪静态映射到了B网站(content.b.com)。也就是访问到http://www.a.com/zt/,其实最后是通过A网站映射到了B网站上面。 后来发现IIS有个伪静态BUG,会经常奔溃,就要我用前端的Nginx来实现直接映射,而不再走IIS的A网站中转。 那么这个需求就正好用到了 proxy_set_header 技巧,一看就懂: 很明显,通过传递自定义域名,就可以实现通过A网站访问Nginx,返回B网站内容,和反向代理谷歌的原理是一致的。 当然,上文为了实现 IP 和域名都可以访问,这个proxy_set_header 设置也是必须的。说白了就是在反代过程中,对后端服务器伪装(传递)了一个自定域名,让后端响应该域名预期内容。 当然,在之前张戈博客分享的《分享几个WordPress本地缓存gravatar评论头像的方案》一文中也用到了这个技巧,感兴趣的朋友可以前往查看。 本文分享的经验,其实比较简单,主要就是通过不同路径来反代不同的目标。估计很多大拿早就用烂了吧!不过值得注意的是,通过自定义路径反代,需要注意 proxy_pass 参数后面是否需要斜杠,避免将自定义的路径传递到后端节点,导致访问404!
阅读全文
WEB应用

Nginx开启fastcgi_cache缓存加速,支持html伪静态页面

张戈博客不久前分享过Nginx开启缓存为WordPress加速的教程,其中分享了2种缓存模式:代理模式和本地模式。我一直以为单个 ngx_cache_purge 缓存模块只支持proxy代理模式,结果热心的网友回复,其实这个模块也是支持本地缓存的,而且WordPress还有配套的插件! 看来还是我孤陋寡闻了! 我像发现了新大陆一般,立马进入折腾状态,幸不辱命,已经成功部署!最爽的是可以通过插件来自动清理文章的对应缓存,解决了前文清理缓存的历史遗留问题。 一、添加模块 本文分享的 Nginx 缓存需要额外编译 ngx_cache_purge 模块。至于下载模块、重新编译以及平滑升级前文已经分享过了,本文就不再赘述了。不会的朋友可以参考前文: 为网站开启Nginx缓存加速,支持html伪静态页面 Ps:需要重新编译Nginx,在原有的编译参数上新增一个 ngx_cache_purge 模块,比如: --add-module=../ngx_cache_purge-2.3 不清楚怎么重新编译和平滑升级的的请参考前文进行操作。 二、Nginx配置 要用这个缓存功能,建议重新弄一个 server 模块(替换之前的),如下代码是张戈博客目前正在使用的规则(已删除了我自定义的伪静态规则,避免混淆视听): 请仔细阅读代码中的所有注释,该修改的修改,该创建的创建,该补充的根据实际情况补充,否则使用之后又来找张戈吐槽各种问题了! 三、安装插件 上文已经提到了 fastcgi_cache 有一个量身定做的WordPress缓存清理插件:Nginx Helper 所以,接下来我们就去安装这个插件 。非常简单,直接进入WordPress后台插件安装界面搜索 Nginx Helper 关键词在线安装即可。 安装后,从后台【工具】==>【Nginx Helper】打开插件设置界面如下所示: Ps:顺带说一下后面2项的含义: 记录插件日志:勾选这个选项后,插件设置下面会显示日志记录存放路径。这个功能主要用来测试插件的设置,比如去已缓存的文字发表一个新的评论,然后看下日志里面是否出现删除记录。 插入缓存信息:勾选这个选项后,前台页面的源代码底部将插入页面的缓存信息,类似如下: 勾上第启用缓存清理后,将出现如下选项: 该怎么设置,应该看图就懂了吧?否则张戈苦逼的用中文标注了半天就白费功夫了! 清理模式选择 上图我也标注的比较清楚了,还是详细解释一下吧! ①、purge模式 这个模式需要保留上文 Nginx 配置中的 purge 清理路径,清理的时候会产生一个请求。 出于安全考虑,一般 purge 都不会完全开放!只有特定的 IP 可以访问,所以,如果用了CDN的朋友,再使用模式一,则需要在服务器上的 /etc/hosts 中将网站域名解析为服务器真实IP,以便插件直接请求purge路径,而不用走CDN节点,避免请求被拒绝。还是没搞懂的话就放弃这个模式吧! ②、文件模式 模式二是直接清理对应的缓存文件,不需要请求 purge这个清理路径,所以使用模式二,不需要配置上文 Nginx 的 purge 规则(我个人推荐使用这个模式)。 由于插件作者定义的缓存路径是 /var/run/nginx-cache ,而我们可能会根据服务器实际情况来自定义缓存路径,这样一来,缓存路径的不同就会导致插件无法找到缓存文件并删除! 解决办法: 很简单,在WordPress根目录下的wp-config.php中新增如下代码即可: Ps:不知道添加到第几行的话,可以添加到 define('WPLANG', 'zh_CN'); 的后面即可。添加后建议重载一下php,确保变量生效(主要针对开启了PHP缓存的网站)。 三、效果预览 ①、缓存效果 替换新的配置,并且重载Nginx之后,访问前台页面,查看header,会多出一个X-Cache 标志。 X-Cache 一般会有3个状态:MISS、HIT、BYPASS。 MISS表示未命中 即这个页面还没被缓存,新发布或刚被删除的页面,首次访问将出现这个状态(图略)。 HIT表示缓存命中 打开一个会缓存的页面,比如文章内容html页面,F5刷新几次即可在F12开发者模式当中的Header头部信息中看到如图缓存命中状态: BYPASS表示缓存黑名单 即页面路径在Nginx规则中被设置成不缓存(set $skip_cache 1;),比如WP后台,查看header: 如果你发现想要缓存的页面却是这个状态,就可以去检查排除规则中是不是包含了这个路径!反之,如果你发现后台登录不了,或者各种登陆态丢失问题,则应该到排除规则中加上该页面路径的关键字。 ②、清理效果 这个插件和缓存的搭配非常好用,不管我们是发布文章,还是有人发表评论,插件都能根据我们的设置来清理对应的缓存!比如有人发表了一个自动审核通过的评论(或博主审核通过一条评论),插件将会自动删除评论相关的文章缓存,具体看下上图张戈贴出的标注即可。 如何查看插件是否正常工作呢?很简单,勾选开启插件日志,然后去点击更新一篇旧文章,最后打开插件日志即可看到是否删除记录。 用Linux的朋友,可以直接使用tailf命令查看该日志,然后去更新文章即可看到效果,如下图所示: 至于要证实是否真的删除了缓存,我们可以先打开浏览器的开发者模式,定位到network界面,然后访问刚刚更新的文章,即可看到如下状态: 很明显,缓存已被成功删除,首页看都不用看,肯定也是这个状态了。 好了,本文就分享到这,如果对网站缓存感兴趣的朋友,可以继续翻看张戈博客的相关文章: WordPress结合阿里云OCS开启高速缓存,优化网站响应速度 WordPress评论ajax动态加载,解决静态缓存下评论不更新问题 php平滑重启nginx,彻底清除WordPress的静态缓存 WP Super Cache静态缓存插件纯代码版(兼容多域名网站) 解决启用wp super cache缓存后,页面追加多个斜杠仍然可以访问的隐患 Ps:当然,东西肯定是越用越好,目前张戈博客也取消了以前的各种缓存,比如php代码缓存等。 最后感谢一下在我博客留言告知的【wordpress优化】站长!总之一句话,如果发现新的WordPress折腾目标,你不会折腾的话,可以留言告诉张戈。
阅读全文
WEB应用

为网站开启Nginx缓存加速,支持html伪静态页面

上一篇文章分享了如何开启 Nginx 的缩略图功能,也提到了 Nginx 缩略图在完美替代七牛缩略图或PHP缩略图的同时,还会带来一定的CPU负载消耗。 因此,本文就来分享一下如何解决这个实时生成缩略图带来的CPU开销问题。 思路很简单,既然你要实时生成,那我就将你生成的缩略图缓存一份好了!在我测试期间发现,Nginx 的缓存也同样可以缓存伪静态的 html 页面,完全可以替代WP-Super-Cache这类缓存插件了。相信大部分CDN也是用的这个原理,比如百度云加速,我们可以在 header 里面发现一个 “Server:yunjiasu-nginx”的标识。 好了,废话不说,一起来看看如何实现吧! 一、代理模式 代理模式,即在使用 Nginx 反向代理时缓存指定内容,所用模块为 proxy_cache。这里网络上的很多教程会说,这个模式必须在反向代理中才能使用,说的好像不能用在只有一台服务器的情况似的。其实不然,我们用点小技巧,将 Nginx 本机的80端口代理转发到 本机的 8080 端口即可变相的开启反向代理模式,在这期间,就完全可以指定缓存内容了,且继续往下看! ①、下载模块 所用模块为 ngx_cache_purge,官方地址:http://labs.frickle.com/files/,我们可以挑选一个新版本下载到服务器上,比如 http://labs.frickle.com/files/ngx_cache_purge-2.3.tar.gz ②、重新编译 所以先执行 -V 命令查看 Nginx 是否已经编译了该模块, 如果编译参数中找不到 ngx_cache_purge,就需要重新编译 Nginx ,新增编译参数: 我现在用的是淘宝开放的 Tengine ,可以使用动态加载模块功能,如果是原版 Nginx ,可以参考张戈博客之前分享的文章,在原来的基础上加上上述参数重新编译 Nginx 即可: Nginx在线服务状态下平滑升级或新增模块的详细操作记录 ③、新增配置 A. 在 http 上下文中新增缓存配置: Ps:上述配置中出现的目录,请在保存配置后,使用 mkdir 手动创建。 B. 如下修改网站原来的server 模块: B. 如下新增一个反向代理Server模块,用于转发请求到本地8080,变相实现反向代理模式: 全部保存后,执行 nginx -s reload 让配置生效即可。现在你再去访问网站的 html 页面,刷新一次就可以看到效果了!加载速度绝逼会有质的飞跃!而且你可以在F12开发模式的 Network 状态中看到 Nginx-Cache HIT 的标识! ④、清理缓存 清理缓存就有点麻烦了,我弄了多次也还是感觉不怎么好用!网上也有不少先驱分享了自动清理脚本或批量清理代码等。不过用了下也是不咋的好用。 还是说一下清理方法吧!在A部分的配置中,我们已经加入了purge缓存清理页面,假设一个URL为http://192.168.1.1/test.html,通过访问http://192.168.1.1/purge/test.html 就可以清除该URL的缓存(我实际测试经常是404...)。 二、本地模式 第一种代理模式,我们是利用本地转发变相实现反向代理下的 Nginx 缓存功能,并且可以缓存 html 伪静态页面。从整体的配置可以看出,已经非常接近百度云加速等CDN的缓存功能了!对于理解CDN缓存还是有不小的帮助的! 现在分享一下,如果不用反向代理模式,该如何实现 Nginx 缓存呢?很简单,进一步借助 ngx_slowfs_cache 模块即可,这也是张戈博客在用模式,如何实现,且继续往下看。 ①、下载模块 这个模式需要下载2个缓存模块:ngx_cache_purge 和 ngx_slowfs_cache 。这2个模块都出自一个网站,下载地址依然是 http://labs.frickle.com/files/ ,挑选一个最新版下载即可,比如: http://labs.frickle.com/files/ngx_slowfs_cache-1.9.tar.gz ②、重新编译 和第一种模式一样,新增2个 --add-module 重新编译 Nginx即可: 具体就不赘述了,参考上文和博客之前的分享就可以搞定了。 ③、新增配置 I. 在 http 上下文新增如下配置: Ps:以上配置中所涉及的目录请手动创建。...
阅读全文
WEB应用

为WordPress开启Nginx缩略图功能,七牛从此陌路

张戈博客曾分享过不少关于七牛云存储的一些经验技巧,对七牛感兴趣或者遇到相关问题的朋友可以看一看以前的相关文章: 七牛&又拍云CDN云存储节省GET次数的小技巧 WordPress简单代码开启七牛CDN及集成七牛缩略图的方法 浅谈网站使用七牛云存储之后的robots.txt该如何设置? Linux/vps本地七天循环备份和七牛远程备份脚本 前段时间,百度云加速自动切换到了3.0,导致我之前的一些规则出现了异常,而且在七牛cname记录上再套云加速缓存这种做法也有部分掉了链子,打开出现90x报错,只好暂时关闭云加速缓存七牛机制,结果七牛d 的数据统计就成这样了: 看来,需要采取措施才能继续享受免费服务了。本想使用之前博友建议的做法:只对需要缩略图的图片指向七牛,其他大图用源站链接,这样应该可以节省不少流量。 于是,对主题代码进行改造,只对缩略图进行七牛地址替换,其他使用源站地址,结果分享效果也不是非常明显,大概能省三分之一到一半的请求流量,但是依然做不到完全免费。 这几天公司组织外出拓展训练,我在和一个开发同事(国添)聊到了nginx时,得知Nginx还有个缩略图功能!运维不怕不会就怕孤陋寡闻,你都不知道有这么回事,也就不存在会不会了,所以不管是做运维,还是做开发,开拓的技术视野是非常重要的,不求深刻记忆,但求方向清晰。 昨天一回到家,立马进入折腾状态,学习Nginx的缩略图和缓存功能,几经折腾终于将这2个实用的功能应用到了我这个WordPress博客,博客图片从此和七牛陌路。 Ps:分享前先简单的说一说实时生成缩略图的好处。肯定有朋友会疑问,WordPress不是已经有缩略图裁剪功能了吗?而且很多主题也加入了自定义尺寸的缩略图裁剪功能,为什么还要多此一举呢?其实,用实时生成缩略图至少有如下2个好处: ①、免去上传图片被裁剪成多种尺寸的困扰(强迫症),既节省了空间且不会杂乱; ②、使用灵活,不管以后换什么主题,需要什么图片尺寸我都能随时拿出最佳尺寸。 下面开始分享具体做法。 一、模块简介 Nginx 缩略图需要用到 image_filter 模块,先贴一些基本参数,备忘之。 image_filter:有如下2种模式: ①、resize:根据尺寸比例缩放图片,比如100*100的图片,而设置是50*25,减小后的图片为25*25。如果你只想设置一个维度,可以用“-”代替。出错时返回415 ②、crop:完全根据尺寸裁剪图片,直接裁剪成跟设置一样大小的图片。比如100*100的图片,而设置是50*25,减小后的图片为50*50,Nginx会选取中间高度25的像素,形成50*25的图片,所以图片会有缺失。如果你只想设置一个维度,可以用“-”代替。出错时返回415 image_filter_buffer:设置图片最大尺寸,超过设定值会返回错误页面 image_filter_jpeg_quality:设置jpeg图片的压缩质量比例 image_filter_transparency:用来禁用gif和palette-based的png图片的透明度,以此来提高图片质量 二、重新编译 因为需要用到 Nginx 的缩略图模块,所以先执行 -V 命令查看 Nginx 是否已经编译了该模块, 如果编译参数中找不到 http_image_filter_module,就需要重新编译 Nginx ,新增编译参数: 我现在用的是淘宝开放的 Tengine ,可以使用动态加载模块功能,如果是原版 Nginx ,可以参考张戈博客之前分享的文章,在原来的基础上加上上述参数重新编译 Nginx 即可: Nginx在线服务状态下平滑升级或新增模块的详细操作记录 三、修改配置 URL形式①:https://zhang.ge/yuantu-${mod}300x300.jpg Ps:${mod}表示缩略图裁剪模式,即resize或crop。 在站点的 Server 模块中新增如下 location 规则: 保存后,执行如下命令行重载 Nginx: 现在可以访问博客图片查看效果了,举例地址形式如下: //res.zgboke.com/wp-content/uploads/2015/05/qiniucdn1.png //res.zgboke.com/wp-content/uploads/2015/05/qiniucdn1-resize400x400.png //res.zgboke.com/wp-content/uploads/2015/05/qiniucdn1-crop400x400.png 很明显的看出resize和crop的区别了吧?和七牛的2中缩略模式一摸一样,下文会有说明。 另外,带尺寸的图片地址其实是不存在的,而是 Nginx 实时生成的,我们可以通过浏览器F12开发模式,在 network 界面查看 header信息就可以看到我们插入的标识: Ps:本来想模仿七牛的缩略图访问方式,在图片后面加上 ?w=300&h=300 请求参数来指定缩略图尺寸,可惜折腾了半天,问题总是在原图和缩略图之间徘徊,只得暂时放弃了。   URL形式①:https://zhang.ge/yuantu.jpg?w=300&h=300 这种形式是我昨天就想弄的,结果折腾半天没成功就暂时洗洗睡了,结果睡觉突然有了灵感,所以一大早就抽空搞定了,下面继续分享: 在站点的 Server 模块中新增如下 location 规则: 保存后,同样是执行命令行重载 Nginx,然后访问图片查看效果,比如分别访问如下2个地址: //res.zgboke.com/wp-content/uploads/2015/05/qiniucdn1.png //res.zgboke.com/wp-content/uploads/2015/05/qiniucdn1.png?width=480 //res.zgboke.com/wp-content/uploads/2015/05/qiniucdn1.png?width=480&height=480 可以发现和七牛一样,只要带上高宽参数就能生成想要的缩略图了,是不是很给力呢? Ps:URL形式①和URL形式②可以同时配置到Nginx当中,不过形式②无法通过传递参数来决定resize还是crop模式,因为我测试发现 image_filter 无法将$1参数(即resize或crop)设置为变量! 不过最近发现使用URL形式①,然后再开启云加速,所有缩略图都会415报错!! 所以,对于URL形式的选择,我个人建议是: A. 如果不用云加速,请使用形式①,因为用参数的缩略图不知道会不会搞晕搜索引擎蜘蛛呢; B. 如果使用云加速,请使用形式②,避免大量415错误! 四、修改代码 既然 Nginx 已经准备就绪了,现在我们要做的就是修改博客的缩略图代码了,这里需要有一定的php折腾基础。因为之前的七牛缩略图就是我自己写代码实现的,所以我很轻松的完成修改,下面贴一下简单代码,仅供参考: 适用于URL形式①: 适用于URL形式②: 当然,这只是文章缩略图,其他位置的缩略图就需要修改主题代码了,由于每个主题都不一样,所以本文就不赘述了,相信这对懂得折腾的人来说应该是小菜一碟了。 五、拓展延伸...
阅读全文
WEB应用

Nginx发布1.9.0版本,新增支持TCP代理和负载均衡的stream模块

昨天在公司微信群,CTO分享了这个消息,对运维来说以后基于TCP协议的后端业务的高可用又多了一个新的选择,实在是棒极了! 一直以来,Nginx 并不支持tcp协议,所以后台的一些基于TCP的业务就只能通过其他高可用负载软件来完成了,比如Haproxy。 这算是一个nginx比较明显的缺憾。不过,在1.90发布后这个认知将得到改写: 2015-04-28 nginx-1.9.0 mainline version has been released, with the stream module for generic TCP proxying and load balancing. nginx-1.9.0 已发布,该版本增加了 stream 模块用于一般的 TCP 代理和负载均衡。 The ngx_stream_core_module module is available since version 1.9.0. This module is not built by default, it should be enabled with the --with-stream configuration parameter. ngx_stream_core_module 这个模块在1.90版本后将被启用。但是并不会默认安装,需要在编译时通过指定 --with-stream 参数来激活这个模块。 其他改进包括: Change: 删除过时的 aio 和 rtsig 事件处理方法 Feature: 可在 upstream 块中使用 "zone" 指令 Feature: 流模块,支持 TCP 代理和负载均衡 Feature: ngx_http_memcached_module 支持字节范围 Feature: Windows 版本支持使用共享内存,带随机化地址空间布局. Feature: "error_log" 指令可在 mail 和 server 级别 Bugfix: the "proxy_protocol" parameter of the "listen" directive did not work if not specified in the...
阅读全文
WEB应用

Apache/Nginx伪静态规则匹配http://出现的问题与解决

这个问题不知道有没有人遇到过,反正度娘和谷姐都没能帮到我!困扰了我挺长时间了,今天偶尔将代码放到Apache服务器下测试时,意外解决了! 问题是这样的,我搭建了一个网站icon图标抓取的API接口,正常情况下对象的传参是通过$_GET获取的,因此常规获取图标的地址应该是: http://domain.com/?url=zhang.ge 或 http://domain.com/?url=https://zhang.ge 为了开启浏览器缓存和后续的CDN缓存,我的设计思路如下: ①、在图标API网站目录下新建一个cache文件夹,以域名.ico的形式保存图标文件,比如zhang.ge.ico ②、当抓取某个网站的ico时,先通过Nginx或Apache判断是否存在缓存文件,如果存在就直接返回给浏览器,这样在没开启CDN的情况下,因为返回的是纯静态文件,浏览器将会自动缓存,也就是返回304状态,加载速度得到提升! 为了开启浏览器缓存,我将地址如下伪静态化: http://domain.com/zhang.ge 或 http://domain.com/https://zhang.ge 这是之前写的Nginx下的伪静态规则: 当时发现不能生效!怎么都匹配不到http://,最后无奈只好用php重写参数中http://了! 今天,我将这个图标API搬家到了万网的免费主机上,是Apache环境,于是按照nginx的规则又写了一遍: 依然不行!奇了怪了,怎么就不能匹配http://呢?于是各种测试,比如将冒号和斜杠缓存url编码都不行! 其实在用nginx失败之后,我用php获取$_GET发现得到的参数中的http://会是http:/,少一个斜杠!而且直接使用http://domain.com/?url=https://zhang.ge获取也是http:/zhang.ge,少一个斜杠! 今天鬼使神差的试了下伪静态中判断http:/,结果成功了!我擦原来要匹配http://,实际上是匹配http:/,少一个斜杠!真实匪夷所思,以前从来没遇到过! 所以上述2个伪静态规则应该如下编写: A. Nginx伪静态:  B. Apache伪静态: 文章写的很啰嗦,实际上关键性解释就是,在Nginx或Apache中要匹配请求url中的【http://】,应该是匹配【http:/】,也就是少写一个斜杠!大胆猜测匹配其他多个斜杠也应该是少一个斜杠。。。 好了,文章洋洋洒洒写了这么多,网站图标API也是成功搭建在万网免费虚拟主机上了。地址是http://seo.zgboke.com/geticon/ ,虽然是专门给中国博客联盟用的,但是如果你有图标调用需求,也可以在合理使用的前提下自由发挥。 另外,要查看是否实现浏览器缓存很简单,随便访问一个ico地址,比如: http://seo.zgboke.com/geticon/zhang.ge 然后按下F12进入开发模式,定位到network(网络选项卡),多刷新一次就能看到304状态了: 304表示当前文件来自浏览器缓存,因为请求的文件和服务段的文件一致,不需要重复调取! 当然,本文写到的伪静态规则只是一部分,如果要实现CDN加速,那还得新增相应的规则,不过这都是后话了,等下次我在张戈博客分享这个网站图标抓取API源码的时候,会一并贴上,敬请期待!
阅读全文