一個請求在 PHP 裡經過的階段

PHP 的執行分成兩層生命週期：程序層與請求層。程序層的工作每個程序只做一次，請求層的工作每個請求都做一次。

請求結束那一步的範圍很大：全域變數、函式內的 static 變數、類別的靜態屬性、開過的檔案與一般的資料庫連線，全部在這一步釋放。下一個請求就算由同一個程序處理，也看不到上一個請求留下的任何 PHP 變數。這個設計叫 shared-nothing：請求之間不共享應用程式的狀態，每個請求從空白開始（見 Shared-nothing 請求模型）。

這件事可以直接量。下面這支腳本每次執行都把函式內的 static 變數與一個全域變數加一，並印出處理它的程序編號：

1<?php
2function counter() { static $n = 0; return ++$n; }
3$GLOBALS['g'] = ($GLOBALS['g'] ?? 0) + 1;
4echo "pid=", getmypid(), " static=", counter(), " global=", $GLOBALS['g'], " sapi=", PHP_SAPI, "\n";

在 Nginx 加 PHP-FPM 的環境連續請求四次，輸出是：

1pid=7 static=1 global=1 sapi=fpm-fcgi
2pid=6 static=1 global=1 sapi=fpm-fcgi
3pid=7 static=1 global=1 sapi=fpm-fcgi
4pid=6 static=1 global=1 sapi=fpm-fcgi

兩個程序（PID 6 與 7）輪流處理請求，同一個程序處理第二次時，兩個計數器仍然是 1。程序活了下來，PHP 變數沒有。

請求結束後留在程序裡的資源

請求結束只清掉 PHP 程式碼建立的變數，程序本身持有的資源可以跨請求存在，而且只有程序活得夠久時才有意義：

• OPcache：把編譯好的 opcode 存在共享記憶體裡，下一個請求不必重新編譯同一個檔案。它的效果完全取決於程序活多久，在 OPcache 與程序壽命 展開。
• 持久連線：PDO 開了 PDO::ATTR_PERSISTENT 的資料庫連線，請求結束時不關閉，留給同一個程序的下一個請求重用。
• APCu 這類記憶體快取擴充：資料放在程序（或程序群共用）的記憶體裡，請求結束不清除。

所以 shared-nothing 的精確範圍是「PHP 程式碼建立的狀態」。程序層的資源由程序壽命決定，而程序壽命由下一節的 SAPI 決定。

SAPI：PHP 直譯器與外部環境之間的介面

SAPI（Server API）是 PHP 核心與外部環境之間的一層。PHP 的直譯器本身不知道請求從哪裡來：它可能被命令列啟動、被 web 伺服器 fork 出來、被嵌在 Apache 裡、或在一個常駐的伺服器裡被呼叫。SAPI 負責兩件事：把外部環境帶來的請求翻譯成 PHP 認得的形式（填好 $_SERVER、$_GET，把請求內容交給 php://input），以及把 PHP 的輸出與回應標頭交回外部環境。同一份 PHP 核心配上不同的 SAPI，就是不同的執行方式（見 SAPI）。

程式裡可以用 PHP_SAPI 常數（或 php_sapi_name()）讀到目前的 SAPI 名稱。上一節的輸出裡 sapi=fpm-fcgi 就是這個值。實測過的幾種：

cgi-fcgi 這個名字反映了一件事：php-cgi 同一支程式能以兩種協定運作。CGI 與 FastCGI 是兩個不同的協定，FastCGI 沿用 CGI 傳遞請求資訊的那套參數名稱，改掉的是程序壽命。被 web 伺服器以 CGI 執行時，php-cgi 處理完一個請求就結束；以 FastCGI 模式啟動時，它常駐下來接收多個請求。兩者的差別在 CGI 與 FastCGI 兩篇分別說明。

比較執行模型的三個問題

SAPI 的種類很多，而它們之間的差異可以歸到三個問題上。每一種執行模型對這三個問題各有一組答案，後面的行為差異幾乎都從這組答案推得出來。

直譯器住在哪裡。 PHP 直譯器可能住在 web 伺服器自己的程序裡（mod_php），也可能住在另一個獨立的程序裡（CGI、PHP-FPM），或住在某個程序的執行緒裡（FrankenPHP）。住在 web 伺服器外面時，web 伺服器與 PHP 之間需要一種溝通方式，CGI 與 FastCGI 就是這種方式。這也決定了誰對外講 HTTP：直譯器住在 web 伺服器外面時，PHP 這一側只收得到 web 伺服器翻譯過的請求。

執行它的程序活多久。 程序可能只活一個請求（CGI），也可能活過成千上萬個請求（mod_php、PHP-FPM、FrankenPHP）。程序活得越久，程序層的工作（讀設定、載入擴充）攤在越多請求上，OPcache 這類程序層的快取也才有編譯結果可以重用。

應用程式的狀態活多久。 在 shared-nothing 的模型裡，狀態只活一個請求，框架每個請求都要重新啟動一次：載入設定、註冊服務、建立路由表。常駐 worker 模式（FrankenPHP 的 worker 模式、Laravel Octane）讓應用程式啟動一次後留在記憶體裡，狀態活過很多個請求，省下每次重新啟動框架的成本，代價是上一個請求留下的變數與物件會被下一個請求看到：放在靜態屬性裡的「目前登入的使用者」會被下一個使用者的請求讀到，每個請求往靜態陣列加資料的程式會讓記憶體隨請求數一路增長。

這張表裡最容易混在一起的是程序壽命與應用程式狀態壽命這兩欄，而它們是兩件獨立的事：FrankenPHP 的傳統模式只有一個程序、而且一直不結束，同一支計數腳本在它上面跑三次，三次的 PID 都是 1、計數器三次都是 1；換成 worker 模式，PID 仍然是 1，計數器變成 1、2、3、4。程序一樣常駐，差在 PHP 有沒有在請求之間清空狀態。

三個問題各自展開的位置

這個模型的三個問題，每換掉一個答案就走到另一種執行模型：

• 把直譯器放在每個請求新啟動的程序裡，就是 CGI：最簡單的隔離，每個請求付一次啟動 PHP 的成本。
• 把直譯器放進 web 伺服器的程序裡，就是 mod_php：省掉啟動成本，代價是 web 伺服器的每個程序都帶著整個 PHP，包括只負責送圖片的那些。
• 把直譯器放在 web 伺服器外面、讓程序常駐，需要一個讓兩邊溝通的協定，就是 FastCGI；管理那群常駐程序的實作是 PHP-FPM。
• 讓程序活得更久對效能的意義集中在 OPcache：程序壽命從一個請求變成很多個請求時，被重用的是什麼。
• 讓應用程式的狀態也活過很多請求，就是 常駐 worker 模型：框架只啟動一次，同時失去 shared-nothing 的隔離。

CGI 怎麼把請求交給外部程式

CGI 是 web 伺服器呼叫外部程式來產生回應的介面，規格寫成 RFC 3875（CGI/1.1），RFC 自己記載這個介面從 1993 年起就在 web 上使用。它跟語言無關：被呼叫的可以是 Perl、C、shell script 或 PHP，早期網站的 cgi-bin/ 目錄放的就是這類程式（見 CGI）。

一個請求經過 CGI 的過程：

RFC 3875 把這些環境變數叫做 meta-variables。PHP 的 $_SERVER 陣列裡那些大寫的鍵（REQUEST_METHOD、QUERY_STRING、SCRIPT_FILENAME）就是從這裡來的，後來的 FastCGI 與 PHP-FPM 沿用了同一套名稱。

PHP 以 CGI 執行時的行為

PHP 提供一支叫 php-cgi 的程式給 CGI 使用，官方的 PHP Docker 映像檔（php:8.5-cli）裡就有。下面用 lighttpd 當 web 伺服器，設定所有 .php 結尾的請求都交給 php-cgi 執行：

1# lighttpd.conf
2server.document-root = "/var/www/html"
3server.modules = ( "mod_cgi" )
4# 副檔名對應到要執行的程式：每個 .php 請求都啟動一個 php-cgi 程序
5cgi.assign = ( ".php" => "/usr/local/bin/php-cgi" )

server.document-root 是網站檔案所在的目錄，cgi.assign 的右邊是 php-cgi 在這個環境裡的實際路徑，換到別的系統要用 which php-cgi 查。對一支印出程序編號與計數器的腳本（腳本內容見 PHP 的請求生命週期與 SAPI）連續請求四次：

1pid=15 static=1 global=1 sapi=cgi-fcgi
2pid=16 static=1 global=1 sapi=cgi-fcgi
3pid=17 static=1 global=1 sapi=cgi-fcgi
4pid=18 static=1 global=1 sapi=cgi-fcgi

每個請求都是一個新的程序。PHP 的兩層生命週期在這裡疊成一層：模組啟動（讀 php.ini、初始化所有擴充）與請求啟動每個請求都各做一次，請求結束時程序也跟著結束。

每個請求付出的啟動成本

在同一台電腦、同一支極小的腳本上，循序送 300 個請求，CGI 每個請求的平均時間大約是 PHP-FPM 的七倍（一次量測：8.7 ms 對 1.3 ms）。腳本本身幾乎不花時間，差距來自 CGI 每個請求都要做的事：作業系統建立一個新程序、載入 PHP 的執行檔與共用函式庫、讀設定、初始化每一個擴充。PHP-FPM 的 worker 是常駐的，這些工作在 worker 啟動時做過一次就不再重複。

確切的倍數隨機器、載入的擴充數量與腳本大小變動，值得帶走的是成本的位置：CGI 的固定成本落在每一個請求上，常駐程序把它攤到很多個請求上。

OPcache 在 CGI 下沒有作用

OPcache 把 PHP 檔案編譯好的 opcode 存在共享記憶體裡，讓之後的請求跳過編譯。它的共享記憶體屬於啟動它的那個程序，程序結束，快取就跟著消失。在 CGI 下印出 OPcache 的統計：

1pid=19 opcache_enabled=true cached_scripts=1 hits=0
2pid=20 opcache_enabled=true cached_scripts=1 hits=0
3pid=21 opcache_enabled=true cached_scripts=1 hits=0

OPcache 是開著的，每個程序也把腳本編譯進了快取（cached_scripts=1），可是命中次數永遠是 0：下一個請求是新程序，拿到的是一份全新、空白的快取。框架每個請求要載入數百個檔案，這些檔案在 CGI 下每次都要重新編譯。OPcache 與程序壽命的關係在 OPcache 與程序壽命 展開。

CGI 在共享主機上留下來的理由

CGI 的成本這麼高，它在共享主機上用了很久，理由是隔離。每個請求都是一個獨立的程序，所以 web 伺服器可以用不同的使用者身分啟動它。Apache 的 suEXEC 讓 CGI 程式以站台擁有者的帳號執行，而不是 Apache 自己的帳號：

• 站台之間互相看不到檔案：A 站的 PHP 以 A 的帳號執行，讀不到 B 站的設定檔與資料庫密碼。
• 檔案權限對得上：PHP 上傳或產生的檔案屬於站台擁有者，透過 FTP 登入的同一個帳號能修改與刪除它們。
• 一個請求出錯只影響那一個程序：記憶體洩漏或當掉都隨程序結束而消失。

這組需求是 mod_php 在 Apache 官方的 MPM 下做不到的：mod_php 的 PHP 住在 Apache 的程序裡，所有站台都以同一個帳號執行。後來 PHP-FPM 用 pool（每個站台一組 worker、各自指定執行帳號）在常駐程序上做到同樣的隔離，共享主機才有理由離開 CGI。

請求資料與程式呼叫參數之間的邊界

CGI 用啟動一支程式的方式處理請求，所以請求的內容有機會被當成「啟動程式的方式」解讀。PHP 在這個邊界上出過一個嚴重的漏洞：CVE-2012-1823。依 NVD 的公告，PHP 5.3.12 與 5.4.2 之前，php-cgi 以 CGI 方式執行時沒有正確處理不含 = 的查詢字串，使查詢字串的內容可能被當成 php-cgi 的命令列選項，進而導致遠端執行程式碼。修正方式是升級到修補過的版本，而這個類型的問題只出現在 PHP 以 CGI 程式被呼叫的部署上。

這類問題在 FastCGI 下不存在同樣的形式：FastCGI 的 PHP 程序早就啟動好了，請求資料走的是協定裡的參數，不會變成程序的啟動參數。PHP 端還有兩個跟 CGI 有關的設定一直保留到今天，cgi.force_redirect 與 cgi.fix_pathinfo，其中 cgi.fix_pathinfo 在 FastCGI 環境仍然影響安全，在 FastCGI 說明。

CGI 在今天的位置

新部署很少用 CGI 執行 PHP，原因是前面量到的兩件事：每個請求的啟動成本，以及 OPcache 沒有作用。它仍然出現在兩種地方：一些舊的共享主機，以及只需要偶爾執行一支腳本、不值得常駐一個程序的場合。

CGI 的設計有兩項比它本身活得久：環境變數形式的請求資訊（$_SERVER 的鍵名）、「web 伺服器負責 HTTP、外部程式負責產生內容」的分工，都被 FastCGI 原樣繼承。FastCGI 改掉的只有一件事：程序不再每個請求結束，見 FastCGI。

PHP 以 Apache 模組的形式載入

mod_php 是編譯成 Apache 模組的 PHP（Debian 系的套件裡檔名是 libphp.so 一類），Apache 啟動時用 LoadModule 把它載入，它的 SAPI 名稱是 apache2handler（見 mod_php）。載入之後，Apache 的每個子程序裡都有一份完整的 PHP 直譯器，收到 .php 的請求時在自己的程序裡直接執行，不經過任何程序之間的溝通。

這個做法省掉了 CGI 每個請求都要啟動一個新程序的成本：子程序處理完一個請求之後留下來，接著處理下一個。在 php:8.5-apache 上對同一支計數腳本送 10 個請求，請求平均落在 5 個子程序上，每個處理兩次：

1   2 pid=16 static=1 global=1 sapi=apache2handler
2   2 pid=17 static=1 global=1 sapi=apache2handler
3   2 pid=18 static=1 global=1 sapi=apache2handler
4   2 pid=19 static=1 global=1 sapi=apache2handler
5   2 pid=20 static=1 global=1 sapi=apache2handler

子程序被重複使用，static 與全域變數仍然每次從 1 開始：程序活下來了，PHP 依舊在每個請求結束時清空應用程式的狀態。

mod_php 要搭配 prefork MPM

Apache 處理並發的方式由 MPM（Multi-Processing Module）決定，常見的有三種（見 Apache MPM）：

PHP 官方的安裝文件寫明：除非 PHP 以執行緒安全（--enable-zts）編譯，mod_php 只能搭配 prefork MPM，而這「significantly limits concurrency」。原因在 PHP 的實作：沒有開啟 ZTS（Zend Thread Safety）的 PHP 把每個請求的狀態放在全域變數裡，兩個執行緒同時執行 PHP 會互相覆寫；而 PHP 的擴充與它們依賴的 C 函式庫也不保證能在多執行緒下使用（見 ZTS）。多數發行版的 mod_php 套件沒有開 ZTS，php:8.5-apache 也一樣：

1$ apache2ctl -M | grep -E "mpm|php"
2 mpm_prefork_module (shared)
3 php_module (shared)
4$ php -i | grep "Thread Safety"
5Thread Safety => disabled

Apache 2.4 自己的預設 MPM 是 event（官方 httpd:2.4 映像檔回報 Server MPM: event）。裝上 mod_php，Apache 就要退回 prefork。

每個子程序都帶著 PHP

prefork 加 mod_php 的組合，讓 PHP 直譯器出現在每一個子程序裡，不論這個子程序正在處理什麼請求。在容器裡列出 Apache 的程序與它們映射的 libphp：

1pid=1  user=root     rss_kb=29112 libphp_mapped=6
2pid=16 user=www-data rss_kb=9928  libphp_mapped=6
3pid=17 user=www-data rss_kb=10640 libphp_mapped=6
4pid=18 user=www-data rss_kb=9928  libphp_mapped=6

（讀其他程序的 /proc/<pid>/maps 需要 SYS_PTRACE 權限，在 Docker 裡要用 --cap-add SYS_PTRACE 啟動容器才讀得到。）

剛處理過一個靜態檔 hello.txt 請求的子程序，也映射著 libphp。這帶出 mod_php 的三個代價，它們的根源相同：

送靜態檔的程序也背著 PHP。 一個頁面載入一支 PHP 與數十個圖片、CSS、JS，每個請求都佔用一個帶著 PHP 的子程序。能同時存在的子程序數量受主機記憶體約束，而每個子程序的記憶體裡都有一份 PHP，所以同樣的記憶體能開的子程序比純送靜態檔的 web 伺服器少。

並發數等於子程序數。 prefork 一個連線佔一個子程序，同時能處理的連線數上限就是子程序的上限（MaxRequestWorkers）。網路慢的客戶端、或是在 keep-alive 時間內沒有送下一個請求的連線，都會佔住一個帶著 PHP 的子程序，而它在這段時間什麼都沒做。

所有站台以同一個帳號執行。 子程序的執行帳號是 Apache 的帳號（上面的 www-data）。同一台伺服器上的每個站台，PHP 都以這個帳號執行，A 站的 PHP 讀得到 B 站的設定檔；PHP 產生的檔案屬於 www-data，站台擁有者用自己的 FTP 帳號刪不掉。共享主機因此長期用 CGI 加 suEXEC，而不用 mod_php。例外是第三方的 MPM mpm-itk：它讓每個虛擬主機以自己的帳號執行 mod_php，使用的人較少，Apache 官方發行的 prefork、worker、event 都沒有這個能力。

設定的位置與生效時機

mod_php 的 PHP 跟 Apache 是同一個程序，所以 PHP 的設定跟 Apache 綁在一起：

• php.ini 改了要重新載入 Apache：設定在子程序啟動時讀入，改了檔案要 apachectl graceful 讓 Apache 換掉子程序才生效。重啟 PHP 就是重啟 Apache。
• .htaccess 可以改 PHP 設定：mod_php 在 Apache 裡註冊了 php_value、php_flag 這些指令，站台在自己目錄的 .htaccess 裡寫 php_value upload_max_filesize 64M 就能覆寫設定，不必有伺服器的管理權限。這是共享主機時代最常用的調整方式。

從 mod_php 換到 PHP-FPM 時 .htaccess 的變化

PHP 官方文件現在對 Apache 的建議是：新的部署用 PHP-FPM 搭配 Apache 的 mod_proxy_fcgi，這樣 Apache 可以用 event MPM，PHP 也能獨立重啟（見 PHP-FPM）。換過去時，.htaccess 裡的 PHP 設定是最常撞到的問題。

php_value 這個指令是 mod_php 註冊的，Apache 沒載入 mod_php 時不認得它。在官方的 httpd:2.4 上放一個只有一行 php_value upload_max_filesize 64M 的 .htaccess，連同目錄下的靜態檔 index.html 都回 500，錯誤 log 是：

1[core:alert] ... /usr/local/apache2/htdocs/.htaccess: Invalid command 'php_value', perhaps misspelled or defined by a module not included in the server configuration

.htaccess 一旦有 Apache 不認得的指令，整份檔案都不能用，所以壞掉的是整個目錄，不只是 PHP 的請求。

PHP-FPM（以及 CGI）下對應的機制是 .user.ini：放在站台目錄裡、語法跟 php.ini 相同的檔案，PHP 官方文件寫明它只由 CGI/FastCGI SAPI 處理（見 php.ini / .user.ini）。所以搬家時要把 .htaccess 裡的 php_value 與 php_flag 移到 .user.ini，並刪掉 .htaccess 裡的那幾行。.user.ini 不是每個請求都重讀：PHP 依 user_ini.cache_ttl（預設 300 秒）快取它，改了之後最多要等這段時間才生效。

mod_php 適合的場合

mod_php 的優點是簡單：一個程序、一份設定，Apache 與 PHP 之間沒有任何協定要設定，也沒有第二個服務要監看。單一站台、流量不大、靜態檔由 CDN 或另一台伺服器處理時，它的代價不明顯。

它的代價集中在兩件事上：每個子程序都帶著 PHP，以及 PHP 的壽命與身分綁在 Apache 上。把 PHP 從 web 伺服器的程序裡搬出去、同時保留常駐程序的好處，需要一個讓 web 伺服器與 PHP 程序溝通的協定，那就是 FastCGI。

FastCGI 要解決 CGI 的哪一件事

CGI 的成本集中在一句話：每個請求啟動一個新程序，請求結束程序就消失。載入 PHP 執行檔、讀設定、初始化擴充這些工作，每個請求都要重做一次，OPcache 也因為程序不續命而永遠命中不了。

FastCGI 的原始規格由 Open Market 在 1996 年發布，開宗明義寫它「designed to support long-lived application processes」——支援長時間存活的應用程式程序。它保留 CGI 已經可行的部分（請求資訊用一組具名的參數傳遞，回應用資料流送回），只改掉程序的壽命：應用程式程序啟動一次後常駐，透過一條連線接收一個又一個請求。

一個請求在 FastCGI 協定裡的樣子

FastCGI 把一條連線上的資料切成一筆一筆的記錄（record），每筆記錄有型別。一個請求用到的主要型別：

• FCGI_PARAMS：web 伺服器把請求的參數（名稱與值的配對）送給應用程式，裝的就是 CGI 那套 meta-variables——REQUEST_METHOD、QUERY_STRING、SCRIPT_FILENAME 等。PHP 的 $_SERVER 就是從這裡填出來的。
• FCGI_STDIN：請求的內容（POST 的資料）。
• FCGI_STDOUT：應用程式送回的回應，包含標頭與內容。
• FCGI_END_REQUEST：應用程式宣告這個請求處理完了。

FastCGI 的角色裡最常用的是 Responder，規格說它對應 CGI 原本做的事：接收一個 HTTP 請求的全部資訊，產生一個 HTTP 回應。PHP-FPM 實作的就是這個角色。

這帶出一個分工上的事實：web 伺服器收到 HTTP 請求之後，自己把它拆解成 FCGI_PARAMS 裡的參數，再送給 PHP。PHP 收到的是 web 伺服器整理好的參數，原始的 HTTP 請求留在 web 伺服器那一側。其中一個參數決定了 PHP 要執行哪個檔案，而它由 web 伺服器填寫——這是下一節的安全邊界。

web 伺服器決定 PHP 執行哪個檔案

SCRIPT_FILENAME 這個參數告訴 PHP 要執行磁碟上的哪一個檔案。在 Nginx 加 PHP-FPM 的設定裡，它由 Nginx 組出來：

1location ~ \.php$ {
2    fastcgi_pass fpm:9000;
3    include fastcgi_params;
4    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
5}

這段設定要讀者改的是 fastcgi_pass 後面的位址：fpm:9000 是 PHP-FPM 在這個環境裡的主機名與埠，同一台機器上通常是 127.0.0.1:9000 或一個 Unix socket 的路徑。$fastcgi_script_name 是 Nginx 從請求路徑推出來的腳本路徑。問題出在 location ~ \.php$：它只要求路徑以 .php 結尾，沒有要求那個檔案存在。

這一點配上 PHP 的 cgi.fix_pathinfo 設定會變成一個漏洞。cgi.fix_pathinfo 開著時（這是預設值），PHP 拿到一個不存在的檔案路徑，會往前找路徑裡存在的那一段當成要執行的腳本。把這幾件事擺在一起，一個常見的攻擊路徑是：使用者上傳一個內含 PHP 程式碼、副檔名卻是圖片的檔案（evil.jpg），再用 /uploads/evil.jpg/x.php 這個網址存取它。

在刻意寫成不安全版本（location ~ \.php$ 沒有檢查檔案存在、cgi.fix_pathinfo=1、PHP-FPM 的 security.limit_extensions 放寬到容許 .jpg）的環境實測：

1$ curl localhost/uploads/evil.jpg/x.php
2executed as PHP: /var/www/html/uploads/evil.jpg   [200]

Nginx 看到路徑以 .php 結尾，把它交給 PHP；PHP 找不到 x.php，依 cgi.fix_pathinfo 往前找到存在的 evil.jpg，把這個圖片當成 PHP 執行了。上傳的內容因此變成在伺服器上執行的程式碼。

三道各自獨立的防線

這個漏洞要同時打穿幾道設定才成立，所以每一道都能單獨擋下它。實測三種修法各自的效果：

PHP-FPM 的 security.limit_extensions 限制哪些副檔名可以被當成 PHP 執行，預設只有 .php。保持預設時，evil.jpg 根本不會被執行：

1$ curl localhost/uploads/evil.jpg/x.php
2Access denied.   [403]
3# php-fpm log: Access to the script '/var/www/html/uploads/evil.jpg'
4#   has been denied (see security.limit_extensions)

把 cgi.fix_pathinfo 關掉（php_admin_value[cgi.fix_pathinfo] = 0），PHP 不再往前找存在的檔案，找不到 x.php 就直接回報沒有輸入檔：

1$ curl localhost/uploads/evil.jpg/x.php
2No input file specified.   [404]

在 Nginx 的 location ~ \.php$ 裡加 try_files $uri =404，要求檔案存在才交給 PHP，不存在的 x.php 在 Nginx 這一層就被擋下，根本到不了 PHP：

1location ~ \.php$ {
2    try_files $uri =404;        # 檔案不存在就直接回 404，不轉給 PHP
3    fastcgi_pass fpm:9000;
4    include fastcgi_params;
5    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
6}

1$ curl localhost/uploads/evil.jpg/x.php
2[404]

三道防線的位置不同：try_files 在 web 伺服器（請求還沒到 PHP）、security.limit_extensions 與 cgi.fix_pathinfo 在 PHP 端。預設值已經擋住這個攻擊（security.limit_extensions 預設 .php、而 fix_pathinfo 的風險要配上寬鬆的 location 才成立），要出事得有人主動放寬設定。三道一起設是縱深防禦：任何一道被改錯，另外兩道還在。

這個邊界的根源是本篇開頭那件事：SCRIPT_FILENAME 由 web 伺服器決定，PHP 照著它執行。PHP 信任 web 伺服器交來的檔案路徑，所以 web 伺服器的路由規則寫得鬆，PHP 就會執行到不該執行的檔案。

FastCGI 與 PHP-FPM 的關係

FastCGI 是協定，規定 web 伺服器與應用程式程序之間怎麼傳遞請求和回應。它本身不規定那群常駐的應用程式程序由誰啟動、開幾個、一個掛了怎麼補、記憶體漲了怎麼辦。

這些是「程序管理」的工作，PHP 的答案是 PHP-FPM（FastCGI Process Manager）。它實作 FastCGI 的 Responder 角色，接 Nginx 或 Apache 用這個協定送來的請求，並管理那一群 PHP worker 程序。程序管理的每一個旋鈕，以及它們怎麼影響服務的行為與壓測數字，在 PHP-FPM 展開。

為什麼常駐程序需要一個管理者

FastCGI 要求應用程式程序常駐，於是出現幾個 CGI 下不存在的問題，因為 CGI 的程序活一個請求就結束、沒有機會累積：

• 開幾個程序：太少，並發的請求要排隊；太多，記憶體吃光。
• 一個程序掛了誰補：常駐的程序可能因為程式錯誤或記憶體不足而死掉，要有人把它補回來。
• 記憶體隨時間漲：worker 活得久，C 擴充的記憶體洩漏會一點一點累積。
• 某個請求卡住：一個跑不完的請求會一直佔著一個 worker，佔住的 worker 越多，能處理新請求的就越少。

PHP-FPM 就是處理這幾件事的常駐服務（見 PHP-FPM）。它的 PHP 版本記在官方 ChangeLog 裡：PHP 5.3.3（2010 年 7 月）的 ChangeLog 記著「Added FastCGI Process Manager (FPM) SAPI」，FPM 從這個版本起隨 PHP 本體發行。PHP-FPM 的架構是一個主程序（master）加一群 worker：master 不處理請求，只負責讀設定、開 worker、補死掉的 worker、轉送管理訊號；worker 才是實際執行 PHP 的程序。

PHP 官方文件對它有一句明確的安全要求：php-fpm must not be reachable from an untrusted network——FastCGI 的埠（預設 9000）不能對不受信任的網路開放。FastCGI 協定本身沒有驗證，誰連得上這個埠，誰就能指定 SCRIPT_FILENAME 要 PHP 執行哪個檔案（見 FastCGI 的安全邊界）。所以它只聽 127.0.0.1 或 Unix socket，或用 listen.allowed_clients 限制來源。

pool：一組 worker 與它的執行身分

PHP-FPM 把 worker 分成一個或多個 pool，每個 pool 是一組設定相同的 worker，可以指定自己的執行帳號（user / group）、監聽位址（listen）、以及 PHP 設定。這一個機制解掉了 mod_php 最大的限制：

mod_php 的所有站台都以 Apache 的帳號執行，彼此的檔案互相看得到。PHP-FPM 讓每個站台一個 pool、各自指定執行帳號：

1[site_a]
2user = site_a
3group = site_a
4listen = /run/php/site_a.sock
5
6[site_b]
7user = site_b
8group = site_b
9listen = /run/php/site_b.sock

listen 可以是 Unix socket 的路徑（如上）或 IP:埠。web 伺服器與 PHP-FPM 在同一台機器、同一個檔案系統時可以用 Unix socket，少走一層 TCP；分在不同容器或不同機器時要用 TCP，這也是容器環境預設 listen = 9000 的原因。

site_a 的 PHP 以 site_a 的帳號執行，讀不到 site_b 的檔案，產生的檔案也屬於 site_a。這把 CGI 加 suEXEC 才有的隔離，做在了常駐程序上——既有隔離，又沒有每個請求啟動程序的成本。這是共享主機從 CGI 換到 PHP-FPM 的主因。

pm：開 worker 的三種策略

pm 決定 PHP-FPM 怎麼決定開幾個 worker，有三個值：

三者的上限都是 pm.max_children，差別只在平常保持幾個 worker 活著。dynamic 是預設，它的「動態」是 PHP-FPM 在常駐的 worker 群裡依閒置數量增減，不是每個請求開關程序，所以跟 CGI 的每請求一程序是兩回事。

容器裡的取捨跟整台伺服器不同。一個容器通常只跑一個 pool，而且 max_children 已經依容器的記憶體上限配好；這時 dynamic 省下的閒置記憶體別的程式也用不到，static 反而省掉流量上升時臨時開 worker 的延遲。

max_children：並發上限與排隊

pm.max_children 是這個 pool 最多能同時存在的 worker 數量，也就是這個 pool 最多能同時處理幾個請求。一個 worker 一次只處理一個請求，所以超過這個數量的請求要排隊等。每個 worker 各自連資料庫，所以實例數 × pm.max_children 也是資料庫連線數的上限，要算進資料庫的 max_connections（各語言的連線模型對照見 1.17 應用程式存取資料庫的工具分層）。

這一點可以直接量。設 pm = static、pm.max_children = 2，然後同時送 6 個各需要 1 秒的請求：

1各請求完成的秒數：[1.06, 1.06, 2.07, 2.07, 3.08, 3.09]  總時間 3.1 秒

兩個 worker 同時處理兩個請求（約 1 秒完成），剩下的排隊：第三、四個等前兩個做完（約 2 秒），第五、六個再等一輪（約 3 秒）。這就是 max_children 太小時的樣子：請求都成功了，延遲隨排隊長度線性增加。

max_children 要設多大，由兩件事夾出來：

• 上界是記憶體：每個 worker 都佔記憶體（框架越大佔越多）。max_children 乘上單一 worker 的記憶體，不能超過機器分給 PHP 的量，否則系統開始用 swap 或直接把程序殺掉。單一 worker 的記憶體要用最重的那一類請求的峰值估，不能用平均值：下面〈max_requests〉一節量到，worker 處理完一個重請求之後，記憶體會保留一段時間才降回來，而尖峰時可能每個 worker 剛好都處理過重請求。
• 下界是並發需求：太小就像上面那樣排隊。需要多少並發，看請求把時間花在哪裡：大部分時間在等資料庫或外部 API 的請求，worker 等待時不佔 CPU，數量可以遠多於 CPU 核心數；大部分時間在計算的請求，worker 數超過核心數之後只增加切換成本，處理量不會再上升。

這是 PHP-FPM 最常調、也最該記進壓測結果的一個值。壓測時換了機器、換了框架、改了這個值，數字就不能跟之前比。

max_requests：定期換掉 worker 以控制記憶體

pm.max_requests 讓一個 worker 處理滿指定數量的請求之後，自己結束，由 master 開一個新的 worker 補上。設 pm.max_requests = 3，對計數腳本連續請求，可以看到 PID 換掉：

1pid=7 static=1 ...
2pid=7 static=1 ...
3pid=7 static=1 ...
4pid=8 static=1 ...     # PID 7 處理滿 3 個請求後，換成 PID 8

它防的是哪一種記憶體成長，要先把 worker 的記憶體分成兩類，因為兩類跨請求的行為不同。

PHP 程式碼用的記憶體不會隨處理過的請求數增長，但會暫時停在高點。 PHP 程式碼建立的變數、陣列與物件，由 PHP 自己的記憶體管理器（Zend Memory Manager）配置，請求結束時全部釋放——這是 shared-nothing 的一部分。不過「釋放」是釋放給記憶體管理器，不等於立刻還給作業系統，所以從作業系統看到的 RSS 不會馬上降。用一個只開一個 worker 的 pool，讓每個請求都落在同一個程序上，量它的 RSS（作業系統看到的實體記憶體佔用）：

1初始                                  rss=10MB
2一個建立 50 萬筆小陣列的請求（PHP 峰值 210MB）
3之後的小請求，依序：                  rss=112MB → 62MB → 36MB → 24MB → 18MB → 14MB → 14MB

請求早就結束了，RSS 卻停在 112MB，再隨後面的請求逐步降回約 14MB。原因在記憶體管理器的實作：它以 2MB 的 chunk 為單位向作業系統要記憶體，請求結束時不把 chunk 全部還回去，而是留下一部分給下一個請求用，省掉反覆向作業系統申請與歸還的成本。留下多少由一個移動平均決定，每個請求結束時更新成「上一次的平均與這次請求的峰值兩者的平均」，保留的 chunk 數跟著這個平均走。代入上面的量測：重請求之前平均接近 0，重請求的峰值約 210MB，這個請求結束時平均變成兩者的一半、約 105MB，所以保留了約 102MB；之後每個輕請求的峰值只有約 2MB，平均每次再減半。PHP 回報的記憶體依序是 102、52、26、14、8、4、2 MB，就是這個減半。這個調整只在請求結束時發生：worker 閒著沒有請求時，RSS 停在原來的值，不會隨時間自己降下來。單一一次配置超過約 2MB 的大區塊不走 chunk，請求結束時直接還給作業系統：一個配置 200MB 字串的請求結束後，RSS 立刻回到 12MB。

所以 worker 的 RSS 反映的是最近處理過的請求的峰值，不是它累計處理過幾個請求。重複「每 5 個輕請求夾 1 個重請求」六輪，每輪結束時的 RSS 都停在 14MB，沒有一輪比一輪高。

真正會跨請求累積的，是 PHP 記憶體管理器以外的記憶體。 C 寫的擴充與它們依賴的函式庫，有一部分記憶體直接向作業系統的配置器要，不經過 Zend Memory Manager，也不在請求結束時被清掉。這一類有洩漏時，worker 的 RSS 會隨處理過的請求數一路往上，不會降回來。max_requests 防的是這一類：與其逐一追查是哪個擴充在漏，讓 worker 處理一定數量的請求後整個換掉，舊程序累積的記憶體隨它結束一起還給作業系統。代價是新 worker 的 OPcache 命中要重新累積（見 OPcache 與程序壽命），所以這個值不設太小。

這兩類的分別給出一個判讀方法：在穩定的負載下，觀察 worker 的 RSS 在輕請求之後回落到的底部。底部固定，代表成長來自重請求的暫時保留，max_requests 不必設；底部隨時間一路往上，代表有 PHP 記憶體管理器以外的洩漏，這才是 max_requests 要處理的情形。

request_terminate_timeout 與 slowlog：跑太久的請求

一個卡住的請求會一直佔著一個 worker。佔住的 worker 越多，max_children 裡能處理新請求的名額就越少，到最後整個 pool 都卡在慢請求上，新請求全部排隊。PHP-FPM 有兩個設定處理這件事。

request_terminate_timeout 是強制上限：一個請求跑超過這個時間，PHP-FPM 直接終止處理它的 worker。設 request_terminate_timeout = 3s，對一個會跑 5 秒的請求：

1$ curl -o /dev/null -w "%{http_code} after %{time_total}s" localhost/sleep.php?s=5
2502 after 3.24s

PHP-FPM 的 log 記下整個過程：

1WARNING: child 11, script 'sleep.php' execution timed out (3.2 sec), terminating
2WARNING: child 11 exited on signal 15 (SIGTERM) ...

而 Nginx 這一側，因為 worker 被終止、連線斷掉，記下：

1[error] recv() failed (104: Connection reset by peer) while reading
2  response header from upstream

這解釋了一個常見的現象：前端收到 502 Bad Gateway，但 Nginx 的 log 寫的是「連線被 upstream 重設」——因為 PHP-FPM 為了保護 worker 名額，主動把那個卡住的 worker 殺掉了。5xx 還有另一個常見成因跟逾時無關：worker 全忙時新請求在佇列裡排隊，延遲一路上升，排得夠久會撞到 Nginx 自己的逾時。兩者在 status 頁分得開，後者的 max listen queue 會大於 0（見下面的〈status 頁〉一節）。request_terminate_timeout 跟 PHP 自己的 max_execution_time 量的不是同一種時間。PHP 官方文件寫明，max_execution_time 只計算腳本本身執行的時間，花在腳本以外的活動——系統呼叫、串流操作、資料庫查詢——不算進去（Windows 例外，那裡量的是實際經過的時間）。所以一個卡在等資料庫回應的請求，max_execution_time 可能永遠不會觸發。request_terminate_timeout 由 PHP-FPM 從外部計算實際經過的時間，卡在哪裡都會終止。

request_slowlog_timeout 不終止請求，只在請求超過指定時間時把它當下的 PHP 呼叫堆疊記進 slowlog。設 request_slowlog_timeout = 1s，一個在 loadReport() 裡 sleep 的請求會留下：

1[pool www] pid 6
2script_filename = /var/www/html/slow.php
3[0x...] usleep() /var/www/html/slow.php:2
4[0x...] loadReport() /var/www/html/slow.php:3
5[0x...] handle() /var/www/html/slow.php:4

堆疊直接指出慢在哪一行、哪一層呼叫。這是找出慢請求根源最直接的工具，不必改程式加計時。

一個部署上的細節：PHP-FPM 取 worker 的堆疊是靠 ptrace 這個系統呼叫，在 Docker 預設的權限下會失敗（failed to ptrace(ATTACH) ... Operation not permitted），slowlog 因此是空的。容器裡要用 slowlog 得在啟動時加 --cap-add SYS_PTRACE。

status 頁：看這個 pool 現在的狀態

pm.status_path 開一個狀態頁，列出 pool 當下的 worker 數量、排隊與累計計數。前面那個 max_children = 2 的排隊測試跑完後，狀態頁是：

 1pool:                 www
 2process manager:      static
 3accepted conn:        15
 4listen queue:         0
 5max listen queue:     4
 6idle processes:       1
 7active processes:     1
 8total processes:      2
 9max active processes: 2
10max children reached: 0
11slow requests:        0

幾個欄位直接對應前面的設定：

• max listen queue：等待空閒 worker 的請求，最多排到過幾個。上面是 4，正好是那次 6 個並發裡、扣掉 2 個正在處理的其餘 4 個。這個數字長期大於 0，代表 max_children 在尖峰時不夠用，請求要排隊等空閒的 worker。
• max children reached：PHP-FPM 想多開 worker、卻撞到 max_children 上限的次數。這個計數只在 dynamic 與 ondemand 下會動，因為只有這兩種模式會「想多開」：上面那次是 static，請求排了 4 個而它仍然是 0；同樣 6 個並發換成 pm = dynamic（max_children = 2）時，它變成 1、max listen queue 是 5。所以 static 模式要看 max listen queue，不能看這一欄。
• slow requests：超過 request_slowlog_timeout 的請求累計數。

所以判斷 max_children 夠不夠，要先看 pool 用的是哪一種 pm：static 只能看 max listen queue（max children reached 在 static 下永遠是 0），dynamic 與 ondemand 兩欄都能看。max listen queue 長期大於 0 就該往上調，前提是記憶體容得下；長期是 0 代表還有餘裕。

停機與重載的訊號

PHP-FPM 的 master 依收到的訊號決定怎麼停或怎麼換掉 worker，PHP 原始碼附的 man page 列出四個：

「graceful」要等正在處理的請求多久，由另一個設定 process_control_timeout 決定：master 送出停止訊號之後，最多等 worker 這麼久。它的預設值是 0，也就是不等。一個請求要跑 3 秒，在它跑到第 1 秒時對 master 送 SIGUSR2：

1process_control_timeout = 0（預設）  →  502，在 1.07 秒時中斷
2process_control_timeout = 10         →  200，跑滿 3.0 秒才回應

SIGQUIT 一樣：預設值下 docker stop 一送出 PHP-FPM 就結束，進行中的請求拿到 502；設成 10 之後，docker stop 花了 2 秒，等那個請求做完。所以要讓 reload 與停機不中斷請求，process_control_timeout 要設成比最長的正常請求還長的秒數（它寫在設定檔的 [global] 段），而容器平台的停機逾時（docker stop -t、Kubernetes 的 terminationGracePeriodSeconds）要比它更長，否則平台會先強制終止。

設好之後，reload 只換 PHP 不動 Nginx。這跟 mod_php 的「改 PHP 設定要重載 Apache」是不同的隔離層級：PHP-FPM 是獨立的服務，重載 PHP 時 Nginx 的程序與它和客戶端之間的連線都不受影響。這也是 PHP 官方建議「用 PHP-FPM 取代 mod_php」的理由之一——PHP 能獨立於 web 伺服器重啟。

PHP-FPM 管的事情總覽

回到開頭那幾個「常駐程序帶出的問題」，PHP-FPM 的每一個旋鈕各對應一個：

這些旋鈕都是因為 worker 常駐才需要。worker 常駐同時讓一件事變得有意義：OPcache。程序活得夠久，編譯好的 opcode 才有機會被下一個請求重用，重用的程度在 OPcache 與程序壽命 實測。

如果連應用程式的狀態也想跨請求保留（框架只啟動一次），就要再往前走一步到常駐 worker 模型，那是另一組取捨，見 常駐 worker 模型。而把 Nginx 跟 PHP-FPM 放進容器時，兩個程序怎麼擺、要不要拆成兩個容器，見 容器裡的 Nginx 與 PHP-FPM。

OPcache 快取的是編譯結果

PHP 每次執行一個 .php 檔，都要先把原始碼編譯成 opcode——Zend 引擎實際執行的指令——再執行它（見 OPcache）。沒有快取時，每個請求的每個檔案都要重新讀檔、解析、編譯。

OPcache 把編譯好的 opcode 存進一塊共享記憶體，下一次要執行同一個檔案時，直接從共享記憶體拿編譯結果，跳過讀檔與編譯。它快取的是程式碼，不是資料：變數的值、查詢結果、請求之間的狀態都不在裡面，shared-nothing 不受影響。PHP 5.5 起 OPcache 隨 PHP 一起發行；PHP 8.5 依〈Make OPcache required〉這份 RFC 把它靜態編進 PHP 本體，不必也不能再另外安裝，開關仍然由 opcache.enable 控制。

框架讓這件事的份量變得很大。Laravel 13 處理一個最簡單的健康檢查請求，get_included_files() 回報這個請求載入了 484 個檔案——設定、服務提供者、路由、中介層、框架本身的類別。這 484 個檔案每個請求都要用到，所以有沒有快取它們的編譯結果，差距是每個請求都要重付一次的成本。

在同一個 Laravel 容器（Nginx 加 PHP-FPM）上循序請求 /healthz，只切換 OPcache 的開關：

相差十幾倍，而請求做的事情完全一樣。差出來的時間幾乎都花在編譯那 484 個檔案上。

快取效果與程序壽命的關係

OPcache 的共享記憶體在 PHP 啟動時建立，屬於那個程序（以及它 fork 出來的子程序）。程序結束，那塊記憶體就跟著釋放，快取也就消失。所以同一個 OPcache，在不同的執行模型下效果完全不同。

CGI：命中次數永遠是零。 CGI 每個請求啟動一個新程序。每個程序都建立自己的 OPcache、把這次用到的檔案編譯進去，然後隨請求結束一起消失。在 CGI 下印出 OPcache 的統計，cached_scripts 每次都是 1（這次編譯進去了），hits 每次都是 0（從來沒有被重用過）。OPcache 是開著的，只是沒有作用。

PHP-FPM：worker 共用同一份快取。 PHP-FPM 的 master 在啟動時建立 OPcache 的共享記憶體，再 fork 出 worker，worker 繼承了這塊記憶體。所以一個 pool 裡所有 worker 讀寫的是同一份快取。對兩個 worker 輪流處理的請求印出統計：

1pid=6 opcache_enabled=true cached_scripts=1 hits=0
2pid=7 opcache_enabled=true cached_scripts=1 hits=1
3pid=6 opcache_enabled=true cached_scripts=1 hits=2
4pid=7 opcache_enabled=true cached_scripts=1 hits=3

PID 6 第一次執行時把腳本編譯進快取，PID 7 接下來直接命中——它自己沒有編譯過這個檔案，用的是 PID 6 編譯好的結果。命中次數跨 worker 累加。這帶出兩個推論：

• worker 被換掉不會清空快取。 pm.max_requests 換掉的是 worker，快取住在 master 建立的共享記憶體裡，新 worker 一啟動就能用。要清空快取得重啟或 reload 整個 PHP-FPM。
• 同一台機器上的不同 pool 共用同一個 master 時，也共用這塊記憶體。 所以 memory_consumption 要容得下所有 pool 的程式碼。

mod_php 的情況相同：Apache 的父程序載入 PHP 時建立共享記憶體，子程序繼承它。在 php:8.5-apache 上連續請求五次，五個不同的子程序（PID 16 到 20）回報的命中次數依序是 0、1、2、3、4。

快取的大小

OPcache 的共享記憶體大小固定，由兩個設定決定，php:8.5-fpm-alpine 的預設值是：

Laravel 13 骨架處理過請求之後，OPcache 回報快取了 467 個腳本，用掉 22.0 MB，剩下 106.0 MB；另外 interned strings（PHP 把重複出現的字串只存一份的區塊）用掉 4.3 MB。一個空骨架用不到預設值的五分之一，但正式專案加上大量套件之後，vendor/ 裡的檔案數可以到上萬個。

快取滿了時，OPcache 不會報錯讓請求失敗：放不進去的檔案就不被快取，每次重新編譯。檔案改過而留下的舊版本佔用的空間算是「浪費的記憶體」，剩餘空間不夠、而浪費的比例又超過 opcache.max_wasted_percentage（預設 5%）時，OPcache 會排定一次重啟，清空整份快取重新累積。兩種情形從外面看都只是請求變慢，所以要從 opcache_get_status() 讀：free_memory 接近零、或 num_cached_scripts 接近 max_accelerated_files，就是該調大的時候。手上的專案實際要多大，在部署環境跑過一輪主要的請求之後，讀這兩個值就知道。

部署新程式碼時舊版還會執行多久

OPcache 快取了編譯結果，所以檔案改了之後，PHP 什麼時候才去讀新版，由 opcache.validate_timestamps 與 opcache.revalidate_freq 決定。這是部署時最常撞到的問題。

opcache.validate_timestamps 決定 OPcache 要不要檢查檔案有沒有改過。opcache.revalidate_freq 是檢查的間隔秒數。php:8.5-fpm-alpine 的預設值是 validate_timestamps=On、revalidate_freq=2。實測兩種設定下，改了檔案之後的行為：

 1# validate_timestamps=1, revalidate_freq=2（預設）
 2改檔之前  version=2
 3改檔之後 t+0s  version=2
 4         t+1s  version=2
 5         t+3s  version=3     # 間隔過了，OPcache 檢查到檔案改了，重新編譯
 6
 7# validate_timestamps=0
 8改檔之前  version=1
 9改檔之後  version=1          # 連續請求都還是舊版
10         version=1
11         version=1
12reload 之後 version=2        # kill -USR2 讓 PHP-FPM reload，快取清空才換成新版

兩種設定各有用途：

• validate_timestamps=1：改檔之後最多 revalidate_freq 秒就生效，代價是每隔這段時間 PHP 要對檔案做一次 stat。開發環境與「直接覆寫伺服器上的檔案」的部署方式適合這個。
• validate_timestamps=0：OPcache 完全不檢查檔案，省掉所有 stat；改了檔案永遠不會生效，部署流程必須在換完程式碼之後 reload 或重啟 PHP-FPM。程式碼包在容器映像檔裡的部署適合這個：映像檔裡的檔案不會在執行中被改，每次部署都是啟動新容器，新容器的快取在啟動時是空的。開發時用 bind mount 把主機上的原始碼掛進容器，雖然也是容器，檔案卻會被改，要算成上一種情形、留著 validate_timestamps=1；設成 0 的話，改了檔案頁面不會變，也沒有任何錯誤訊息。

validate_timestamps=1 下還有一個中間狀態要知道：部署是逐一覆寫檔案時，在 revalidate_freq 那幾秒內，有的檔案已經重新編譯成新版、有的還是舊版快取，同一個請求可能同時執行到新舊兩版的程式碼。把整個版本目錄準備好再一次切換（例如換一個符號連結），然後 reload，可以避開這個狀態。

OPcache 的 JIT 與 preload

OPcache 另外帶著 JIT 與 preload，兩者跟快取 opcode 相鄰，解決的是不同的問題：

• JIT：把 opcode 進一步編譯成 CPU 的機器碼。它對計算密集的程式（數學運算、影像處理）有幫助，對多數時間在等資料庫與網路的 web 請求效果有限。php:8.5-fpm-alpine 預設 opcache.jit=disable。
• preload（opcache.preload）：PHP-FPM 啟動時先執行一支指定的腳本，把它載入的類別常駐在共享記憶體裡，之後每個請求不必再載入它們。被 preload 的檔案改了要重啟 PHP-FPM 才生效。

OPcache 與執行模型的關係

OPcache 的效果整個建立在程序壽命上：CGI 下沒有作用，常駐的 PHP-FPM worker 讓它重用到極致。但它只省掉「編譯」這一段。框架在每個請求開頭還要做另一件事——執行那 484 個檔案：建立服務容器、註冊服務、讀設定、建立路由表——這一段 OPcache 省不掉，因為 shared-nothing 要求每個請求從空白的狀態開始。

想連這一段也省掉，就要讓應用程式的狀態也跨請求保留，框架只啟動一次。那是 常駐 worker 模型 的做法，也是它要付出的代價的來源。

兩種擺法

拆成兩個容器符合「一個容器一個職責」的慣例（見 Container per Service）：Nginx 與 PHP-FPM 可以各自更新映像檔、各自看 log、各自重啟。放進同一個容器則讓這個 PHP 服務對外就是一個講 HTTP 的單位，這在兩種情況下有用：平台只接受「一個容器、一個 HTTP 埠」的服務（多數 PaaS 與 serverless 容器平台），以及要把 PHP 服務跟其他講 HTTP 的後端一起放進同一個負載平衡的 upstream——一個 upstream 只能用一種協定轉送，Nginx 的 proxy_pass（HTTP）與 fastcgi_pass（FastCGI）不能混在同一個 upstream 裡。

「拆成兩個容器」指的是兩個容器仍然部署在一起：同一個 compose 專案，或 Kubernetes 的同一個 pod。同一個 pod 裡的容器共用網路（Nginx 用 127.0.0.1:9000 連 PHP-FPM），也能共用一個 volume 放程式碼，由 Kubernetes 分別監看兩個容器，不必手寫下面〈放進同一個容器〉那一節的腳本。拆成兩個獨立部署、跨 pod 連 FastCGI 也做得到，但 9000 就得在叢集網路上開放，要另外用 NetworkPolicy 之類的機制限制只有 Nginx 連得到。

兩種擺法共用同一個起點：官方的 php-fpm 映像檔。

官方 php-fpm 映像檔替容器改掉的預設值

PHP-FPM 原本是為「裝在一台伺服器上、由 systemd 管理」設計的，它的預設值有幾項在容器裡不適用。官方映像檔用一個 php-fpm.d/docker.conf 把它們改掉：

1[global]
2error_log = /proc/self/fd/2      ; 錯誤 log 寫到 stderr，docker logs 才看得到
3
4[www]
5access.log = /proc/self/fd/2     ; 存取 log 也寫到 stderr（PHP-FPM 啟動時會關掉 stdout）
6clear_env = no                   ; 把容器的環境變數交給 worker
7catch_workers_output = yes       ; worker 的輸出也收進主 log
8listen = 9000                    ; 聽所有網路介面的 9000

另外映像檔設了 STOPSIGNAL SIGQUIT，docker stop 送給它的是 SIGQUIT 而不是預設的 SIGTERM。SIGQUIT 是 PHP-FPM 的 graceful stop，SIGTERM 是立即終止。但 graceful stop 要等進行中的請求多久，由 process_control_timeout 決定，而它的預設值是 0：只靠 STOPSIGNAL，docker stop 時進行中的請求仍然拿到 502。實測與設定方式見 PHP-FPM 的停機與重載的訊號。映像檔沒有改這個值，所以要在自己的設定檔加上：

1[global]
2; 停機與 reload 時，最多等進行中的請求這麼久；要比最長的正常請求長，比平台的停機逾時短
3process_control_timeout = 10

其中 clear_env 最容易在自己寫設定時改壞。PHP-FPM 自己的預設是 clear_env = yes：worker 啟動時清掉所有環境變數，PHP 程式用 getenv() 讀不到。而容器的設定慣例正是用環境變數傳進去（資料庫密碼、APP_KEY）。同一個容器帶著 APP_KEY=secret-from-env 啟動，只改這一個設定：

1clear_env = no   →  getenv("APP_KEY") = 'secret-from-env'
2clear_env = yes  →  getenv("APP_KEY") = false

沒有任何錯誤訊息，程式讀到的是 false。自己寫 pool 設定或從非容器環境搬一份 www.conf 進來時，要確認這一行還是 no。

拆成兩個容器：Nginx 這一側也要有程式碼

拆成兩個容器時，最容易漏的是程式碼要兩邊都有。理由是兩個容器各自要用到檔案，用途不同：

• PHP-FPM 容器要有 PHP 檔：Nginx 送來的 SCRIPT_FILENAME 是一個路徑，PHP-FPM 在自己的檔案系統裡找這個路徑去執行。
• Nginx 容器要有靜態檔：CSS、JS、圖片由 Nginx 直接從自己的檔案系統回，不經過 PHP。try_files 判斷檔案存不存在，也是看 Nginx 自己的檔案系統。

只把程式碼掛進 PHP-FPM 容器，而 Nginx 容器沒有，一般的 Laravel 式設定（try_files $uri /index.php$is_args$args）不會報錯，而是給出錯的內容。請求 /app.css：

1# Nginx 容器沒有程式碼
2HTTP/1.1 200 OK
3Content-Type: text/html; charset=UTF-8
4（內容是 index.php 產生的頁面）
5
6# Nginx 容器也掛上同一份程式碼
7HTTP/1.1 200 OK
8Content-Type: text/css
9body{}

Nginx 在自己的檔案系統找不到 app.css，try_files 就照設定退回給 index.php，於是 PHP 回了一頁 HTML，狀態碼 200。監控看到的是全部成功，瀏覽器看到的是樣式全部消失。做法有兩種：用同一個 volume 把程式碼同時掛進兩個容器；或者正式部署時在建置映像檔的階段，把 public/ 底下的靜態檔複製一份進 Nginx 的映像檔。兩個容器裡的路徑也要一致（例如都是 /var/www/html），因為 Nginx 組出來的 SCRIPT_FILENAME 是拿自己的 root 拼的，PHP-FPM 要能在同一個路徑找到檔案。

另一件事是 FastCGI 埠的暴露範圍。映像檔的 listen = 9000 聽所有網路介面，在 compose 網路裡 Nginx 才連得到它。PHP 官方文件明寫 php-fpm 不能讓不受信任的網路連到——FastCGI 沒有驗證，連得到 9000 的人能指定 PHP 執行哪個檔案。所以 compose 裡 PHP-FPM 服務不寫 ports:，9000 只在容器網路內可達。

放進同一個容器：要自己做程序監看

同一個容器裡跑兩個程序，容器的主程序（PID 1）就不能直接是 php-fpm 或 nginx，要有一支腳本把兩個都啟動起來。這支腳本要負責三件事，而三件都是單一程序的容器不必想的。

任一個程序結束，整個容器也要結束。 只剩一半在跑的容器最難排查：Nginx 還活著，PHP-FPM 已經掛了，每個請求都回 502，而容器的狀態仍是 running，平台不會重啟它。腳本要等待任一個子程序結束，然後停掉另一個、讓自己結束。shell 的 wait -n 做的就是「等任一個子程序結束」，但 Alpine 預設的 busybox sh（1.37）在這裡有一個陷阱：子程序被訊號殺掉時（kill -9、記憶體不足被系統終止），它的 wait -n 不會返回，正好漏掉崩潰這個最需要偵測的情況。換成 bash 的 wait -n，子程序被 kill -9 時會立刻返回、帶著狀態碼 137。

把停機訊號轉給兩個程序。 docker stop 只把訊號送給 PID 1，也就是這支腳本，shell 不會自動轉給子程序。腳本要接住訊號、自己轉送。這裡有一個連帶的細節：映像檔設了 STOPSIGNAL SIGQUIT，所以腳本收到的是 QUIT。只寫 trap ... TERM 的腳本接不到它，而 PID 1 對沒有註冊處理器的訊號一律忽略，結果 docker stop 要等滿 10 秒的逾時才強制終止——實測只接 TERM 時 docker stop 花 10 秒，加上 QUIT 之後 1 秒完成。

把 FastCGI 只開給容器內部。 兩個程序在同一個容器裡，Nginx 用 127.0.0.1:9000 連 PHP-FPM 就夠了，FastCGI 不必聽在網路介面上。映像檔的 listen = 9000 設在 docker.conf，在 php-fpm.d/ 底下放一個檔名排在它後面的設定檔（例如 zzz-listen.conf）覆蓋它：

1[www]
2listen = 127.0.0.1:9000

php-fpm.d/ 底下的檔案依檔名順序讀取，後讀到的設定覆蓋前面的，所以檔名要排在 docker.conf 之後。

這三件事寫成 entrypoint 腳本：

 1#!/bin/bash
 2# 用 bash：busybox sh 的 wait -n 在子程序被訊號殺掉時不返回
 3
 4# docker stop 送來的是 SIGQUIT（映像檔的 STOPSIGNAL），一併接 TERM 與 INT
 5stop() {
 6    kill -QUIT "$fpm" "$web" 2>/dev/null   # 兩者的 graceful stop；PHP-FPM 要設 process_control_timeout 才會等
 7}
 8trap stop QUIT TERM INT
 9
10php-fpm -F &                               # -F：前景執行，讓這支腳本當它的父程序
11fpm=$!
12nginx -e stderr -g 'daemon off;' &         # -e stderr：讀設定之前的錯誤 log 也寫到 stderr
13web=$!
14
15wait -n                                    # 任一個結束就往下走
16status=$?
17stop                                       # 停掉另一個
18wait
19exit "$status"

映像檔要另外裝 bash 與 nginx（apk add bash nginx）。以非 root 使用者執行時，Nginx 的 pid 檔與暫存目錄要放在那個使用者寫得進去的位置（例如 /tmp），監聽的埠也要用 1024 以上。

這組驗證值得在建好映像檔時跑一次，因為三件事出錯時容器都照樣啟動、照樣回應：用 kill -9 分別殺掉 PHP-FPM 與 Nginx 的 master，確認容器在幾秒內結束；量 docker stop 的時間，確認不是 10 秒；從容器外面連 9000，確認連線被拒。

兩種擺法的選擇

兩種擺法的差別落在「誰負責程序監看」：拆成兩個容器時，平台（compose、Kubernetes）監看每個程序，每個容器只有一個主程序，失敗時平台看得到；放進同一個容器時，這份責任移進了 entrypoint 腳本，上面那三件事都要自己做對。

放進同一個容器時，手寫腳本之外也可以用 process supervisor（s6-overlay、supervisord）管理兩個程序，由它負責監看與回收結束的子程序，代價是映像檔多一個相依；手寫腳本的好處是沒有額外相依，三件事都看得到。

所以預設是拆成兩個容器；只有在平台只接受單一 HTTP 容器、或要讓 PHP 服務跟其他 HTTP 後端進同一個 upstream 時，才放進同一個容器，並把上面的驗證當成映像檔的驗收條件。兩種擺法都繼承 PHP-FPM 的 shared-nothing 模型；不再每個請求重新啟動框架的做法是另一個執行模型，見 常駐 worker 模型。

常駐 worker 省下的是哪一段成本

PHP-FPM 的 worker 常駐，OPcache 讓每個檔案只編譯一次，可是框架的啟動流程每個請求仍然要跑一次：建立服務容器、執行每個服務提供者的註冊、讀設定、建立路由表。這段流程的成本由框架的規模決定，跟請求要做什麼無關，是 shared-nothing 的直接代價——每個請求都從空白開始，就得每個請求都重新建立一次應用程式。

常駐 worker 模型把這段流程移到 worker 啟動時：應用程式啟動一次之後留在記憶體裡，每個請求進來只執行「處理這個請求」那一段。Laravel Octane 的文件把這件事寫成一句話：Octane boots your application once, keeps it in memory, and then feeds it requests。

這個模型要求執行 PHP 的程序或執行緒有能力在請求之間不清空狀態，所以它需要特定的伺服器，PHP-FPM 做不到（它在每個請求結束時一定清空）。Octane 支援的伺服器有 FrankenPHP、Swoole、Open Swoole 與 RoadRunner：

FrankenPHP 的兩種模式

FrankenPHP 是一個講 HTTP 的 web 伺服器，PHP 嵌在它的程序裡（SAPI 名稱是 frankenphp），所以它不需要前面再接一個 Nginx。它有兩種模式，差別正好就是狀態壽命。

傳統模式：每個請求執行一次 PHP 腳本，執行完清空狀態，跟 PHP-FPM 一樣是 shared-nothing。同一支計數腳本（腳本內容見 PHP 的請求生命週期與 SAPI）請求三次：

1pid=1 static=1 global=1 sapi=frankenphp
2pid=1 static=1 global=1 sapi=frankenphp
3pid=1 static=1 global=1 sapi=frankenphp

PID 一直是 1，因為 FrankenPHP 只有一個程序，PHP 在它的執行緒裡跑（這個 PHP 是以執行緒安全編譯的，Thread Safety => enabled，見 ZTS）。計數器每次都是 1。

worker 模式：一支 worker 腳本啟動一次，在一個迴圈裡反覆呼叫 frankenphp_handle_request()，每呼叫一次處理一個請求：

 1<?php
 2// 這段只在 worker 啟動時執行一次：模擬框架啟動
 3$bootedAt = microtime(true);
 4$requestLog = [];
 5
 6$handler = static function () use ($bootedAt, &$requestLog) {
 7    static $count = 0;
 8    $count++;
 9    $requestLog[] = $_SERVER['REQUEST_URI'];
10    echo "static=", $count, " log_entries=", count($requestLog),
11         " booted=", round($bootedAt, 3), "\n";
12};
13
14// 每次迴圈處理一個請求；伺服器要這個 worker 結束時回傳 false
15while (frankenphp_handle_request($handler)) {
16    gc_collect_cycles();
17}

連續請求四次：

1static=1 log_entries=1 booted=1791203186.703
2static=2 log_entries=2 booted=1791203186.703
3static=3 log_entries=3 booted=1791203186.703
4static=4 log_entries=4 booted=1791203186.703

booted 的時間戳四次都一樣，證明迴圈前的那段只跑了一次；static 與 $requestLog 一路累加，證明前一個請求留下的變數被下一個請求看到了。FrankenPHP 的文件對此寫得很直接：Static variables, class static properties, global variables, and in-memory caches all persist across requests。

Laravel Octane：框架層的常駐 worker

自己寫 worker 迴圈要處理的事情很多：每個請求之間重設框架的哪些物件、例外怎麼處理、什麼時候重啟 worker。Laravel Octane 是 Laravel 官方的套件，把這些包好，讓既有的 Laravel 應用程式跑在上面那幾種伺服器上，用 php artisan octane:frankenphp（或 octane:swoole、octane:roadrunner）啟動。

Octane 會在每個請求之間重設 Laravel 自己的請求相關狀態，但應用程式程式碼留下的狀態它管不到。在 Laravel 骨架加一條路由，用一個類別的靜態屬性計數，並在每個請求往一個靜態陣列塞 100 KB 的資料——模擬把查詢結果或 log 暫存在靜態屬性裡這種在 PHP-FPM 下無害的寫法：

1Route::get('/state', function () {
2    RequestLog::$count++;
3    RequestLog::$entries[] = str_repeat('x', 100 * 1024);
4    return ['count' => RequestLog::$count,
5            'php_mem_mb' => round(memory_get_usage() / 1048576, 1)];
6});

在 Octane 加 FrankenPHP、一個 worker、--max-requests=500 下連續請求：

1request #1   -> count=1   php_mem=5.6MB
2request #100 -> count=100 php_mem=15.8MB
3request #200 -> count=200 php_mem=26.1MB
4request #400 -> count=400 php_mem=46.5MB
5request #499 -> count=499 php_mem=56.6MB
6request #500 -> count=1   php_mem=1.2MB    # 處理滿 500 個請求，worker 重啟
7request #600 -> count=101 php_mem=11.5MB

同一段程式碼在 PHP-FPM 下，count 永遠是 1、記憶體在請求結束時全部釋放。在常駐 worker 下它變成兩個問題：

• 狀態洩漏到下一個請求：count 一路累加。換成「目前登入的使用者」「這個請求的語系」這類資料，就是前一個使用者的資料被下一個使用者看到。
• 記憶體隨請求數線性增長：每個請求多 0.1 MB，max-requests 到了 worker 重啟才歸零。Octane 的文件寫明它預設在 worker 處理滿 500 個請求後 gracefully restart，理由正是 to help prevent stray memory leaks，並舉了同一個例子：adding data to a statically maintained array will result in a memory leak。

這裡的記憶體增長跟 PHP-FPM 那篇〈max_requests〉一節 量到的不同。PHP-FPM 下 PHP 程式碼建立的記憶體每個請求都會釋放，worker 的記憶體反映最近一次請求的峰值；常駐 worker 下，靜態屬性裡的資料不會被釋放，記憶體跟著累計的請求數往上長。max-requests 在兩個模型下都存在，防的記憶體成長不一樣。在常駐 worker 下，它的值是兩個成本的取捨：設得低，洩漏累積到的上限低，代價是 worker 重啟頻繁、每次重啟都要重新啟動一次框架；設得高，重啟少，代價是洩漏能長到的量大。先用上面那種逐請求記錄記憶體的方式量出每個請求漲多少，再依可接受的記憶體上限回推。

worker 是程序還是執行緒，也決定一個 worker 崩潰時影響多大。RoadRunner 的 worker 是各自獨立的 PHP 程序，一個因為擴充的錯誤而 segfault 時只有它自己結束；FrankenPHP 與 Swoole 的 worker 跑在同一個程序裡，程序層級的崩潰會連同其他 worker 一起帶走。

FrankenPHP 的 worker 是執行緒，所以重啟時 PID 不變（這次實測一直是同一個 PID），換掉的是執行緒裡的 PHP 狀態。看 PID 判斷 worker 有沒有重啟，在這個伺服器上不成立。

寫給常駐 worker 的程式要避開的寫法

Octane 的文件列出的幾類問題，根源都是「物件比請求活得久」：

• 靜態屬性與全域變數存放請求的資料：上面那個例子。請求的資料放在請求範圍的物件裡，或在請求結束時清掉。
• 把服務容器或請求物件注入到長壽物件的建構子：Octane 文件的原文是 that object may have a stale version of the container or request on subsequent requests——一個 singleton 在第一個請求時拿到了那個請求的 Request，之後的請求它手上一直是第一個請求的版本。
• 在 singleton 裡快取會變的值：設定、目前的使用者、語系，在 PHP-FPM 下每個請求都重新算，在常駐 worker 下只算一次。

既有的 Laravel 應用程式搬上 Octane 之前，要把程式碼與用到的套件逐一檢查過這幾類寫法；套件作者沒有考慮常駐 worker 的話，問題會出在套件裡，而它們在 PHP-FPM 下從來不會顯現。

速度差多少要在自己的應用程式上量

常駐 worker 省下的是框架的啟動流程，所以省下多少由框架啟動流程佔每個請求多少時間決定。在 Laravel 13 骨架的 /healthz 上，同一時段各循序送 300 個請求：

兩者的中位數只差不到一毫秒，而這個差距還包含 PHP-FPM 那一側多經過的容器內 Nginx 一跳，所以兩邊不完全對等。量測對象是一個幾乎沒有服務提供者的空骨架，框架啟動流程本來就短，開了 OPcache 之後能省的不多。正式專案的服務提供者、套件與設定檔越多，啟動流程越長，常駐 worker 省下的越多。所以這組數字只說明量測的方式，不說明手上的專案會差多少：在自己的應用程式、自己的主要請求上量一次，才知道省下的時間值不值得上一節那些改寫與檢查的成本。

常駐 worker 在執行模型裡的位置

這一系列的執行模型可以排成一條線，每一步讓程序或應用程式狀態活得更久：CGI 的程序與狀態都只活一個請求；mod_php 與 PHP-FPM 讓程序活過很多請求，OPcache 因此有編譯結果可以重用；常駐 worker 讓應用程式的狀態也活過很多請求。

每往前一步，省下一段每個請求都要重付的成本，也失去一層隔離：CGI 的程序隔離讓一個請求的錯誤隨程序消失；shared-nothing 讓一個請求的資料不會被下一個請求看到。常駐 worker 走到最後一步，代價是這兩層隔離的責任從執行環境移到了程式碼身上——PHP-FPM 替程式清空的那些狀態，現在要程式自己不留下來。