發(fā)現(xiàn)的問題對(duì)象存儲(chǔ)簡稱COS，數(shù)據(jù)萬象簡稱CI。由于5月數(shù)據(jù)萬象突然征收“CDN回源流量費(fèi)”，由于先森圖片請(qǐng)求量不大，且還是需要使用數(shù)據(jù)萬象的圖片處理功能，所以先森在CDN->COS的中間加了一個(gè)Nginx做反向代理，由于Nginx所在的服務(wù)器和先森的COS存儲(chǔ)桶是同地域的，所以服務(wù)器到COS的流量是內(nèi)網(wǎng)，因此講道理COS和CI都不會(huì)產(chǎn)生CDN回源流量了。但是，先森過了幾天又來看數(shù)據(jù)萬象控制臺(tái)，發(fā)現(xiàn)每天還是有產(chǎn)生CDN回源流量，先森這波就無語了，明明都沒用CDN了，怎么還會(huì)有CDN回源流量呢，這不是無中生有么。數(shù)據(jù)萬象控制臺(tái)問題原因定位經(jīng)過排查確認(rèn)，是由于先森的Nginx直接透傳了CDN的回源請(qǐng)求，導(dǎo)致COS和CI判定流量是來自CDN回源。。。先森在服務(wù)器上進(jìn)行抓包確認(rèn)。同一個(gè)圖片，CDN回源到CVM服務(wù)器：抓包：CDN回源到CVM服務(wù)器CVM回源到COS：抓包：CVM回源到COS可以看到，CDN回源到CVM比較有特殊性的請(qǐng)求頭是以下兩個(gè)，在CVM請(qǐng)求到COS時(shí)也是帶著的： X-NWS-LOG-UUID: 630013543448005765 X-Tencent-Ua: Qcloud那么，就要想辦法把這兩個(gè)請(qǐng)求頭去掉，不讓其透傳。去除Nginx請(qǐng)求頭先森百度了一下，Nginx內(nèi)置的模塊中沒有刪除指定請(qǐng)求頭的，只能編譯增加headers-more-nginx-module模塊。先森圖省事，服務(wù)器安裝了寶塔，Nginx是通過寶塔安裝的。看了一下，寶塔安裝的Nginx不像Redis等軟件，可以在網(wǎng)頁上動(dòng)態(tài)添加支持模塊，只能命令行編譯添加模塊。當(dāng)然編譯之前需要看一下寶塔的Nginx會(huì)不會(huì)已經(jīng)很好心的幫忙編譯了headers-more-nginx-module。查看Nginx已經(jīng)安裝的模塊 ./sbin/nginx -V nginx version: nginx/1.22.0 built by gcc 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC)  built with OpenSSL 1.1.1o  3 May 2022 TLS SNI support enabled configure arguments: --user=www --group=www --prefix=/www/server/nginx --add-module=/www/server/nginx/src/ngx_devel_kit --add-module=/www/server/nginx/src/lua_nginx_module --add-module=/www/server/nginx/src/ngx_cache_purge --add-module=/www/server/nginx/src/nginx-sticky-module --with-openssl=/www/server/nginx/src/openssl --with-pcre=pcre-8.43 --with-http_v2_module --with-stream --with-stream_ssl_module --with-stream_ssl_preread_module --with-http_stub_status_module --with-http_ssl_module --with-http_image_filter_module --with-http_gzip_static_module --with-http_gunzip_module --with-ipv6 --with-http_sub_module --with-http_flv_module --with-http_addition_module --with-http_realip_module --with-http_mp4_module --with-ld-opt=-Wl,-E --with-cc-opt=-Wno-error --with-ld-opt=-ljemalloc --with-http_dav_module --add-module=/www/server/nginx/src/nginx-dav-ext-module肉眼可見的，并沒有headers-more-nginx-module模塊，只能重新編譯一下了。由于寶塔編譯的Nginx沒有留configure文件，所以先森參考這篇文章：寶塔面板安裝的Nginx（已安裝）如何添加echo-nginx-module模塊，操作了一下編譯。其中，有一些點(diǎn)需要注意一下。1、模塊的下載地址，下載后解壓得到的目錄，就是編譯時(shí)指定的目錄： wget https://github.com/openresty/headers-more-nginx-module/archive/refs/tags/v0.33.tar.gz tar -zxvf v0.33.tar.gz -C /www/server/module/ ls /www/server/module/headers-more-nginx-module-0.332、下載的模塊目錄不要放在/www/server/nginx目錄下，使用先森參考的這個(gè)方法寶塔在更新Nginx時(shí)會(huì)清空該目錄；修改反向代理配置文件進(jìn)入寶塔的網(wǎng)站配置頁，找到反向代理的配置文件，增加想要去除的請(qǐng)求頭即可。 more_clear_input_headers "X-Tencent-Ua"; more_clear_input_headers "X-NWS-LOG-UUID";修改反向代理配置重新抓包確認(rèn)請(qǐng)求頭沒有透傳修改好了之后，重新抓個(gè)包，看看請(qǐng)求頭還有沒有透傳。CDN回源到CVM服務(wù)器，可以看到這兩個(gè)請(qǐng)求頭還是在的（肯定在，先森又沒刪）。CDN回源到CVM然后再看CVM服務(wù)器訪問COS的請(qǐng)求頭，指定清除的兩個(gè)請(qǐng)求頭已經(jīng)沒有了。先森只是剛改好，由于數(shù)據(jù)萬象的控制臺(tái)對(duì)于“CDN回源流量”的監(jiān)控粒度是1天，所以起碼要明天才能看到效果，希望有效。

存在的問題在這六一兒童節(jié)的歡樂佳節(jié)，騰訊云又給先森送了一波小禮，上一次還是先森畢業(yè)的時(shí)候，騰訊云恭喜先森畢業(yè)，并收走了先森1元購買服務(wù)器的資格。。。大清早的，騰訊云郵件、短信通知先森騰訊云賬號(hào)欠費(fèi)停服了，先森表示一臉懵逼。登錄騰訊云費(fèi)用中心，發(fā)現(xiàn)是數(shù)據(jù)萬象產(chǎn)生了CDN回源流量，這更是讓先森感到懵逼。騰訊云賬號(hào)欠費(fèi)明細(xì)先森自2020年就將對(duì)象存儲(chǔ)從七牛轉(zhuǎn)到騰訊云COS了，在此之間從未發(fā)生過費(fèi)用，之前先森還炫耀過：網(wǎng)站http轉(zhuǎn)為https之始，從七牛到騰訊云突然產(chǎn)生的CDN回源流量讓先森真的很奇怪，再次確認(rèn)，COS是有CDN回源流量包的，先森的CDN源站也是COS域名而非數(shù)據(jù)萬象的域名。COS的CDN回源流量包問題原因先森聯(lián)系售后在線支持，經(jīng)過確認(rèn)得知，只要CDN回源時(shí)帶了圖片處理參數(shù)，那么就算是CDN回源到數(shù)據(jù)萬象，啊這。。。先森就很無語售后的答復(fù)先森的解決辦法數(shù)據(jù)萬象產(chǎn)品的策略已經(jīng)這樣了，先森也沒有辦法改變，先森去聯(lián)系售后，也不是為那6分錢討回公道的，及時(shí)止損才是王道。針對(duì)這種情況，先森想到了兩個(gè)解決方案：1、CDN繼續(xù)使用騰訊云的，源站改為七牛對(duì)象存儲(chǔ)或CDN域名；2、使用同地域的服務(wù)器做一個(gè)反向代理，CDN源站改為這個(gè)服務(wù)器，服務(wù)器通過內(nèi)網(wǎng)訪問對(duì)象存儲(chǔ)，這樣就不會(huì)產(chǎn)生對(duì)象存儲(chǔ)和數(shù)據(jù)萬象的流量費(fèi)用，也就不存在CDN回源流量費(fèi)了。先森選擇了第二種方案，第一種方案可以用來做CDN的備用源站，避免自建反向代理掛了的話導(dǎo)致網(wǎng)站訪問受到影響。第二種方案配置起來也簡單，寶塔上增加一個(gè)站點(diǎn)，設(shè)置反向代理，目標(biāo)URL和發(fā)送域名都填上COS的域名即可：寶塔的反向代理配置注意事項(xiàng)需要注意的是，使用的CVM服務(wù)器一定要與COS所屬地域一致，且CVM的dns服務(wù)器保持騰訊云默認(rèn)DNS，否則不會(huì)解析到內(nèi)網(wǎng)。配置反向代理前，可以在服務(wù)器內(nèi)解析驗(yàn)證一下，解析出來應(yīng)該是一個(gè)169.254.x.x的IP：dig確認(rèn)內(nèi)網(wǎng)解析不打算再使用騰訊云數(shù)據(jù)萬象的圖片處理功能？那么，如果希望繼續(xù)使用對(duì)象存儲(chǔ)COS，但是又不希望無意間使用到數(shù)據(jù)萬象該怎么辦呢？經(jīng)過確認(rèn)，可以在數(shù)據(jù)萬象的控制臺(tái)操作對(duì)應(yīng)存儲(chǔ)桶“解綁”，解綁后COS桶就無法調(diào)用數(shù)據(jù)萬象的能力了。數(shù)據(jù)萬象解綁COS桶

現(xiàn)在工作、生活需要關(guān)注的事情越來越多了，對(duì)博客的關(guān)注度是越來越少了，上一次發(fā)文章已經(jīng)是去年的事情了。前段時(shí)間服務(wù)器被人通過寶塔漏洞登錄成功，騰訊云告警了，先森知道被人攻破的服務(wù)器，不重裝的話是很難清理干凈的，所以簡單備份了一下相關(guān)數(shù)據(jù)就重裝了，結(jié)果還出了點(diǎn)小問題，一個(gè)月都沒發(fā)現(xiàn)。在重裝的一個(gè)多月后，先森上自己博客查點(diǎn)資料，結(jié)果發(fā)現(xiàn)網(wǎng)站打開不了，看報(bào)錯(cuò)是網(wǎng)站將您重定向的次數(shù)過多。網(wǎng)站將您重定向的次數(shù)過多（為了演示，先森臨時(shí)開了一個(gè)測試網(wǎng)站test.capjsj.cn）問題原因作為一枚資深騰訊云售后工程師，這個(gè)小問題當(dāng)然是看一眼就知道原因了。去年，先森將網(wǎng)站從http轉(zhuǎn)為了https訪問，先森前端使用的CDN，網(wǎng)站如果從http訪問，肯定得跳轉(zhuǎn)到https的，但是這個(gè)問題不是CDN跳轉(zhuǎn)的問題。先森當(dāng)時(shí)配置的回源方式是http回源，然后網(wǎng)站在寶塔中配置的是http訪問，這沒問題，但問題就出在重裝服務(wù)器之后，先森將寶塔中網(wǎng)站也配置成https訪問了，還手賤的開啟了強(qiáng)制https訪問：寶塔配置強(qiáng)制HTTPS客戶端訪問CDN域名，使用HTTPS進(jìn)行訪問，然后CDN使用HTTP進(jìn)行回源，然后源站開啟了強(qiáng)制訪問HTTPS，源站會(huì)返回CDN一個(gè)301跳轉(zhuǎn)到https的請(qǐng)求，然后客戶端又開始https訪問，不停的拿到301請(qǐng)求，導(dǎo)致死循環(huán)。解決辦法這問題解決起來也非常簡單，有兩種方法。第一種是把寶塔里的強(qiáng)制HTTPS關(guān)掉，第二種是在CDN的回源配置中，配置為HTTPS回源或者協(xié)議跟隨。修改CDN回源協(xié)議    總結(jié)這個(gè)問題相當(dāng)簡單，但是在我的騰訊云運(yùn)維生涯中，還是有很多客戶遇到反饋過。先森服務(wù)器是重裝的，由于舍不得錢沒有做快照，如果各位有預(yù)算的話，服務(wù)器建議還是定時(shí)做下快照。有快照的話，先森就不用手動(dòng)再去做各種配置了。

本著安全的考慮，先森在騰訊云的CDN配置里開啟了防盜鏈的配置，結(jié)果先森發(fā)現(xiàn)這里面有個(gè)小坑，竟然禁止了搜索引擎。發(fā)現(xiàn)與排查先森最近有開始關(guān)注起來網(wǎng)站了，之前先森對(duì)網(wǎng)站是一個(gè)活著即可的態(tài)度的，所以CDN的緩存時(shí)間配置的比較長，先森想著緩存命中率應(yīng)該很高才對(duì)，結(jié)果實(shí)際上很低，所以先森開始尋找命中率低的原因。命中率低可能的原因首先，先了解一下可能是哪些原因?qū)е旅新实汀Ｏ壬戳艘幌律厦娴脑颍畲蟮目赡芫褪菭顟B(tài)碼4XX和5XX的情況了。通過CDN控制臺(tái)的運(yùn)營報(bào)表，先森看到網(wǎng)站的404和403的情況挺多的，5XX的情況倒是很少：網(wǎng)站4xx情況然后先森就很疑惑了，這個(gè)404先森還理解，這個(gè)是由于很多人拿先森網(wǎng)站練手，瘋狂訪問不存在的zip或rar壓縮包，或者asp網(wǎng)頁等，造成大量404，先森今日也是在分享訪問次數(shù)多的重復(fù)IP，量大的就加到CDN的IP黑名單里面，一次兩次的就懶得管了。不過這個(gè)403先森就很不解了，訪問中出現(xiàn)403的IP也不全是先森加到IP黑名單中的呢。日志分析403情況而且訪問的鏈接也是很正常的鏈接，然后單獨(dú)過其中一個(gè)IP看了一下：單獨(dú)IP分析然后看到5次請(qǐng)求都是403，來源都是百度，先森先嘗試直接打開這個(gè)網(wǎng)頁，發(fā)現(xiàn)訪問是正常的。然后再通過訪問來源百度的鏈接打開，這個(gè)鏈接確實(shí)會(huì)跳轉(zhuǎn)到先森的網(wǎng)頁，發(fā)現(xiàn)竟然403了。百度跳轉(zhuǎn)403果斷F12打開審查元素，僅看響應(yīng)頭沒有看出什么端倪，然后先森就開始思考，CDN的配置中，還有哪里會(huì)出現(xiàn)403的響應(yīng)。這種必然是安全方面的配置，且先森開啟的也不多，仔細(xì)想一下就想到應(yīng)該是防盜鏈配置了。然后看了一下請(qǐng)求頭，果然如此：請(qǐng)求頭中的referer先森的referer防盜鏈里面并沒有配置百度的域名，所以出現(xiàn)了這種情況，這個(gè)是先森配置的時(shí)候沒有考慮到的。解決起來也簡單，兩個(gè)辦法，一個(gè)是防盜鏈中增加百度等域名，一個(gè)是關(guān)閉防盜鏈白名單。CDN防盜鏈配置先森選擇了最簡單的方式，直接關(guān)閉了防盜鏈，相信也沒有哪位大佬來盜鏈先森的網(wǎng)站。如果實(shí)在有的話，就配置相關(guān)黑名單吧。如果每個(gè)搜索引擎都去配置到白名單，總還是會(huì)有疏漏，所以還是關(guān)掉比較省事。總結(jié)配置防盜鏈，竟然讓搜索引擎來源中了招，這個(gè)讓先森有點(diǎn)始料未及，所以網(wǎng)站的情況還是得多關(guān)注一下，如果先森又是放個(gè)大半年再來關(guān)注，怕是網(wǎng)站已經(jīng)在搜索引擎那里零分了。

先森之前先發(fā)了一篇博文，講述了一些想從http轉(zhuǎn)為https做的一些準(zhǔn)備：網(wǎng)站http轉(zhuǎn)為https之始，從七牛到騰訊云前進(jìn)的道路從來都不是一帆風(fēng)順的，先森在切換的過程中也是遇到了一些問題，這里簡單的記錄一下歷程。七牛轉(zhuǎn)騰訊云七牛令先森最喜愛的功能就是圖片的處理功能了，現(xiàn)在是騰訊云的對(duì)象存儲(chǔ)COS也支持直接圖片處理，所以先森才開始打算從http轉(zhuǎn)為https。針對(duì)七牛的圖片處理，先森以前還是寫過幾篇博文的：WordPress百度UEditor編輯器自動(dòng)添加七牛云儲(chǔ)存裁剪代碼將WordPress歷史文章中所有圖片加上七牛裁剪水印代碼七牛圖片處理樣式的正確使用方式當(dāng)然，當(dāng)時(shí)的用法比較簡單粗暴，直接用了一大段的圖片處理參數(shù)，而正確的方法應(yīng)該是將固定的處理方法保存為處理樣式，直接在圖片后面調(diào)用圖片處理樣式，這個(gè)先森也在上面的最后一篇博客中寫到了。先森使用圖片處理，最主要的用途還是加速網(wǎng)站打開速度。將不同位置的圖片縮小至合適的大小，讓圖片的體積盡可能的減小，以實(shí)現(xiàn)加快網(wǎng)站訪問速度。先森最喜歡的一點(diǎn)，還是文章中的圖片，結(jié)合燈箱插件，讓圖片在未點(diǎn)擊時(shí)呈現(xiàn)縮放并降低圖片質(zhì)量的狀態(tài)，點(diǎn)擊后顯示原始大小及質(zhì)量。這么好的功能先森當(dāng)然不想放棄，先森網(wǎng)站的各種縮略圖都是不同的大小，所以有不同的樣式。本以為從七牛的圖片處理換到騰訊云的圖片處理，相關(guān)規(guī)則還得自己研究半天才能實(shí)現(xiàn)同樣的效果，結(jié)果圖片處理的規(guī)則竟然非常兼容。COS圖片處理規(guī)則除了需要添加水印的規(guī)則，其他的規(guī)則直接將七牛的復(fù)制過來就可以直接用了，簡直方便的一批。COS新增樣式時(shí)，添加水印圖片竟然只能上傳圖片，而不能從存儲(chǔ)桶里直接選擇，這一點(diǎn)有些體驗(yàn)不佳。而自己通過自定義規(guī)則去添加水印圖片的話，又會(huì)比較麻煩：使用自定義參數(shù)添加水印圖片需要滿足3個(gè)條件不過研究一下還是可以完成操作，總的來說，這個(gè)切換過程還是非常滿意的。自適應(yīng)http和https先森前面的文章也寫到過，為了避免切換到https有問題，先森切換的時(shí)候是沒有開啟強(qiáng)制跳轉(zhuǎn)到https的，所以這里就需要做到http和https的兼容。先森想到的兼容方式就是將網(wǎng)頁中的‘http://’換成‘//’，這樣就會(huì)根據(jù)訪問的協(xié)議自動(dòng)顯示相應(yīng)的協(xié)議。要實(shí)現(xiàn)也很簡單，先森下面這篇博客中講到了“WordPress七牛CDN代碼版”：七牛圖片處理樣式的正確使用方式先森這里把這個(gè)代碼改吧改吧就能實(shí)現(xiàn)https的兼容了。//WordPress七牛CDN代碼版function QiNiuCDN(){    function Rewrite_URI($html){        /* 前面是需要用到七牛的域名,后面是需要加速的靜態(tài)文件類型，使用分隔符 | 隔開即可 */        /* 這里先森小改了一下，兼容https */        $pattern ='/http[s]{0,1}:\/\/(www\.|)capjsj\.cn\/(wp-|ueditor|avatar)([^"\']*?)\.(jpg|js|css|gif|png|jpeg|ico|cur)/i';        /* 七牛CDN空間地址,請(qǐng)自行替換成實(shí)際空間地址*/        /* 先森這里又換成騰訊云COS的地址了 */        $replacement = '//cos.capjsj.cn/$2$3.$4';    $html = preg_replace($pattern, $replacement,$html);    /* 增加了一次替換，把http://替換為// */    $html = preg_replace('/http:\/\/www.cnidcc.cn/i', '//www.cnidcc.cn',$html);    return $html;    }    if(!is_admin()){        ob_start("Rewrite_URI");    }}add_action('init', 'QiNiuCDN');這個(gè)時(shí)候需要注意，WordPress后臺(tái)登錄的時(shí)候，需要使用http，因?yàn)樵谠O(shè)置-常規(guī)處的WordPress地址與站點(diǎn)地址還未修改，為了http與https的兼容，所以當(dāng)時(shí)也并未修改。但若要修改，這里還有個(gè)坑。全站HTTPS先森經(jīng)過一段時(shí)間的測試，發(fā)現(xiàn)https沒有什么問題，所以就打算將網(wǎng)站開啟HTTP到HTTPS的強(qiáng)制跳轉(zhuǎn)，并且把后臺(tái)配置中的站點(diǎn)地址也改成HTTPS，但是先森修改后，竟然遇到了后臺(tái)地址無限跳轉(zhuǎn)。HTTPS無限302跳轉(zhuǎn)經(jīng)過一番搜索，發(fā)現(xiàn)是需要在WordPress網(wǎng)站根目錄中的wp-config.php中添加配置進(jìn)行解決：/* 解決https無限跳轉(zhuǎn)*/$_SERVER['HTTPS'] = 'on';define('FORCE_SSL_LOGIN', true);define('FORCE_SSL_ADMIN', true);添加在文件開頭處即可，藥到病除。CDN緩存命中率低先森閑來無事，跑去17ce測試了一下網(wǎng)站的GET速度，結(jié)果大出先森預(yù)料，竟然全國通紅（忘了截圖）。先森覺得很奇怪，先森這網(wǎng)站這么久了沒更新了，按理說應(yīng)該訪問到的都是緩存才對(duì)啊，然后先森進(jìn)行了排查。先森就從首頁排查起，先森在非放置本站的服務(wù)器上curl首頁，結(jié)果發(fā)現(xiàn)經(jīng)常是 X-Cache-Lookup: Cache Miss，但是連著刷兩次就會(huì)變成Cache Hit，但是再過幾秒curl又變成Cache Miss了，這就有點(diǎn)奇怪了。仔細(xì)看了一下響應(yīng)頭，結(jié)果先森發(fā)現(xiàn) Cache-Control: must-revalidate, max-age=3，這就表示緩存3秒啊，怪不得連著刷能命中緩存，接下來就要看這個(gè)響應(yīng)頭是怎么配置的了。不過講道理，騰訊云的CDN判定是否命中緩存的規(guī)則是看X-Cache-Lookup是否為Hit From MemCache或Hit From Disktank，直接顯示Cache Hit和Cache Miss是很奇怪的。X-Cache-Lookup:Hit From MemCache 表示命中 CDN 節(jié)點(diǎn)的內(nèi)存。X-Cache-Lookup:Hit From Disktank 表示命中 CDN 節(jié)點(diǎn)的磁盤。不過先森也去查了一下，Cache Hit也是正常命中緩存了，也不需要過多的去糾結(jié)。這個(gè)僅緩存3秒的響應(yīng)頭，先森自己記得是沒有配置的，可能比較容易出問題的可能是WordPress中使用的緩存插件。先森使用的緩存插件是WP Super Cache，所以首先就是懷疑這貨。百度大法好，果然是這貨影響的。默認(rèn)情況下，WP Super Cache 返回的 Cache Control Header 固定為： cache-control: max-age=3, must-revalidate ，不管你在插件設(shè)置中設(shè)置的緩存超時(shí)時(shí)間是多久。修改起來也簡單，只要在WordPress根目錄的wp-config.php增加配置即可：define('WPSC_CACHE_CONTROL_HEADER','max-age=3600, must-revalidate');參考：WP SUPER CACHE 緩存插件但是，如果CDN的緩存也是繼承源站的響應(yīng)頭，那先森在騰訊云CDN的緩存配置豈不是沒有用了？所以還是得研究一下什么情況下，CDN會(huì)繼承源站的配置。騰訊云官方文檔對(duì)高級(jí)緩存配置的說明經(jīng)過一番查閱騰訊云官方文檔，發(fā)現(xiàn)是開啟高級(jí)緩存配置時(shí)，CDN會(huì)對(duì)比源站響應(yīng)頭中的max-age值。先森看了一下自己CDN的配置，果然是開啟了高級(jí)緩存配置的，趕緊關(guān)閉：關(guān)閉高級(jí)緩存配置這個(gè)配置估計(jì)是為了迎合一些對(duì)自定義配置要求較高的用戶，先森這種小站就沒必要開啟了。CDN對(duì)no-cache或者no-store不緩存需要注意的一點(diǎn)是，默認(rèn)情況下，CDN也不會(huì)對(duì)no-cache或者no-store的資源進(jìn)行緩存，所以如果有遇到始終無法緩存的情況，可以檢查一下cache-control是否配置了禁止緩存。先森最終是即修改了WP Super Cache的配置，將max-age改為了3600，即1個(gè)小時(shí)；CDN側(cè)是關(guān)閉了高級(jí)緩存配置。至于為什么關(guān)閉了高級(jí)緩存配置的情況下，還要修改插件的緩存配置，那是因?yàn)閙ax-age還會(huì)影響到客戶端瀏覽器的緩存配置，3秒太短了，所以還是修改一下比較好。修改之后，過了一段時(shí)間，先森再進(jìn)入17ce進(jìn)行GET測試，測試的結(jié)果就能讓先森接受了：17ce測速總結(jié)先森在網(wǎng)站開啟HTTPS中，可能還有一些比較小的坑，先森隨手就解決了，這里就沒有記錄了。網(wǎng)站加了CDN后，訪客具體的訪問速度先森實(shí)際上也不得而知，因?yàn)橄壬约捍蜷_網(wǎng)站覺得還是很快的，結(jié)果用17ce一測，全紅，這個(gè)17ce的數(shù)據(jù)也不知道與實(shí)際情況是否匹配。如果有訪問比較慢的，還希望能夠留言告訴先森，您的地域與具體訪問的URL。

最近先森還是重拾了一點(diǎn)大學(xué)期間的激情，對(duì)網(wǎng)站又上心了一點(diǎn)。周圍的網(wǎng)站看著都將http換成了https，先森也想著動(dòng)一動(dòng)了。目前是已經(jīng)完全換為https有一段時(shí)間了，先森也記錄一下切換過程中折騰的一些情況。首先，七牛七牛，先森最早開始使用的CDN與對(duì)象存儲(chǔ)。當(dāng)然，當(dāng)時(shí)并不清楚這些概念，不過依然非常感謝七牛這些年來的陪伴。先森最早一篇關(guān)于七牛的文章是2015年9月初寫的，先森的域名是同年6月份購買的。最早的記錄：WordPress使用七牛CDN導(dǎo)致ajax評(píng)論報(bào)錯(cuò){“error”:”get from image source failed: E405″}當(dāng)初先森還不愿意使用七牛，因?yàn)椴寮]什么作用，但后面正確使用后的感覺是真香，這一香，就香了五年。七牛對(duì)象存儲(chǔ)的免費(fèi)額度七牛免費(fèi)10G的存儲(chǔ)空間，以及10G的下載流量，還有圖片處理的免費(fèi)額度，讓當(dāng)時(shí)囊中羞澀（現(xiàn)在也是）的先森萬分欣喜。當(dāng)時(shí)先森使用的還是萬網(wǎng)的免費(fèi)虛擬主機(jī)，一個(gè)月只有10G的流量，剛開始沒有使用七牛的時(shí)候，各種折騰，然后各種跑滿。使用七牛，讓圖片、js文件等靜態(tài)文件都走七牛CDN后，問題得到有效解決。不過要使用https了，還是得跟七牛暫時(shí)告一段落了。七牛CDN的免費(fèi)額度七牛的對(duì)象存儲(chǔ)必須搭配CDN進(jìn)行使用，否則無法外網(wǎng)訪問。而七牛的CDN只有http請(qǐng)求有免費(fèi)額度，https是必須收費(fèi)的。雖然非常感謝七牛的陪伴，但是有白嫖的機(jī)會(huì)又何必花錢呢？然后，騰訊云先森一直不愿意換HTTPS的原因就是因?yàn)槠吲＃绕涫瞧吲５膱D片處理，可以在請(qǐng)求圖片時(shí)對(duì)圖片進(jìn)行各種壓縮、裁剪、加水印等操作，對(duì)網(wǎng)站加速訪問很有益處。但先森畢竟是一名騰訊云公有云售后運(yùn)維，對(duì)自家產(chǎn)品了解還是很深的。在七牛使用了兩個(gè)產(chǎn)品，一個(gè)是對(duì)象存儲(chǔ)，一個(gè)是CDN。而要換到騰訊云，就得觀察好對(duì)應(yīng)的產(chǎn)品。以前知道騰訊云也有圖片處理的相關(guān)產(chǎn)品，叫做萬象優(yōu)圖，現(xiàn)在改名叫做數(shù)據(jù)萬象，不僅僅做圖片處理了。但是一直沒有去深入了解，也覺得既要使用騰訊云對(duì)象存儲(chǔ)，還要使用萬象優(yōu)圖，很麻煩，不像七牛那么方便：對(duì)象存儲(chǔ)的圖片，加上參數(shù)就能做圖片處理。但是今年3月，騰訊云對(duì)象存儲(chǔ)做出了改變，當(dāng)時(shí)發(fā)了郵件：對(duì)象存儲(chǔ)發(fā)布圖片處理功能當(dāng)時(shí)先森對(duì)網(wǎng)站是放任不管的，對(duì)此也沒有在意。不過最近騰訊云又發(fā)了一次短信通知，先森又去研究了一下。對(duì)象存儲(chǔ)COS先森目前對(duì)網(wǎng)站本來就不是很重視，要切換使用一定是在有免費(fèi)額度的基礎(chǔ)上。這里就需要注意的是，騰訊云的對(duì)象存儲(chǔ)COS在去年9月份是對(duì)免費(fèi)額度進(jìn)行了調(diào)整的，在2019年1月22日之前開通使用對(duì)象存儲(chǔ)的老用戶繼續(xù)每月享有之前的免費(fèi)額度，之后開通的，就只有6個(gè)月的免費(fèi)額度了。但是老用戶還得注意，看自己有沒有收到過以下郵件：COS免費(fèi)額度變更標(biāo)明了【不受此次變更影響】的用戶才能繼續(xù)享受每月免費(fèi)額度，如果有什么疑問，可以在騰訊云官網(wǎng)聯(lián)系在線客服或提交工單。騰訊云COS的免費(fèi)額度還是比較給力，存儲(chǔ)50G，流量10G，請(qǐng)求次數(shù)100萬次。先森在使用時(shí)，一般都是配合CDN進(jìn)行使用，所以這里要關(guān)注的是CDN回源流量。先森這邊剛好有個(gè)賬號(hào)還享有免費(fèi)額度，所以具備七牛遷移騰訊云的基本條件。然后繼續(xù)往下看。騰訊云的對(duì)象存儲(chǔ)簡稱COS，后面都直接用COS了。數(shù)據(jù)萬象CICOS的圖片處理功能，使用的是數(shù)據(jù)萬象的功能，所以還得看數(shù)據(jù)萬象有沒有免費(fèi)額度。在數(shù)據(jù)萬象的文檔中可以看到，很多操作都是有免費(fèi)額度的：數(shù)據(jù)萬象免費(fèi)額度這里先森重點(diǎn)關(guān)注的是基礎(chǔ)圖片處理和CDN回源流量，這兩項(xiàng)是先森用的上的。基礎(chǔ)圖片處理10TB/月，七牛是20TB/月，對(duì)于先森來說完全夠了，先森11月5號(hào)開始使用，截止目前才用不到2GB，說來也是慚愧。CDN回源流量10GB/月，對(duì)先森來說也是完全夠用了。由于是結(jié)合COS來使用的，圖片不添加處理參數(shù)時(shí)，是不會(huì)回源到數(shù)據(jù)萬象的，所以這個(gè)流量先森目前用的特別少，才200MB+。需要注意的是外網(wǎng)出流量，只要你不直接使用數(shù)據(jù)萬象CI默認(rèn)域名進(jìn)行訪問，僅使用CDN->COS->CI的方式訪問的話，是不會(huì)產(chǎn)生的。數(shù)據(jù)萬象默認(rèn)域名格式為存儲(chǔ)桶名-賬號(hào)Appid.piccd.myqcloud.com，盡量還是使用自己的域名通過CDN訪問吧。內(nèi)容分發(fā)網(wǎng)絡(luò)CDN對(duì)象存儲(chǔ)和數(shù)據(jù)萬象都有免費(fèi)額度了，那么再來看看CDN。CDN不像對(duì)象存儲(chǔ)和數(shù)據(jù)萬象，這樣費(fèi)用那樣費(fèi)用，簡單直接，就一個(gè)流量費(fèi)用。不過CDN的免費(fèi)額度按照官方文檔來說，個(gè)人用戶于官網(wǎng)開通 CDN 當(dāng)天可獲贈(zèng)共120GB免費(fèi)境內(nèi)流量包。分6個(gè)月生效，每月生效20GB。其他就沒有更多說明了，不過目前看來，只要接入了CDN，每個(gè)月還是會(huì)有10GB的贈(zèng)送流量包，對(duì)先森來說夠用了，使用前可以在控制臺(tái)看下自己是否有贈(zèng)送流量包：CDN免費(fèi)流量包另外一點(diǎn)，SSL證書要從http切換為https，證書是肯定少不了的。想要安全，肯定不可能使用自頒發(fā)的證書，不過免費(fèi)的證書也還是挺多的。先森使用的SSL證書是在騰訊云上直接免費(fèi)申請(qǐng)的。騰訊云申請(qǐng)的免費(fèi)證書是由亞洲誠信提供的，實(shí)際上也是DigiCert的免費(fèi)DV證書。想比于Let's Encrypt證書的3個(gè)月一換，先森還是喜歡一年一換的。雖然Let's Encrypt證書可以跑腳本進(jìn)行替換，但是從寶塔上的一些體驗(yàn)來看，這個(gè)自動(dòng)替換還是有點(diǎn)坑的。先森不想過多的去修改源站web服務(wù)器上的配置，所以SSL證書是直接部署到CDN上的，使用http的方式進(jìn)行回源。剛開始切換https的時(shí)候，先森擔(dān)心https會(huì)出現(xiàn)問題，所以沒有開啟http到https的強(qiáng)制跳轉(zhuǎn)，將證書部署在CDN上面，切換起來比較方便。當(dāng)然，在切換的過程中，還是不免的遇到一些坑，為了避免篇幅過長，先森這邊后面再說。后面的記錄：網(wǎng)站從http轉(zhuǎn)為https折騰記錄

先森的網(wǎng)站還是放在阿里云免費(fèi)云虛擬主機(jī)，每個(gè)月被關(guān)停之后，只能啟動(dòng)三次。先森上一次被關(guān)停是7月份的事情，沒想到昨天凌晨，噩夢又來襲。早上先森上班之后，抽空看了一下網(wǎng)站的日志。因?yàn)榘⒗镌频奶崾径绦攀橇璩咳c(diǎn)四十多發(fā)的短信，所以先森重點(diǎn)關(guān)注這個(gè)時(shí)間段的，然后就發(fā)現(xiàn)了罪魁禍?zhǔn)祝@篇文章的主角——百度云觀測。坑爹的百度云觀測在日志中，我發(fā)現(xiàn)了大量的請(qǐng)求，全是User-Agent:Baidu-YunGuanCe-ScanBot(ce.baidu.com），而且訪問的還都是/wp-comments-post.php和/wp-admin/admin-ajax.php這些會(huì)接收數(shù)據(jù)，查詢、修改數(shù)據(jù)庫的php文件，這樣一來對(duì)網(wǎng)站的壓力就非常的大了。來自百度云觀測的大量請(qǐng)求這種情況，先森趕緊去百度云觀測把網(wǎng)站監(jiān)控關(guān)閉，百度云觀測的騷操作太恐怖了。關(guān)閉百度云觀測后續(xù)先森在百度云觀測找到這樣的一段話，先森感覺心中一萬只。。。。網(wǎng)站初始化包含多個(gè)分析過程，一般需要5~10分鐘。 網(wǎng)站初始化時(shí)，我們會(huì)對(duì)你的網(wǎng)站進(jìn)行全方位安全體檢。初始化這段時(shí)間內(nèi)，可能會(huì)向你的網(wǎng)站發(fā)送一定攻擊探測請(qǐng)求，以發(fā)現(xiàn)安全漏洞。 一般情況下，正常網(wǎng)站不會(huì)因?yàn)榘踩w檢受到任何影響。后來，昨天下午先森的網(wǎng)站又被關(guān)停了一次，這一次，不是百度云觀測的鍋了，先森已經(jīng)關(guān)了。這次，是有人在拿先森網(wǎng)站練手，搞DDOS，先森看日志，發(fā)現(xiàn)大量的125.39.239.*網(wǎng)段的請(qǐng)求。因?yàn)榫W(wǎng)站放在百度云CDN，免費(fèi)版又不能設(shè)置黑白名單，所以先森只把防守放在了.htaccess文件里面，但是先森發(fā)現(xiàn)，放在里面并無卵用，有了CDN，該訪問還是能訪問。所以先森還是把網(wǎng)站CDN都解析到騰訊云CDN。騰訊云CDN對(duì)移動(dòng)寬帶的支持貌似不太友好，但是好在是能夠配置黑白名單，有這點(diǎn)就夠了。

上篇文章解決了WordPress加入CDN后“非插件瀏覽次數(shù)統(tǒng)計(jì)”瀏覽次數(shù)不刷新問題，同時(shí)留下了兩個(gè)未解決的問題：1.按F5可無限制刷新文章訪問量，并影響數(shù)據(jù)庫效率；2.只解決了后臺(tái)不更新問題，前臺(tái)顯示還是得等CDN刷新后才能更新。那么這篇文章就是為了解決以上兩個(gè)問題。問題分析第一個(gè)問題，先森想到的解決方法是用JS代碼創(chuàng)建cookies，如果cookies存在就不在更新后臺(tái)的統(tǒng)計(jì)量。第二個(gè)問題，直接讓ajax獲取后臺(tái)的訪問量，修改前臺(tái)顯示的訪問量就行了。一開始，先森配置的讓ajax多傳一個(gè)參數(shù)，是判斷cookies是否存在的，存在為1，不存在為0。若cookies不存在，則后臺(tái)訪問量統(tǒng)計(jì)就+1，并返回?cái)?shù)據(jù)庫中的瀏覽量并+1。若cookies存在，則后臺(tái)不增加訪問數(shù)量，直接返回?cái)?shù)據(jù)庫中的瀏覽量并+1，如此訪客刷新也不會(huì)增加訪問量了。但是這樣還是存在會(huì)在后臺(tái)查詢數(shù)據(jù)的問題，查詢多了對(duì)數(shù)據(jù)庫也是一種負(fù)擔(dān)。先森之前沒有意識(shí)到這個(gè)問題，結(jié)果還是晚上睡覺前反思發(fā)現(xiàn)了，且也琢磨除了一個(gè)更好的解決方法。直接在JavaScript代碼中加判斷，如果cookies已存在，則直接不向后端服務(wù)器發(fā)數(shù)據(jù)。這樣一來，前端再怎么刷新，也停留在CDN的層面上。那么要實(shí)現(xiàn)這種效果，就需要先實(shí)現(xiàn)不向后端服務(wù)器發(fā)送數(shù)據(jù)，也能獲取到當(dāng)前文章的訪問量。解決方法很簡單，第一次獲取訪問量時(shí)，將后端服務(wù)器返回的訪問量直接寫入cookies，下次刷新時(shí)，直接從cookies中讀取訪問量。另外，還有一個(gè)地方需要解釋一下，cookies的過期時(shí)間。如果cookies時(shí)間太長了的話，那么未免還是會(huì)損失一些訪問量，所以先森就沒有設(shè)置cookies的過期時(shí)間，保持默認(rèn)。cookies的默認(rèn)過期為關(guān)閉瀏覽器，先森覺得，這樣一來還是比較合理的。同時(shí)，一個(gè)訪客，可能并不會(huì)只打開本站一篇文章就關(guān)閉，打開多篇文章時(shí)，每篇文章的訪問量是不一樣的，需要從cookies中獲取的話，cookies的名稱就必須不一樣。不然訪問打開其他文章，看到了訪問量都是同一個(gè)數(shù)值。解決方法就是，已“固定值+文章ID”的方式，確定cookies名稱的唯一。效果實(shí)現(xiàn)上一篇文章中，先森是模仿通用的評(píng)論ajax提交的處理方式，自建了一個(gè)類似的php。但這樣可能有點(diǎn)不安全，也有點(diǎn)麻煩，所以先森還是研究著將php代碼部分放進(jìn)了主題的functions.php。首先還是在footer.php中添加ajax的代碼，注意需要將前臺(tái)顯示訪問量的標(biāo)簽ID或class名稱改成自己的。<script type= "text/javascript" > function GetCookie(sName) {    var arr = document.cookie.match(new RegExp("(^| )"+sName+"=([^;]*)(;|$)"));    if(arr !=null){return unescape(arr[2])};    return null;}var postviews_cook=GetCookie("postviews<?php the_ID();?>");  if ( postviews_cook == null ){$.ajax({ type:'POST', url: "<?php echo admin_url('admin-ajax.php');?>" , data:"postviews_id=<?php the_ID();?>&action=postviews",cache:false,success: function(postviews_count){ $("#views").text('閱讀：' + postviews_count + ' 次');document.cookie="postviews<?php the_ID();?>=" + postviews_count;} });   }  else{$("#views").text('閱讀：' + postviews_cook + ' 次');}; </script><?php endif ; ?>然后直接在自己主題的functions.php中添加下面的代碼：/** 緩存時(shí)更新瀏覽量-有緩存* //www.cnidcc.cn/ajax_cookies_views.html*/function postviews_cache(){    if( empty( $_POST['postviews_id'] ) ) return;        $post_ID = $_POST['postviews_id'];        if( $post_ID > 0 ) {                $post_views = (int)get_post_meta($post_ID, 'views', true);/*if( !defined( 'WP_CACHE' ) || !WP_CACHE ){ 以前的錯(cuò)誤代碼*/if( defined( 'WP_CACHE' ) && WP_CACHE ){ //如果wp-config.php開啟緩存    update_post_meta($post_ID, 'views', ( $post_views + 1 ));}                echo ( $post_views + 1 );                exit();        }}add_action( 'wp_ajax_nopriv_postviews', 'postviews_cache' );add_action( 'wp_ajax_postviews', 'postviews_cache' );2018年06月07日更新：感謝網(wǎng)友@魚魚 在評(píng)論區(qū)指出的BUG，以前寫上面的代碼的時(shí)候參考了wp-postviews插件wp-postviews.php里面的代碼，結(jié)果學(xué)藝不精，只看了上半截，忽略了下半截。錯(cuò)誤的代碼竟然用了近1年的時(shí)間沒發(fā)現(xiàn)，還發(fā)布在這里誤人子弟，實(shí)在羞愧。上面的代碼中，錯(cuò)誤的代碼依然留存著，只是注釋了，修改的方法有兩種，第一種是上面那樣，第二種則是將10-12行的if段改為下方模式（這種就是wp-postviews插件的寫法）：if( defined( 'WP_CACHE' ) && WP_CACHE ) //如果wp-config.php沒有開啟緩存    return;                             //退出（中止函數(shù)的運(yùn)行）    update_post_meta($post_ID, 'views', ( $post_views + 1 ));注意，如果網(wǎng)站的WordPress只加入了CDN，沒有使用緩存插件的話，需要將上面代碼改成下面的，也就是刪除開啟緩存判斷：/** 緩存時(shí)更新瀏覽量-無緩存* //www.cnidcc.cn/ajax_cookies_views.html*/function postviews_cache(){    if( empty( $_POST['postviews_id'] ) ) return;        $post_ID = $_POST['postviews_id'];        if( $post_ID > 0 ) {                $post_views = (int)get_post_meta($post_ID, 'views', true);                update_post_meta($post_ID, 'views', ( $post_views + 1 ));                echo ( $post_views + 1 );                exit();        }}如果想使用有緩存的版本，想要開啟網(wǎng)站緩存，可以選擇安裝緩存插件，或者直接在網(wǎng)站根目錄的wp-config.php中，加入下面這行代碼：define('WP_CACHE', true);如果網(wǎng)站沒有加入CDN，也沒有使用緩存插件，那么有兩個(gè)選項(xiàng)：1、Ctrl + D 保存本頁到書簽，待文章變成靜態(tài)頁面后再拿出來看看；2、Ctrl + W 關(guān)閉本頁，因?yàn)槌悄阋芯看a，本頁對(duì)你沒有什么價(jià)值，看看更多該看的吧。總結(jié)對(duì)于本文的解決方案有什么意見和建議，希望能夠在下方評(píng)論欄中提出來，先森覺得還有能夠改進(jìn)的地方，但一人之力實(shí)在有些相形見絀。ajax是個(gè)很實(shí)用的東西，可能還有更多可以使用的地方，先森也得好好想想。

不知道多少人和先森一樣，在最初接觸wordpress的時(shí)候，被網(wǎng)上的各類教程灌輸了“能用代碼版，就不用插件”的概念。先森就本著這個(gè)概念，在文章的訪問量的時(shí)候，先森就找的代碼版。網(wǎng)上提供的代碼版瀏覽次數(shù)統(tǒng)計(jì)功能的文章，名稱都差不多，類似“WordPress非插件添加文章瀏覽次數(shù)統(tǒng)計(jì)功能”這種比比皆是。先森應(yīng)該是在wordpress大學(xué)看到的教程，關(guān)于教程先森就不再贅述了。本文主要解決的是，開啟CDN后，用這種代碼版訪問量統(tǒng)計(jì)的方式瀏覽次數(shù)不再刷新的問題，如果想結(jié)合著來使用的話，統(tǒng)計(jì)代碼部分可以去wordpress大學(xué)看《WordPress非插件添加文章瀏覽次數(shù)統(tǒng)計(jì)功能》這篇文章。瀏覽次數(shù)問題分析先森其實(shí)很早就意識(shí)到，開啟CDN后，其實(shí)瀏覽量不是不刷新，而是只在首次緩存的時(shí)候才會(huì)增加一次。因?yàn)橹挥械谝淮卧L問的時(shí)候才會(huì)執(zhí)行php，緩存后就直接訪問的html了，所以就不會(huì)增加統(tǒng)計(jì)了。所以解決問題的方式，是讓html也能統(tǒng)計(jì)到瀏覽次數(shù)，先森認(rèn)知中的方法就只有一個(gè)：ajax。然而當(dāng)初先森雖然知道問題原因，知道解決方式，但奈何先森代碼能力不強(qiáng)，當(dāng)時(shí)沒能解決。先森始終認(rèn)為，一個(gè)問題如果死活解決不了，那么就先放放，過段時(shí)間再反顧可能就會(huì)發(fā)現(xiàn)，這個(gè)問題根本就不是事。當(dāng)然，這個(gè)時(shí)間可能就有點(diǎn)久了，起碼就ajax這個(gè)問題，先森等了一兩年。。。。先森想到的用ajax更新瀏覽次數(shù)的方法就是，使用ajax提交文章的ID給后方的php，后方的php接收到文章ID后，將該文章的瀏覽次數(shù)+1。效果實(shí)現(xiàn)先森研究了一晚上，發(fā)現(xiàn)要解決還是挺簡單的。又是研究幾小時(shí)，分享幾分鐘，心塞。首先，在footer.php中添加ajax的代碼，注意url的地址要改為自己的php路徑：<?php if  (is_singular()) : ?>  <!-- ajax post view -->  <!-- ajax post view -->  <script type= "text/javascript" >$.ajax({ type:'POST', url: "//www.cnidcc.cn/wp-content/themes/*/*.php" ,   /*此處需要修改為自己的php路徑*/data: { "postviews_id" : "<?php the_ID();?>" } });   </script><?php endif ; ?>接收數(shù)據(jù)的php代碼很簡單，參考了評(píng)論的comments-ajax.php的頭部，禁止直接訪問，然后加上了幾行更新瀏覽量的代碼。將下面內(nèi)容保存到一個(gè)php文件中，放入自己的wordpress主題里面，將該php的訪問鏈接加入到上面的url中：<?php//禁止直接訪問本phpif ( 'POST' != $_SERVER['REQUEST_METHOD'] ) {        header('Allow: POST');        header('HTTP/1.1 405 Method Not Allowed');        header('Content-Type: text/plain');        exit;}require( dirname(__FILE__) . '/../../../wp-load.php' );nocache_headers();$post_ID = $_POST['postviews_id'];$post_views = (int)get_post_meta($post_ID, 'views', true);update_post_meta($post_ID, 'views', ($post_views+1));?>如此一來，即使加入了CDN，文章頁面變成了靜態(tài)頁面，后臺(tái)也會(huì)更新訪問次數(shù)了。總結(jié)這樣僅僅是解決了文章頁面被緩存后，瀏覽次數(shù)無法被統(tǒng)計(jì)到的問題，但是還并不完善。上面的功能實(shí)現(xiàn)之后，你會(huì)發(fā)現(xiàn)，每一次刷新瀏覽次數(shù)都會(huì)加一，如果有人一直按著F5，那么增加的瀏覽次數(shù)就有點(diǎn)恐怖了。這樣還會(huì)增加服務(wù)器的負(fù)擔(dān)，像先森這種把網(wǎng)站放在阿里云虛擬主機(jī)的，若負(fù)載過量還會(huì)直接關(guān)停，被人這樣搞的關(guān)機(jī)先森就哭了。所以，下篇文章先森會(huì)分享使用cookies來限制訪問次數(shù)無限增加的問題。另外，除了訪問量持續(xù)增加的問題，還有一個(gè)地方可以優(yōu)化。既然ajax能夠異步提交數(shù)據(jù)，那么能不能動(dòng)態(tài)的修改文章中的瀏覽次數(shù)呢？答案是肯定的，先森也會(huì)在下一篇文章中更新。關(guān)于上面的問題，請(qǐng)查看下一篇文章：CDN后用Ajax動(dòng)態(tài)提交、顯示文章閱讀量，cookies避免重復(fù)刷新

自從用上CDN，需要關(guān)注的前臺(tái)頁面的問題就更多了，因?yàn)橐苊庖恍┎辉摫籆DN緩存的內(nèi)容被緩存，導(dǎo)致訪客訪問到不該看到的內(nèi)容，影響使用體驗(yàn)。最近，先森發(fā)現(xiàn)曾解決過的問題故態(tài)復(fù)萌。用了CDN之后比較突出的問題，就是如果一篇文章如果先森登錄之后再去訪問，其他訪客訪問的時(shí)候，會(huì)顯示“內(nèi)容管理”、“登出”、評(píng)論框會(huì)顯示先森的頭像等問題。這個(gè)問題其實(shí)之前已經(jīng)處理過了，但是先森wordpress升級(jí)之后，發(fā)現(xiàn)原本通過WP Super Cache設(shè)置的“不要為已知用戶緩存”和“讓已知用戶匿名使他們?yōu)g覽的內(nèi)容是緩存文件”竟然失效了。查看了下WP Super Cache的版本，發(fā)現(xiàn)四周前才更新，并且提示與當(dāng)前WordPres版本兼容，先森也確定選項(xiàng)已經(jīng)勾選，但就是不生效，所以就很心塞。發(fā)現(xiàn)問題，處理問題。先森冒著英語超爛的風(fēng)險(xiǎn)，去了WP Super Cache的插件頁面，看了一圈問題討論，就是沒發(fā)現(xiàn)有人提這個(gè)BUG的，在官方找解決方案的道路失敗了。也不知道新的版本什么時(shí)候發(fā)布，發(fā)布會(huì)不會(huì)包含解決這個(gè)問題，所以先森只能又冒著php一知半解的風(fēng)險(xiǎn)來寫代碼了。解題思路解決方式先森覺得有兩種，一個(gè)是去把自己的主題中的前臺(tái)中管理員登錄后才會(huì)顯示的代碼給刪掉，另一種就是讓管理員在前臺(tái)匿名，被認(rèn)為沒有登錄。第一種方案，先森覺得有點(diǎn)費(fèi)時(shí)費(fèi)力。當(dāng)初主題的代碼是自己一行一行的寫的，現(xiàn)在讓自己去刪，內(nèi)心表示很痛苦啊（心中憧憬著哪天要是不用CDN了...）。所以先森還是想實(shí)現(xiàn)第二種方案。經(jīng)過研究自己的主題，先森發(fā)現(xiàn)，會(huì)顯示管理員才能看到的東西，大多使用了這樣的一種套路：<?php if (is_user_logged_in()){    '我是管理員'} ?>都用的is_user_logged_in()這個(gè)函數(shù)來判斷用戶是否登錄，所以先森就想，讓這個(gè)函數(shù)返回“用戶沒有登錄”豈不是就可以了？is_user_logged_in()函數(shù)介紹：is_user_logged_in()函數(shù)位于wp-includes/pluggable.php函數(shù)參數(shù)：該函數(shù)不接受任何參數(shù)。返回值：已登陸返回True，否則返回False。先森在函數(shù)所在位置，找到了這個(gè)函數(shù)的代碼：if ( !function_exists('is_user_logged_in') ) :/** * Checks if the current visitor is a logged in user. * * @since 2.0.0 * * @return bool True if user is logged in, false if not logged in. */function is_user_logged_in() {        $user = wp_get_current_user();        return $user->exists();}endif;先森把上面的return內(nèi)容改成了如下內(nèi)容：if(!is_admin()){    return false;}else{return $user->exists();}這樣之后，只要不是后臺(tái)，就會(huì)返回false，這樣前臺(tái)就會(huì)得到管理員沒有登錄。先森發(fā)現(xiàn)使用了is_user_logged_in()函數(shù)的位置都已經(jīng)不會(huì)在登錄的情況下顯示了，但是還有兩個(gè)地方例外。第一個(gè)地方是文章頁面上的“編輯”按鈕，另一個(gè)就是評(píng)論的頭像了。通過查看代碼，先森發(fā)現(xiàn)編輯按鈕用的是edit_post_link()函數(shù)：edit_post_link('編輯', ' &#124; ', '');函數(shù)說明：若用戶已登錄且具有編輯文章的權(quán)限，該標(biāo)簽顯示一個(gè)可編輯當(dāng)前文章的鏈接。該標(biāo)簽必須用在主循環(huán)（loop）中。這個(gè)函數(shù)就沒有使用is_user_logged_in()函數(shù)了，所以通過修改is_user_logged_in()的返回值就對(duì)“編輯”按鈕不生效了。再來看評(píng)論頭像。修改了is_user_logged_in()的返回值之后，頭像旁邊的文字已經(jīng)變成了未登錄狀態(tài)下的文字，但是頭像依然是先森的管理員評(píng)論頭像。再去查看代碼，發(fā)現(xiàn)評(píng)論頭像部分雖然也使用了is_user_logged_in()函數(shù)，但是還另外使用了一個(gè)全局變量，代碼大致如下：global $current_user;get_currentuserinfo();...echo get_avatar( $current_user->user_email, $size = '48' ,'');這樣是通過獲取當(dāng)前用戶信息，然后來獲取用戶的email郵箱地址，這樣就和is_user_logged_in()函數(shù)無關(guān)了，因此前臺(tái)還是會(huì)顯示管理員的頭像。但也正是這個(gè)問題，讓先森找到了解決的辦法。讓管理員在前臺(tái)匿名評(píng)論頭像是通過獲取當(dāng)前登錄用戶的相關(guān)信息，進(jìn)而獲取用戶郵箱來顯示頭像的。用到的獲取用戶信息函數(shù)是:get_currentuserinfo()而其實(shí)看is_user_logged_in()函數(shù)，其實(shí)它也有獲取當(dāng)前用戶的相關(guān)信息，但用的是另一個(gè)函數(shù)：$user = wp_get_current_user();而這兩個(gè)函數(shù)，其實(shí)是同一個(gè)函數(shù)，只是wp_get_current_user()是get_currentuserinfo()的進(jìn)階版：Notice: 自4.5.0版本起，已不建議使用get_currentuserinfo，請(qǐng)換用wp_get_current_user()。 in ***\wp-includes\functions.php on line 3707既然如此，只需要讓當(dāng)前用戶信息為空即可。在自己的主題function.php最后加入以下代碼，那么在前臺(tái)就用戶信息就為空了，即獲取不到用戶信息了：/*** 讓管理員在前臺(tái)訪問匿名** //www.cnidcc.cn/make_known_users_anonymous.html*/function make_known_users_anonymous() {    global $current_user; if(!is_admin()){    $current_user = array( 'user_login' => '', 'user_email' =>'', 'user_level' => '', 'user_firstname' => '', 'user_lastname' => '', 'display_name' => '', 'ID' => '', 'user_url' => '', ); } return $current_user;}add_action( 'init', 'make_known_users_anonymous' );如果想要調(diào)試的話，可以把以下代碼放在前臺(tái)頁面中想放的位置：<?php  global $current_user; get_currentuserinfo(); //或者將這兩行換成 $current_user = wp_get_current_user();if( is_user_logged_in()){    echo '已經(jīng)登錄';}else{    echo '沒有登錄';}echo('Username: ' . $current_user->user_login . "\n"); //輸出用戶名  ?>但目前這種方式有個(gè)BUG，那就是在文章編輯頁面點(diǎn)擊預(yù)覽的時(shí)候會(huì)返回404，這個(gè)待先森找找解決方法。2017-09-01更新先森看了下，預(yù)覽的頁面會(huì)在文章鏈接后面加上“?preview=true”或者“?p=xxx&preview=true”,那么，當(dāng)訪問鏈接是帶了“preview=true”的，就不清除登錄信息就行了。那么，把上面的匿名代碼改成下面的代碼，加入functions.php中/*** 讓管理員在前臺(tái)訪問匿名** //www.cnidcc.cn/make_known_users_anonymous.html*/function make_known_users_anonymous() {    global $current_user; if(!is_admin() && $_GET['preview'] != 'true'){    $current_user = array( 'user_login' => '', 'user_email' =>'', 'user_level' => '', 'user_firstname' => '', 'user_lastname' => '', 'display_name' => '', 'ID' => '', 'user_url' => '', ); } return $current_user;}add_action( 'init', 'make_known_users_anonymous' );如果有任何問題，可以在下方評(píng)論。關(guān)于訪客填寫的昵稱、郵箱、域名等信息不被CDN緩存，可以看看先森的解決方案：用cookie解決網(wǎng)站開啟CDN緩存之后已知用戶頭像昵稱被緩存等系列問題用cookie記住用戶信息后隱藏信息輸入框，優(yōu)化用戶體驗(yàn)