今天明月碰到了一次 Nginx 的「500 Internal Server Error」故障,依慣例必須發文水一篇,算是一次記錄吧!最後排查出來的故障原因雖然很奇葩但也算是一次經驗積累了,所以也可以當做一次經驗分享給大家。
今天下午抽時間研究了一下 Nginx 的 Lua 模塊 ngx_lua_waf 防火牆的規則文件,想著看看在不使用 CSP 規則的情況下完全依賴 ngx_lua_waf 提升一下屏蔽效能,理論上這些操作是不會影響到 Nginx 的正常運行的,並且每次需要重啟 Nginx 服務的時候都要通過nginx -t命令來檢查驗證配置無誤的(有關 ngx_lua_waf 可參考『LNMP 1.5 測試版體驗之 ngx_lua_waf 初體驗!』一文)。沒有想到就是這個驗證配置無誤的疏忽造成了伺服器長達半個小時的「500 Internal Server Error」錯誤狀態。
剛開始明月都還沒有發覺出現 500 錯誤了,還在 QQ 群好友的提醒下才知道的,這時候發現這個伺服器上所有的站點都是「500 Internal Server Error」錯誤狀態了,無論是重啟 Nginx、重啟 LNMP 甚至重啟伺服器後重新編譯 Nginx 都無濟於事,所有的站點都是「500 Internal Server Error」錯誤狀態,無論是 WordPress、Typecho 還是 Hexo 博客都是這樣,很明顯問題出在 Nginx 上,可以是 Nginx 的配置以及站點配置文件都排查了沒有任何問題,Nginx 的 error.log 裡也是沒有任何有價值的提示線索。理論上來說「500 Internal Server Error」錯誤狀態就是指 Web 伺服器內部錯誤,所以 Nginx 這個鍋必須背了,但就是不知道問題出在哪裡了?
說實話,隨著時間的推移明月有點兒「急」了,眼看快下班了都,故障原因竟然都找不到,鬱悶呀!強迫自己回憶了一下自己在控制臺終端的最後一次修改配置的文件應該是編輯保存了一下/usr/local/nginx/conf/waf/waf.lua 文件,雖然記得是沒有動過任何字符,但最後用 Vim 打開這個文件的時候是使用:wq退出的 Vim 的,難道問題出在這裡?Nginx 的 nginx.conf 文件裡倒是確實有引用到這個文件,還是通配符式的引用,在『LNMP 1.5 測試版體驗之 ngx_lua_waf 初體驗!』一文裡可以知道這是為了給 Nginx 部署 ngx_lua_waf 防火牆的,於是打開/usr/local/nginx/conf/waf/waf.lua 文件仔細的查看下發現是Vim 操作的時候不小心碰到回車鍵讓首行的"local ……」弄成「ocal ……」了,修復這個誤操作保存退出,Nginx 的「500 Internal Server Error」消失了,所有的站點都恢復正常了。
問題解決了,事後分析竟然是 Nginx 並不支持 Lua 模塊.lua 文件的語法錯誤的輸出提示,nginx -t檢查更是不會涉及到引用的.lua 文件,自然也就不會提示配置文件有問題了,可以說這個「坑」要不是明月回憶起最後的操作還真的不易發現,唉!真是一次小小的失誤就會造成一個不小的「坑」呀!
謝謝支持!