由於官網的網域名稱跳轉是在阿里雲的網域名稱解析的地方配置的，於是就登陸到阿里雲的網域名稱解析地方，檢視了一下發現，這裡的配置是www.lechange.com 會302跳轉到 home.lechange.com，而ping一下home.lechange.com ping得到的ip位址是乙個負載均衡的位址，然後在阿里雲的控制台查詢這個負載均衡的情況，發現這個負載均衡後面掛載的是兩台伺服器a和b。
於是我在瀏覽器裡面直接輸入負載均衡的ip位址，發現還是像上面那樣錯誤的php介面，而瀏覽器位址列使用兩個伺服器的外網ip卻是正常可以開啟的。這個時候初步懷疑是slb的問題，而我當時就覺得就憑上面這一點就去跟阿里撕逼不太妥當，但是事實告訴我們事情不是那麼簡單的。
我檢查一下slb的埠配置情況，分別是http 80轉8080和https 443轉80，可見這個**有兩個協議，乙個是http的而乙個是https的，我們剛才雖然在瀏覽器裡直接使用a和b的外網ip訪問是可以正常開啟頁面，只能說明http協議是ok的，我們還要測試一下https協議訪問的效果。
我就在瀏覽器位址列裡進一步嘗試，發現a外網ip：8080 是ok的，而b外網ip：8080 就是php的文字介面。於是基本問題定位到b伺服器裡有檔案的配置錯誤。
登陸到b伺服器裡，在nginx的conf資料夾裡發現乙個多餘的檔案，開啟內容如下：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
server
location/public
access_log/data/logs/nginx/access.log;
#access_log off;
}
而原來nginx是有正常的conf檔案，現在又多餘了乙個這個檔案，可見是兩個檔案都在占用8080埠時出現了衝突，所以就導致這樣php介面的情況。刪除這個多餘的檔案後，重啟nginx，清除瀏覽器快取，再重新嘗試就正常開啟頁面了。
為什麼會多乙個這樣的檔案，後來把各位運維人員嚴刑拷打一頓才知道，原來有一次某運維小弟在b伺服器裡面做跳轉的測試，測試完畢之後忘記了把這個多餘的檔案刪除，原本這一切是沒有問題的，但是可能伺服器nginx經歷了重啟，於是就載入了這兩個conf檔案，就把這個隱藏的問題暴露了。
一次佈線的經歷
一次佈線的經歷 由於公司要重sz搬遷到sd，sd區需要裝修整改，重新佈線。專案開始2012年10月份入職就開始入手 左邊是工廠區 辦公區 凹字形結構 共4層樓，是拼接房大部分是翻新，只有 內凹部分那裡新建 www.2cto.com 專案結束標誌以機房的ups，機房機架上的監控 伺服器 交換機，除錯完...
一次安裝fedora linux的經歷
2個星期前吧,用pqmagic分了下區,結果重起後,系統就進不去了，估計是pqmagic破壞我的硬碟分割槽表。之前一直是聽別人說 pqmagic會破壞系統，今天算是讓我碰到了。在網上找了些資料，重新來恢復我的grub。root 和setup命令是重新來安裝 引導的，如root hd0,hda1 se...
一次重組程式的經歷
整整費了n久功夫,終於重組好了畢設程式的構架,頭暈暈的,簡單敘述一下改寫的經過,分享一下自己的感受,順便自勉也整理一下思路o o 系統環境 redhat 9.0 開發語言 c 編譯器 gcc 原來程式包含的檔案 sniff.h,sniff.c,tp.c,main.c makefile檔案內容 cc ...