發現的問題對象存儲簡稱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.cnidcc.cn/i', '//www.cnidcc.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折騰記錄

時光流轉，先森竟然已經近一年沒有發過博客了，現在先森的工作是騰訊云公有云的大客戶售后運維，平時比較忙，博客這邊就基本處于荒廢狀態了。本文是昨天處理的一個客戶遇到的問題，雖然問題不是很難，但是比較難為先森，先森做運維，做的是Linux運維，對Windows著實不是很熟悉。問題背景客戶反饋，Windows服務器上，配置完IIS的FTP服務器后，安全組需要配置全端口放通才能正常訪問FTP。Windows先森不是很懂，但是FTP還是挺熟悉的，上一家公司做運維的時候，FTP環境還是搭建過不少的，不過搭建的都是vsftpd。這個問題先森這邊一看，想到的就是被動端口的問題。FTP有主動模式和被動模式兩種：主動模式：主動模式下，FTP客戶端從任意的非特殊的端口（N > 1023）連入到FTP服務器的命令端口--21端口。然后客戶端在N+1（N+1 >= 1024）端口監聽，并且通過N+1（N+1 >= 1024）端口發送命令給FTP服務器。服務器會反過來連接用戶本地指定的數據端口，比如20端口。被動模式：被動模式下，FTP客戶端會用一個大于等于1024的端口N去連接FTP服務器的命令端口（21端口），然后服務器側會告知客戶端一個端口，讓客戶端再用本地N+1的端口去連接服務器告知的這個端口，用于傳輸數據，而服務器這個端口就叫做被動端口解決問題讓客戶參考騰訊云官方文檔《Windows 云服務器搭建 FTP 服務》中的第六步，設置安全組及防火墻： 騰訊云官方文檔-步驟6客戶這個問題，其實答案本身就在上圖中了。FTP的被動模式，默認的被動端口范圍就是1024-65535。客戶也說了，所有端口全放通是能夠正常使用的。所以客戶的需求是縮小被動端口范圍。上面的步驟6的第二點，其實是有說明怎么配置被動端口范圍的。但是客戶連我們精心準備的騰訊云文檔都不愿意看，難道還想讓客戶去看滿是英文的微軟官方文檔么。微軟官方文檔中的第四步也說明了怎么配置被動端口：微軟官方文檔(已翻譯)但是微軟官方文檔是真的耿直，通篇文檔一張圖片示意都沒有，且跟著做了其實也有坑。先森這邊也讓客戶按照指引，在FTP防火墻支持中配置被動端口的范圍。可是客戶配置之后，在安全組中放通了相應端口，結果還是會出現報錯：打開 FTP 服務器上的文件夾時發生錯誤，請檢查是否有權限訪問改文件夾。詳細信息：操作超時這個問題看著是權限問題，其實還是被動端口沒有放通的問題導致。另外有一點，配置FTP防火墻支持的時候，除了可以配置被動端口的范圍，還有一個“防火墻的外部 IP 地址”，最好也一并配置上，需要配置為服務器的公網IP地址，否則可能遇到下面的報錯：227 Entering Passive Mode先森對windows服務器著實不太熟悉，沒辦法，最后買了一臺Windows服務器按照步驟做測試。僅按照騰訊云文檔及微軟文檔配置，確實會報錯操作超時。最后發現，配置完成之后，還需要在“開始->管理工具->服務”中，找到【Microsoft FTP Service】服務，重啟該服務才能生效：重啟【Microsoft FTP Service】服務    重啟服務后，先森再按照客戶的操作，直接在本地windows資源管理器中鍵入“ftp://公網IP:命令端口”進行測試，訪問正常：測試連接FTP正常比較迷的是，在【FTP 防火墻支持】中，“防火墻的外部 IP 地址”一經設置，立刻生效，但同一個配置地點的被動端口卻要重啟服務才能生效。可能這就像MySQL的配置，有些可以動態生效，有些就必須重啟才能生效。且這些配置都是在IIS管理器里配置的，IIS管理器旁邊也有一個重啟的按鈕：重啟FTP站點這個重啟點了是一點用都沒有，不過溯源來看也可以理解，這畢竟是重啟的站點，而不是服務。比較起來，果然還是Linux比較可愛。

先森之前在騰訊云買了一臺屬于Linux操作系統的CentOS 7.1 64位云服務器，再買了一個.cn的域名，共計一元錢。關于購買的事情先森曾經也發文炫耀過《直播了一段用騰訊云校園計劃1元購買免費域名+專享服務器及安全認證》。雖然4月份就買了云服務器了，但是一直也沒時間折騰，直到六一兒童節騰訊云給我發了一封郵件，我決定不忍了，開始動這臺云服務器。騰訊云恭喜先森畢業了在先森正在為畢業傷感的時候，騰訊云跑來恭喜我畢業了，并且還宣布將不再向先森發送學生特權代金券，這不是火上澆油嗎？為了不讓先森每個月交的1元錢白花，先森決定用這個騰訊云服務器搭建一個WordPress網站。但是沒想到，第一次折騰服務器，連怎么用Xshell連接服務器都搞了很久。整明白后其實還是很簡單，今天將過程整理一下。為什么要用Xshell登錄？主要是因為方便，Xshell可以在Windows界面下用SSH來訪問遠端不同系統下的服務器，從而比較好的達到遠程控制終端的目的。騰訊云服務器的控制臺中其實就有登錄入口，是通過一個網頁來連接服務器的。雖然也比較方便了，但是如果每次去管理服務去還打開瀏覽器，再打開網頁，實在有點麻煩了。騰訊云 云主機 控制臺web登錄在這里可以使用賬號密碼登錄，而在Xshell中是不能用密碼登錄的，因為騰訊云服務器的SSH配置中默認把密碼連接關閉了的。關于賬號密碼在購買云服務器的時候，騰訊云在系統通知和郵件都有做下發提醒：騰訊云服務器的賬號密碼用Xshell連接1.SSH密鑰。在購買服務器的前文中提到過，購買的時候需要提前創建一組SSH密鑰，購買的服務器中就會加載上公鑰，密鑰則是在創建時保存到了自己的電腦上，這個很重要。因為騰訊云默認關閉了SSH密碼連接，所以我們需要使用密鑰連接。SSH密鑰 控制臺2.騰訊云安全組。這個安全在有什么用，先森也沒有具體的了解，只是看其備注，好像要SSH連接就需要開啟的樣子，所以先森就加入云服務器了。備注內容：該安全組將只暴露Linux SSH登錄的tcp 22端口到公網，內網所有端口全通，您的CVM如有業務需要放通其它端口（如80、443等）到公網，建議選擇按需新建的安全組。騰訊云安全組可以測試一下不加入云服務器是否無法連接，無法連接再加入也不遲。3.Xshell連接。首先需要準備的是，在騰訊云控制臺查看自己的公網IP地址，然后確定創建的SSH密鑰在本機的位置。3.1 打開Xshell 5軟件，在左上角點擊新建新建會話3.2 在新建會話的屬性中，名稱自定義，協議選擇SSH，主機填寫公網IP，端口號默認22，其他選項就可以先不用管了。新建會話的屬性3.3 填寫完之后點擊確認，在新彈出來的窗口中選擇創建的會話連接：選擇會話連接3.4 點擊連接后在新的窗口中輸入需要登錄的用戶名，默認一般為root，為了方便以后的登錄，最好勾選記住用戶名：輸入用戶名3.5 輸入用戶名，點擊確認后，會彈出輸入密碼的窗口。但是先森說過多次，騰訊云服務器的SSH服務默認關閉了密碼登錄，所以這時候我們需要用SSH密鑰文件驗證連接。在新的窗口中點擊瀏覽，再選擇用戶密鑰：用戶密鑰然后選擇導入，找到存放在本地的SSH密鑰，確認導入：導入密鑰3.6 導入密鑰之后點擊確定，在密鑰下拉欄中選擇剛才導入的密鑰。為了方便以后登錄，記得勾選右下角的記住密碼。接著直接點擊確認，不用輸入密碼。選擇密鑰3.7 選擇好密鑰確定之后，如果操作無誤就可以連接到服務器了，以后就可以方便的管理服務器了。連接成功總結本文算是顯示真實開始折騰服務器的一個開篇，培訓了那么就的Linux終于也開始正式用于實踐操作了。本文只是做一個記錄，就這個教程而言太過小白了，各位前輩肯定是用不上的，希望能夠幫助到一些比我還白的小白吧。

無意中在中國博客聯盟的群里面直播了一次一元買服務器，還透露了先森免費買了一個.cn的域名，讓群里的博主羨慕有之，鄙視有之。主要是.cn域名和騰訊云主機很多博主瞧不起。但既然都直播了，先森還是發個博文來記錄一下折騰經歷，畢竟是可以得免費域名的。這是什么活動？先森參加的是騰訊云的云+校園計劃，云+校園計劃是騰訊云為在讀高校生量身打造的扶持計劃，旨在為高校生提供先進的技術支持、資金扶持和經驗分享。同時讓更多高校生了解云計算及互聯網知識，為后續職業、創業發展奠定基礎。想參加這個活動，首先你得是在校全日制統招大學生，然后需要完成騰訊云平臺的學生認證。優惠的截止日期就是你學生生涯的結束日期。說到這先森就傷心，要畢業了，55555~下面先森摘抄一下活動內容：【1元云主機-65元服務器代金券】代金券有效期：31天，用戶使用代金券滿65減64元；指定配置：CPU1核、內存1G、帶寬1M、贈送系統盤linux8G/windows50G(每人限買1臺，如超過指定配置，需補齊價)發放規則：通過學生認證后1個工作日內發放首次代金券，按月扶持，每月提前7天自動發放；特別注意：用戶連續90天不繼續使用騰訊云服務(騰訊云域名除外)，將被認為放棄特權，系統不再發放代金券。【免費域名-38元域名代金券】代金券有效期：1年，首次代金券金額38元；指定配置：.cn域名1年，如超過指定配置，需補齊差價；發放規則：通過學生認證后1個工作日內發放首次代金券，按年扶持，每年提前1個月自動發放，每次50元。直播購買域名因為是之前購買的，所以這里就不多說了，反正大家在這把cn當免費域名吧。下面講購買云服務器。選擇云服務器得按照標準來，什么都是最低標準的，1核、1G、1M，沒什么選的，值得注意的是購買之前要創建SSH密鑰，購買的時候要用來選擇。購買騰訊云服務器這也就是按照要求的，最低檔65元/月。不得不說服務器還真貴，65元個一月，相較而言域名的續費都不算啥了。還好，騰訊云會在下個月的前七天發代金券。下面開始付錢。本來65元的東西，結果發現能用優惠券，用了之后Duang的一下變成1元錢，這種體驗真的很好。當然買域名的時候更爽，38元的域名一用代金券錢都不用給了。支付的方式先森選擇了微信支付，畢竟微信錢包里的錢都是搶紅包搶來的，用著不心疼。而且微信提現都要收手續費了，這種時候正是體現微信錢包作用的時候了。微信二維碼掃碼支付微信二維碼掃碼支付先森故意把二維碼發到中國博客聯盟群里面，那群混蛋們果然沒有幫先森支付一波的。最終先森成功的搶在其他人支付前支付成功。這里先森就完成了1元購買cn免費域名+云服務器了，再來曬一波訂單：騰訊云付費訂單希望看到上圖的博主們不要眼紅，是學生就趕緊注冊一波，不是的話...就找親戚家的孩子幫幫忙吧。當然也不要把騰訊云的服務器看的太重，反正先森是準備拿來練手的。最終還是購買了騰訊云的東西，騰訊，你夠狠。下面再來講講關于騰訊云安全認證的事情。騰訊云安全認證可能不了解的朋友還會納悶，什么是騰訊云安全認證？其實對于此，我們應該都不陌生，騰訊云對其解釋一大堆，其實我們看中的僅僅一點：QQ對話框安全鏈接認證展示：也就是在QQ里面發你的網站鏈接的時候，會顯示綠色安全的勾勾。實際上也并無卵用，只為了好看。騰訊云其它的介紹無非就是為其增加賣點。其實先森在接入騰訊云CDN的時候，就談到過騰訊云安全認證的事情。但是那時候也說了，在申請的時候，主營業務選擇框不能彈出選擇，所以申請不了。有時候甚至連申請認證頁面都進入不了，直接跳轉到購買云服務器的頁面，讓你購買之后再訪問。現在先森購買了騰訊云的云服務器了，趕緊去嘗試了一波。結果一看，果然可以選擇主營業務了：騰訊云安全認證主營業務變為可選既然可選，當然要嘗試申請一下，能否成功暫且不說嘛。申請騰訊云安全認證看到提示上說預計3個工作日，想到今天周六，也就打算不管了。沒想到的是，沒過多久，騰訊云發了一封郵件、一條短信，以及站內通知，提示申請結果校驗完畢。申請結果當然是杠杠的失敗！ 申請認證不通過好吧，還是去看看申請不成功的原因，畢竟還是折騰了半天。赤裸裸的結果就是沒有使用騰訊云的主機：未通過騰訊云安全認證原因點擊查看具體原因，就來到了詳細介紹騰訊云安全的頁面，先森還是仔細看了下。發現網站唯一不滿足的條件也是最重要的條件，以及先森不能接受的條件，就在第一條：騰訊云安全認證申請要求既然如此，除非是真心打算好好在騰訊云建站的，其他人就還是別想了吧。QQ聊天窗口的事情就隨他去吧，反正我們的網站主要也不是在QQ上傳播的。另外還有個什么安全聯盟，這里就不多說了。最后說幾句本文中所述活動的重要依托，是有一個全日制大學生的身份。先森作為大學晚期學生，對學校還是有著非常多的不舍的，想著即將畢業，真的有點不甘。所以奉勸各位學生博主們，要做什么就趁著大學期間，趕緊實踐了，不然一錯過可能就是一輩子的事情了。下面對文中提到的一些內容做些傳送門，方便需要之人：【云+校園計劃】 1元=免費域名+專享服務器騰訊云SSH密鑰-控制臺騰訊云安全認證 - 騰訊云平臺一個字，就是干！

先森用了幾天的VeryCloud、騰訊云兩個云服務商的CDN，時間雖短，卻問題不斷。為了不讓自己忘記這些來之不易的經驗，先森覺得把它們寫出來，記下來。當然能幫上人就更好了。除了本篇文章，先森之前還寫了一篇總結，有興趣的也可以去看看：第一篇：VeryCloud、騰訊云CDN使用技巧總結之查看命中緩存情況下面，先森來做新一輪的總結。1.搜索引擎線路解析什么是搜索引擎線路？即專為搜索引擎單獨設置的DNS解析線路。為什么要設置搜索引擎線路？先森主要是在張戈博客接收到了這么一個理念，搜索引擎蜘蛛也許有一個DNS的解析緩存，對你網站解析的IP會保存一段時間，這個時間大概一兩天。而我們使用的CDN是讓訪客訪問就近的服務器節點，每個節點都有單獨的IP，而且這個IP還不是長時間保留的。這就相當于我們的網站經常更換服務器，這樣我們自己都會感覺不好吧，何況是蜘蛛？同時，我們的網站設置CDN后，搜索引擎蜘蛛訪問的也是節點IP，而一旦蜘蛛對這個IP進行緩存，緩存時間大于CDN的IP存在時間的時候，蜘蛛就訪問不了這個IP了。那么蜘蛛就會判定我們的網站存在問題，最終導致SEO受到傷害。大概就是這么一個觀點，詳細的內容還請大家去看看張戈博客的原文：淺析網站更換ip或使用CDN會不會影響SEO排名而解決或者說不產生上面的問題的方法，就是設置搜索引擎線路。雖然張戈已經說得很清楚了，如何設置搜索引擎線路，但還是有很多站長在問設置問題。包括先森自己，也是研究了一下，才想明白該如何設置。首先，奉勸和我之前一樣，一直使用萬網域名解析的，趕緊換換吧。下面再次簡單講講先森的經歷。萬網解析只支持百度、谷歌、必應三家的搜索引擎線路，重點是解析的還不準確。不，是非常不準確。先森用百度抓取診斷，該抓取CDN節點IP的還是抓取，設置和沒設置完全沒有什么兩樣。萬網設置搜索引擎線路后的百度抓取診斷百度抓取的IP實為騰訊云的CDN節點IP問張戈博客的張哥，張哥給我兩個解決辦法，一是換DNSPod解析，二是使用百度云加速，因為云加速有自動的搜索引擎回源。先森因為才開始使用VeryCloud不久，還想再研究研究，就選擇了使用DNSPod的方法。關于如何將域名解析從萬網轉移到DNSPod，先森也分享過方法，因為DNSPod的方法有點老舊了：將萬網/阿里云域名DNS地址修改到DNSPod如何設置搜索引擎線路？首先新增一個解析記錄，然后開始設置。主機記錄：根據需求，如果直接解析域名，填“@”；域名、二級域名都要解析，填“*”；只解析一個二級域名，填二級域名的值，如“www”。先森就只解析www的。記錄類型：選擇A記錄。線路類型：DNSPod支持百度、谷歌、必應、搜搜、搜狗、奇虎，和相當于默認搜索引擎線路的“搜索引擎”。先森是每個搜索引擎線路都單獨設置了一條A記錄。記錄值：這里就設置自己源站服務器IP，即真實IP，要小心，不要泄露。其他各項就根據自己的需求設置了。下面貼出先森的設置情況：DNSPod搜索引擎線路設置設置之后，先森立馬到百度站長工具去抓取診斷，秒秒鐘虐了萬網：抓取IP為源站IP2.詳讀“常見問題”這一點，就是讓大家去仔仔細細的將VeryCloud、騰訊云的“常見問題”看完，這樣能使我們少走很多彎路。這也是先森在問了售后很多問題之后發現的，有很多問題，都已經寫入“常見問題”中了，相信售后的心是崩潰的。其實說到底，就是多讀、多看、多想。兩個CDN服務商都有常見問題頁面，但是先森覺得VeryCloud的常見問題比較偏原理解釋，重點介紹了什么是CDN、CDN如何工作、CDN的優勢、什么是緩存命中率等等：VeryCloud常見問題其實VeryCloud的話，大家更應該點擊上圖紅框中的云分發，看更多更有針對性的解決問題方法。單頁不能忽視這一頁15個常見問題的作用，這些基礎知識能讓我們對CDN更加了解。更多詳情就希望大家自己查看了：VeryCloud云分發-使用幫助VeryCloud常見問題而騰訊云的常見問題頁面，則做的更加細致，問題更加全面，也有著很好的針對性。騰訊云對自家服務進行了介紹，其中有優勢，有原理，有功能。從基礎介紹，接入相關，日常使用，問題排查四個方面回答問題，顯得簡單明了。其中就有如何判斷用戶訪問是否命中CDN cache、接入cdn之后網站打不開，如何排查、命中率低是什么原因呢等經典問題，這些問題有很多都是現在自己搞了很久才弄明白的，沒想到這里就很清楚的寫著：騰訊云常見問題在這里，先森也把騰訊云的相關鏈接貼出來，騰訊云還有一個內容分發網絡的幫助文檔，文檔中包含以上內容，查看卻沒有以上內容方便，但先森還是一并貼出來：騰訊云CDN常見問題騰訊云內容分發網絡常見問題騰訊云內容分發網絡CDN論壇騰訊云還介紹了一個可以管理查看CDN中緩存文件軟件SVN的使用方法，但是騰訊云卻沒有使用SVN源了，讓我們使用他們的對象儲存業務COS。3.查看日志不管是VeryCloud還是騰訊云，都支持查看日志。但是他們的日志下載之后，打開顯得非常凌亂，雖然很詳細，但遠不如直接在網站上查看統計分析來的簡單明了。主要還是，關于CDN日志，他們都沒有提供什么統計分析軟件。不過先森覺得，查看日志主要也是排查問題的，很具有針對性。簡單的來說，騰訊云統計里可以看到訪問返回碼，我們可以看到產生了多少次的404，但是看不到是哪些頁面出現了404，這時候就需要查看日志了。先森問了騰訊云的售后，售后推薦使用notepad++，sublime兩款軟件。日志的內容顯得很亂，但都是每行一條，每條里面有很多數據，這些數據是按照順序來的。VeryCloud日志：例：12.243.121.90 - - [24/Mar/2015:12:42:18 +0800] "GET http://www.verycloud.cn/usr/uploads/201503/20150302100356_29670.flv  HTTP/1.1" 200 1933334 "http://portal.verycloud.cn/galileo/20150306/8ad1637dbf7cd191f1fe728fc18658d9.swf" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36" TCP_MEM_HIT 0.947 58.22.102.229字段參數客戶端真實ip12.243.121.90請求時間24/Mar/2015:12:42:18方法GETURLhttp://www.verycloud.cn/usr/uploads/201503/20150302100356_29670.flvhttpversionHTTP/1.1狀態碼200請求字節1933334Refererhttp://portal.verycloud.cn/galileo/20150306/8ad1637dbf7cd191f1fe728fc18658d9.swfUAMozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36結果TCP_MEM_HIT處理請求時間0.947節點IP58.22.102.229騰訊云日志：拿先森自己網站的日志中的一行作為例子：20160407104007 180.97.171.210 www.cnidcc.cn /qzcdnhcjszjrtxy.html 12276 120 2 200 NULL 1 "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0"字段參數請求時間20160407104007訪問域名的客戶端IP180.97.171.210被訪問域名www.cnidcc.cn文件請求路徑/qzcdnhcjszjrtxy.html本次訪問字節數大小12276省份120運營商2http返回碼200referer信息NULLrequest-time(毫秒)1User-Agent"Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0"關于省份和運營商代碼所代表的含義，還需要我們去查看騰訊云的映射表查看地域及運營商編碼映射表注：Referer信息，保存的是訪問該網頁是從哪個頁面鏈接過來的，我們統計搜索引擎跳轉，就是用的這個信息。4.文件刷新使用CDN有一個很大的問題，就是動態數據的顯示問題。最容易涉及到的，就是文章的訪問量，以及最新評論的問題。關于訪問量，無傷大雅，只要設置緩存策略的時候緩存時間設短一些就還好。至于文章的最新評論，就有點不好了。別人在你的網站上留了言，明明通過審核了，卻還是顯示之前的頁面，最新的評論就沒有顯示出來。這時候我們再去手動的刷新緩存的話，就會比較麻煩。所以，我們就需要用到刷新緩存的API了。我們使用API，實現當頁面增加了評論的時候，刷新該頁面。具體的使用方法是將一些代碼放入WordPress主題functions.php文件中即可，代碼是張戈博客提供的，需要的小伙伴可以去看看：VeryCloud：WordPress發布/更新文章、提交/審核評論自動清理VeryCloud緩存騰訊云：WordPress發布/更新文章、提交/審核評論自動清理騰訊云CDN緩存另外，VeryCloud的API，是不對外開放的，向售后工程師申請的時候，也要保證自己網站帶寬夠大，才能申請成功。售后工程師給先森的回復是要達到20M的帶寬，這對張戈博客當然不成問題，但是對我們這些小站來說，差的太遠。雖然有小伙伴在先森交《全站CDN緩存加速之接入VeryCloud》一文中回復說，VeryCloud開放了API接口，但先森查看之后發現，實際還是需要讓你想客服索要API。總結回顧一下，本文主要介紹了如何設置搜索引擎解析線路，通過詳讀“常見問題”來少走彎路，如何查看VeryCloud的日志，日志內容的參數含義，以及如何用API接口來實現刷新緩存。現在就總結這些，如果以后還有什么好的經驗，先森還會默默的更新的。