記錄一次 docker：Primary script unknown" while reading response header from upstream
這個問題簡單翻譯過來就是：
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
這行配置無法幫我找到 傳過來的檔案。試了一下寫一個 index.html 檔案進行測試，發現是有的。然而，index.php就不行。
這要是在以往的無docker時代，檔案目錄不用掛載來掛載去的，就不容易出現這種問題。於是檢查了一下docker 配置，發現在php-fpm容器把相對應的檔案目錄掛載進去以後就解決問題了。
差點被網友誤導，說是啟動php-fpm的使用者和nginx的使用者不一致導致。這樣讓我很容易產生一種錯覺：我應該將nginx和fpm放在同一個容器裡。
相關推薦
記錄一次 docker：Primary script unknown" while reading response header from upstream
這個問題簡單翻譯過來就是： fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; 這行配置無法幫我找到 傳過來的檔案。試了一下寫一個 index.html 檔案進行測試，發現是有的。
FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream 問題解決
配置好了 nginx.conf 和 php7.0-fpm.conf 檔案，但是要訪問 php 檔案的時候，卻不顯示任何內容或者顯示“File not found”，問題在於要訪問的 php 檔案 php7.0-fpm 沒有訪問許可權，修改下訪問許可權即可。 改成如下圖所
FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream 問題解決
配置好了 nginx.conf 和 php7.0-fpm.conf 檔案，但是要訪問 php 檔案的時候，卻不顯示任何內容或者顯示“File not found”，問題在於要訪問的 php 檔案 php7.0-fpm 沒有訪問許可權，修改下訪問許可權即可。 改成如下圖所示： 附
graphite報錯：upstream prematurely closed connection while reading response header from upstream
線上監控系統使用grafana+graphite，graphite使用nginx+uwsgi啟動。有一次在grafana上監控圖出現錯誤，顯示響應式502，於是先檢查graphite-web，發現在graphite-web介面上偶爾打不開。 然後再nginx的error日誌上顯示如下資訊：
修復Nginx 502錯誤：upstream sent too big header while reading response header from upstream
最近發現Nginx+Laravel 搭建的網站搜尋某些關鍵字時返回502錯誤。 查了一下Nginx的錯誤日誌，發現如下錯誤 2015/03/19 10:46:40 [error] 6412#0: *16436265 upstream sent too big header
記錄一次網站漏洞修復過程(三)：第二輪處理（攔截SQL註入、跨站腳本攻擊XSS）
cat nbsp ebe 嵌入 網頁 防止 記錄 用戶輸入 light 在程序編寫的時候采用參數化的SQL語句可以有效的防止SQL註入，但是當程序一旦成型，再去修改大量的數據庫執行語句並不是太現實，對網頁表單上輸入進行校驗是易於實現的方法。在webForm 頁面中開啟校驗屬
多線程系列七：記錄一次學習項目性能優化的過程及心得
安全問題 ota except dex 等等 exception family print 單個 一、項目背景和問題 有一個自適應的考試學習系統，對學員的學習要求經常考試進行檢查，學員的成績出來以後，老師會要求系統根據每個學員的考卷上錯誤的題目從容量為10萬左右的題庫中抽取
Python+Selenium自動化模擬用戶登錄(備註：記錄一次強行卸載rpm依賴包，引發的rpm、yum等命令異常，無法遠程xftp工具)
支持 fir 遠程 margin pan ~~ dep sta aliyun 近期在摸索Python+Selenium自動化，實現模擬用戶登錄搜索等操作，反饋相關日誌，再交由Zabbix分析，監控頁面訪問是否正常。 期間需要對Linux火狐瀏
測試PHP是否安裝成功時,nginx報錯："Primary script unknown"
stderr php pri index known req tde stc 參數 小生博客：http://xsboke.blog.51cto.com 小生 Q Q：1770058260-------謝謝您的參考，如有疑問，歡迎交流 環境php-5.6.36nginx-
記錄一次 .Net 框架 Bug 發現和提交過程：SmtpClient一處程式碼編寫錯誤導致非同步傳送郵件時DeliveryFormat配置項無法正確工作
問題已經發到了開發者社群 developercommunity.visualstudio.com/content/pro… 涉及到的Github倉庫： github.com/xiangyuecn/… .Net開發者社群富文字編輯器太難用了，還是簡書的編輯器好用，然後掘金的版面好看，最後還是喜歡cnb
spark2.2.0：記錄一次資料傾斜的解決（擴容join）！
前言： 資料傾斜，一個在大資料處理中很常見的名詞，經由前人總結，現已有不少資料傾斜的解決方案（而且會發現大資料的不同框架的資料傾斜解決思想是一致的，只是實現方法不同），本文重點記錄這次遇到spark處理資料中的傾斜問題。 老話： 菜雞一隻，本人會對文中的結論負責，如果有說錯的，還請各位批評指出
記錄一次SpringClooud restTemplate java.net.UnknownHostException：XXserver 問題
restTemplate出現 java.net.UnknownHostException：XXserver ，寫服務名找不到eureka對應的服務地址， 網上的解決方案，在Application啟動類這樣寫： @Bean @LoadBalanced
記錄一次svn報錯：[Previous operation has not finished; run 'cleanup' if it was interrupted] 的排錯過程
前言：由於目前客戶習慣使用SVN管理程式碼，所以仍在使用SVN做程式碼管理，管理方式雖然落伍，但客戶粑粑就是上帝~~ 今天在改完十幾個類檔案批量提交時，在程式碼提交SVN伺服器過程中，電腦突然性卡死一大會沒有反應，果斷採取關閉然後重啟開發工具的方
記錄一次.Net框架Bug發現和提交過程：.Net Framework和.Net Core均受影響
SmtpClient一處程式碼編寫錯誤導致非同步傳送郵件時DeliveryFormat配置項無法正確工作，非同步操作已經完全不受我們設定屬性控制了，UTF-8內容（如中文）轉不轉碼完全看對方郵件伺服器心情！ .Net開發者社群富文字編輯器太難用了，還是簡書的編輯器好用，然後掘金的版面好看，最後還是喜歡c
硬體運維：記錄一次被伺服器電源模組坑成狗的案例
事由 今天開始，逐步把硬體運維過程中遇到的坑整理成公眾號文章，以便踩到坑的人共勉，也給還沒踩到坑的人一個提醒。至於這款電源模組，反正我已經被這款電源模組（這裡說的艾默生電源PH-79RDR指的是DELL PC伺服器使用的電源模組）坑過N回了，總體總結成3類問題 問題1 ：PH-79RDR在低版
記錄一次“記錄超長”
har 語句 類型 執行 如果 可能 事情 縮小 百度 Jdbc報錯“記錄超長”，百度一下推測可能是因為SQL過長導致；但是後來經過老杜指點，發現原來是因為字段（varchar 8000）超長導致； 解決問題的套路： 1. 首先在Sql的客戶端上執行代碼；如果不錯，說明還是
[邏輯漏洞]記錄一次挖洞
9.png 列表 一次 查詢 urn 找到 ima sting .com 陽光明媚的早上，turn on the PC and 隨意地瀏覽著以往漏洞列表，希望在裏面找到一些遺忘的痕跡。 果然，我發現一個被忽略的漏洞，一個暴露在外網的的一個接口，可以查詢該企業網站是否註冊了的
簡單記錄一次REDO文件損壞報錯 ORA-00333重做日誌讀取塊出錯
clas 後者 利用 實例恢復 poi cancel true cover html 一.故障描寫敘述 首先是實例恢復須要用到的REDO文件損壞 二、解決方法 1.對於非當前REDO或者當前REDO可是無活動事務使用下面CLEAR命令： 用CLEAR命令重建該日誌
記錄一次配置http跳轉https的過程
http https 網站跳轉 公司最近搞了一個數據運營平臺，這個平臺會以web界面的形式把各個數據展示出來，這個項目是我們一個經理的重點關照項目。把平臺模塊部署完畢並且啟動之後，又把這個平臺服務器的外網IP綁定到alkaid.lechange.com這個域名上，在瀏覽器裏輸入https://al
記錄一次concurrent mode failure問題排查過程以及解決思路
tails only cnblogs 策略 executor red execute incr run 背景：後臺定時任務腳本每天淩晨5點30會執行一個批量掃庫做業務的邏輯。 gc錯誤日誌： 2017-07-05T05:30:54.408+0800: 518534