發現的問題對象存儲簡稱COS，數據萬象簡稱CI。由于5月數據萬象突然征收“CDN回源流量費”，由于先森圖片請求量不大，且還是需要使用數據萬象的圖片處理功能，所以先森在CDN->COS的中間加了一個Nginx做反向代理，由于Nginx所在的服務器和先森的COS存儲桶是同地域的，所以服務器到COS的流量是內網，因此講道理COS和CI都不會產生CDN回源流量了。但是，先森過了幾天又來看數據萬象控制臺，發現每天還是有產生CDN回源流量，先森這波就無語了，明明都沒用CDN了，怎么還會有CDN回源流量呢，這不是無中生有么。數據萬象控制臺問題原因定位經過排查確認，是由于先森的Nginx直接透傳了CDN的回源請求，導致COS和CI判定流量是來自CDN回源。。。先森在服務器上進行抓包確認。同一個圖片，CDN回源到CVM服務器：抓包：CDN回源到CVM服務器CVM回源到COS：抓包：CVM回源到COS可以看到，CDN回源到CVM比較有特殊性的請求頭是以下兩個，在CVM請求到COS時也是帶著的： X-NWS-LOG-UUID: 630013543448005765 X-Tencent-Ua: Qcloud那么，就要想辦法把這兩個請求頭去掉，不讓其透傳。去除Nginx請求頭先森百度了一下，Nginx內置的模塊中沒有刪除指定請求頭的，只能編譯增加headers-more-nginx-module模塊。先森圖省事，服務器安裝了寶塔，Nginx是通過寶塔安裝的。看了一下，寶塔安裝的Nginx不像Redis等軟件，可以在網頁上動態添加支持模塊，只能命令行編譯添加模塊。當然編譯之前需要看一下寶塔的Nginx會不會已經很好心的幫忙編譯了headers-more-nginx-module。查看Nginx已經安裝的模塊 ./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模塊，操作了一下編譯。其中，有一些點需要注意一下。1、模塊的下載地址，下載后解壓得到的目錄，就是編譯時指定的目錄： 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目錄下，使用先森參考的這個方法寶塔在更新Nginx時會清空該目錄；修改反向代理配置文件進入寶塔的網站配置頁，找到反向代理的配置文件，增加想要去除的請求頭即可。 more_clear_input_headers "X-Tencent-Ua"; more_clear_input_headers "X-NWS-LOG-UUID";修改反向代理配置重新抓包確認請求頭沒有透傳修改好了之后，重新抓個包，看看請求頭還有沒有透傳。CDN回源到CVM服務器，可以看到這兩個請求頭還是在的（肯定在，先森又沒刪）。CDN回源到CVM然后再看CVM服務器訪問COS的請求頭，指定清除的兩個請求頭已經沒有了。先森只是剛改好，由于數據萬象的控制臺對于“CDN回源流量”的監控粒度是1天，所以起碼要明天才能看到效果，希望有效。

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

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

本著安全的考慮，先森在騰訊云的CDN配置里開啟了防盜鏈的配置，結果先森發現這里面有個小坑，竟然禁止了搜索引擎。發現與排查先森最近有開始關注起來網站了，之前先森對網站是一個活著即可的態度的，所以CDN的緩存時間配置的比較長，先森想著緩存命中率應該很高才對，結果實際上很低，所以先森開始尋找命中率低的原因。命中率低可能的原因首先，先了解一下可能是哪些原因導致命中率低。先森看了一下上面的原因，最大的可能就是狀態碼4XX和5XX的情況了。通過CDN控制臺的運營報表，先森看到網站的404和403的情況挺多的，5XX的情況倒是很少：網站4xx情況然后先森就很疑惑了，這個404先森還理解，這個是由于很多人拿先森網站練手，瘋狂訪問不存在的zip或rar壓縮包，或者asp網頁等，造成大量404，先森今日也是在分享訪問次數多的重復IP，量大的就加到CDN的IP黑名單里面，一次兩次的就懶得管了。不過這個403先森就很不解了，訪問中出現403的IP也不全是先森加到IP黑名單中的呢。日志分析403情況而且訪問的鏈接也是很正常的鏈接，然后單獨過其中一個IP看了一下：單獨IP分析然后看到5次請求都是403，來源都是百度，先森先嘗試直接打開這個網頁，發現訪問是正常的。然后再通過訪問來源百度的鏈接打開，這個鏈接確實會跳轉到先森的網頁，發現竟然403了。百度跳轉403果斷F12打開審查元素，僅看響應頭沒有看出什么端倪，然后先森就開始思考，CDN的配置中，還有哪里會出現403的響應。這種必然是安全方面的配置，且先森開啟的也不多，仔細想一下就想到應該是防盜鏈配置了。然后看了一下請求頭，果然如此：請求頭中的referer先森的referer防盜鏈里面并沒有配置百度的域名，所以出現了這種情況，這個是先森配置的時候沒有考慮到的。解決起來也簡單，兩個辦法，一個是防盜鏈中增加百度等域名，一個是關閉防盜鏈白名單。CDN防盜鏈配置先森選擇了最簡單的方式，直接關閉了防盜鏈，相信也沒有哪位大佬來盜鏈先森的網站。如果實在有的話，就配置相關黑名單吧。如果每個搜索引擎都去配置到白名單，總還是會有疏漏，所以還是關掉比較省事。總結配置防盜鏈，竟然讓搜索引擎來源中了招，這個讓先森有點始料未及，所以網站的情況還是得多關注一下，如果先森又是放個大半年再來關注，怕是網站已經在搜索引擎那里零分了。

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

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

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

上篇文章解決了WordPress加入CDN后“非插件瀏覽次數統計”瀏覽次數不刷新問題，同時留下了兩個未解決的問題：1.按F5可無限制刷新文章訪問量，并影響數據庫效率；2.只解決了后臺不更新問題，前臺顯示還是得等CDN刷新后才能更新。那么這篇文章就是為了解決以上兩個問題。問題分析第一個問題，先森想到的解決方法是用JS代碼創建cookies，如果cookies存在就不在更新后臺的統計量。第二個問題，直接讓ajax獲取后臺的訪問量，修改前臺顯示的訪問量就行了。一開始，先森配置的讓ajax多傳一個參數，是判斷cookies是否存在的，存在為1，不存在為0。若cookies不存在，則后臺訪問量統計就+1，并返回數據庫中的瀏覽量并+1。若cookies存在，則后臺不增加訪問數量，直接返回數據庫中的瀏覽量并+1，如此訪客刷新也不會增加訪問量了。但是這樣還是存在會在后臺查詢數據的問題，查詢多了對數據庫也是一種負擔。先森之前沒有意識到這個問題，結果還是晚上睡覺前反思發現了，且也琢磨除了一個更好的解決方法。直接在JavaScript代碼中加判斷，如果cookies已存在，則直接不向后端服務器發數據。這樣一來，前端再怎么刷新，也停留在CDN的層面上。那么要實現這種效果，就需要先實現不向后端服務器發送數據，也能獲取到當前文章的訪問量。解決方法很簡單，第一次獲取訪問量時，將后端服務器返回的訪問量直接寫入cookies，下次刷新時，直接從cookies中讀取訪問量。另外，還有一個地方需要解釋一下，cookies的過期時間。如果cookies時間太長了的話，那么未免還是會損失一些訪問量，所以先森就沒有設置cookies的過期時間，保持默認。cookies的默認過期為關閉瀏覽器，先森覺得，這樣一來還是比較合理的。同時，一個訪客，可能并不會只打開本站一篇文章就關閉，打開多篇文章時，每篇文章的訪問量是不一樣的，需要從cookies中獲取的話，cookies的名稱就必須不一樣。不然訪問打開其他文章，看到了訪問量都是同一個數值。解決方法就是，已“固定值+文章ID”的方式，確定cookies名稱的唯一。效果實現上一篇文章中，先森是模仿通用的評論ajax提交的處理方式，自建了一個類似的php。但這樣可能有點不安全，也有點麻煩，所以先森還是研究著將php代碼部分放進了主題的functions.php。首先還是在footer.php中添加ajax的代碼，注意需要將前臺顯示訪問量的標簽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中添加下面的代碼：/** 緩存時更新瀏覽量-有緩存* //www.lzhcjx.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 ){ 以前的錯誤代碼*/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日更新：感謝網友@魚魚 在評論區指出的BUG，以前寫上面的代碼的時候參考了wp-postviews插件wp-postviews.php里面的代碼，結果學藝不精，只看了上半截，忽略了下半截。錯誤的代碼竟然用了近1年的時間沒發現，還發布在這里誤人子弟，實在羞愧。上面的代碼中，錯誤的代碼依然留存著，只是注釋了，修改的方法有兩種，第一種是上面那樣，第二種則是將10-12行的if段改為下方模式（這種就是wp-postviews插件的寫法）：if( defined( 'WP_CACHE' ) && WP_CACHE ) //如果wp-config.php沒有開啟緩存    return;                             //退出（中止函數的運行）    update_post_meta($post_ID, 'views', ( $post_views + 1 ));注意，如果網站的WordPress只加入了CDN，沒有使用緩存插件的話，需要將上面代碼改成下面的，也就是刪除開啟緩存判斷：/** 緩存時更新瀏覽量-無緩存* //www.lzhcjx.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();        }}如果想使用有緩存的版本，想要開啟網站緩存，可以選擇安裝緩存插件，或者直接在網站根目錄的wp-config.php中，加入下面這行代碼：define('WP_CACHE', true);如果網站沒有加入CDN，也沒有使用緩存插件，那么有兩個選項：1、Ctrl + D 保存本頁到書簽，待文章變成靜態頁面后再拿出來看看；2、Ctrl + W 關閉本頁，因為除非你要研究代碼，本頁對你沒有什么價值，看看更多該看的吧。總結對于本文的解決方案有什么意見和建議，希望能夠在下方評論欄中提出來，先森覺得還有能夠改進的地方，但一人之力實在有些相形見絀。ajax是個很實用的東西，可能還有更多可以使用的地方，先森也得好好想想。

不知道多少人和先森一樣，在最初接觸wordpress的時候，被網上的各類教程灌輸了“能用代碼版，就不用插件”的概念。先森就本著這個概念，在文章的訪問量的時候，先森就找的代碼版。網上提供的代碼版瀏覽次數統計功能的文章，名稱都差不多，類似“WordPress非插件添加文章瀏覽次數統計功能”這種比比皆是。先森應該是在wordpress大學看到的教程，關于教程先森就不再贅述了。本文主要解決的是，開啟CDN后，用這種代碼版訪問量統計的方式瀏覽次數不再刷新的問題，如果想結合著來使用的話，統計代碼部分可以去wordpress大學看《WordPress非插件添加文章瀏覽次數統計功能》這篇文章。瀏覽次數問題分析先森其實很早就意識到，開啟CDN后，其實瀏覽量不是不刷新，而是只在首次緩存的時候才會增加一次。因為只有第一次訪問的時候才會執行php，緩存后就直接訪問的html了，所以就不會增加統計了。所以解決問題的方式，是讓html也能統計到瀏覽次數，先森認知中的方法就只有一個：ajax。然而當初先森雖然知道問題原因，知道解決方式，但奈何先森代碼能力不強，當時沒能解決。先森始終認為，一個問題如果死活解決不了，那么就先放放，過段時間再反顧可能就會發現，這個問題根本就不是事。當然，這個時間可能就有點久了，起碼就ajax這個問題，先森等了一兩年。。。。先森想到的用ajax更新瀏覽次數的方法就是，使用ajax提交文章的ID給后方的php，后方的php接收到文章ID后，將該文章的瀏覽次數+1。效果實現先森研究了一晚上，發現要解決還是挺簡單的。又是研究幾小時，分享幾分鐘，心塞。首先，在footer.php中添加ajax的代碼，注意url的地址要改為自己的php路徑：<?php if  (is_singular()) : ?>  <!-- ajax post view -->  <!-- ajax post view -->  <script type= "text/javascript" >$.ajax({ type:'POST', url: "//www.lzhcjx.cn/wp-content/themes/*/*.php" ,   /*此處需要修改為自己的php路徑*/data: { "postviews_id" : "<?php the_ID();?>" } });   </script><?php endif ; ?>接收數據的php代碼很簡單，參考了評論的comments-ajax.php的頭部，禁止直接訪問，然后加上了幾行更新瀏覽量的代碼。將下面內容保存到一個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，文章頁面變成了靜態頁面，后臺也會更新訪問次數了。總結這樣僅僅是解決了文章頁面被緩存后，瀏覽次數無法被統計到的問題，但是還并不完善。上面的功能實現之后，你會發現，每一次刷新瀏覽次數都會加一，如果有人一直按著F5，那么增加的瀏覽次數就有點恐怖了。這樣還會增加服務器的負擔，像先森這種把網站放在阿里云虛擬主機的，若負載過量還會直接關停，被人這樣搞的關機先森就哭了。所以，下篇文章先森會分享使用cookies來限制訪問次數無限增加的問題。另外，除了訪問量持續增加的問題，還有一個地方可以優化。既然ajax能夠異步提交數據，那么能不能動態的修改文章中的瀏覽次數呢？答案是肯定的，先森也會在下一篇文章中更新。關于上面的問題，請查看下一篇文章：CDN后用Ajax動態提交、顯示文章閱讀量，cookies避免重復刷新

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