php安全配置記錄和常見錯誤梳理

 

一般部署完php環境後會進行一些安全設置，除了熟悉各類php漏洞外，還能夠經過配置php.ini來加固PHP的運行環境，PHP官方也曾經屢次修改php.ini的默認設置。
下面對php.ini中一些安全相關參數的配置進行說明

register_globals
當register_globals = ON時，PHP不知道變量從何而來，也容易出現一些變量覆蓋的問題。所以從最佳實踐的角度，強烈建議設置 register_globals = OFF，這也是PHP新版本中的默認設置。

open_basediropen_basedir
能夠限制PHP只能操做指定目錄下的文件。這在對抗文件包含、目錄遍歷等攻擊時很是有用，應該爲此選項設置一個值。
須要注意的是，若是設置的值是一個指定的目錄，則須要在目錄最後加上一個「/」，不然會被認爲是目錄的前綴。
open_basedir = /home/web/html/

allow_url_include = Off
爲了對抗遠程文件包含，請關閉此選項，通常應用也用不到此選項。同時推薦關閉的還有allow_url_fopen。

display_errors = Off
錯誤回顯，通常經常使用於開發模式，可是不少應用在正式環境中也忘記了關閉此選項。錯誤回顯能夠暴露出很是多的敏感信息，爲攻擊者下一步攻擊提供便利。推薦關閉此選項。

log_errors = On
在正式環境下用這個就好了，把錯誤信息記錄在日誌裏。正好能夠關閉錯誤回顯。

magic_quotes_gpc = Off
推薦關閉，它並不值得依賴（請參考「注入攻擊」一章），已知已經有若干種方法能夠繞過它，甚至因爲它的存在反而衍生出一些新的安全問題。XSS、SQL注入等漏洞，都應該由應用在正確的地方解決。同時關閉它還能提升性能。

cgi.fix_pathinfo = 0
若PHP以CGI的方式安裝，則須要關閉此項，以免出現文件解析問題（請參考「文件上傳漏洞」一章）。

session.cookie_httponly = 1  開啓HttpOnly

session.cookie_secure = 1
如果全站HTTPS則請開啓此項。

sql.safe_mode = Off
PHP的安全模式是否應該開啓的爭議一直比較大。一方面，它會影響不少函數；另外一方面，它又不停地被黑客們繞過，所以很難取捨。若是是共享環境（好比App Engine），則建議開啓safe_mode，能夠和disable_functions配合使用；
若是是單獨的應用環境，則能夠考慮關閉它，更多地依賴於disable_functions控制運行環境安全。

disable_functions =
可以在PHP中禁用函數（如上默認=號後面什麼都不配置）。這是把雙刃劍，禁用函數可能會爲開發帶來不便，但禁用的函數太少又可能增長開發寫出不安全代碼的概率，同時爲黑客獲取webshell提供便利。
通常來講，若是是獨立的應用環境，則推薦禁用如下函數：
disable_functions = escapeshellarg, escapeshellcmd, exec,passthru, proc_close, proc_get_status, proc_open, proc_nice,proc_terminate, shell_exec, system, ini_restore, popen, dl,disk_free_space, diskfreespace, set_time_limit, tmpfile, fopen,readfile, fpassthru, fsockopen, mail, ini_alter, highlight_file,openlog, show_source, symlink, apache_child_terminate,apache_get_modules, apache_get_version, apache_getenv,apache_note, apache_setenv, parse_ini_file

php 上傳大文件主要涉及配置upload_max_filesize和post_max_size兩個選項

曾經遇到的問題：
在網站後臺上傳圖片的時候出現一個很是怪的問題，有時候表單提交能夠獲取到值，有時候就獲取不到了，連普通的字段都獲取不到了，苦思冥想還沒解決，最後問了師傅，
師傅看了說挺奇怪的，而後問我 upload_max_filesize的值改了嗎，我說改了啊，師傅也解決不了了。過了一會師傅問 post_max_size改了嗎，我說那個和上傳不要緊吧，
師傅沒理我，我仍是照着本身的想法繼續測試，弄了半天仍是不行，最後試了師傅提的意見，成功了，原來上傳是和 post_max_size有關係的。
 
問題總結 :
php.ini配置文件中的默認文件上傳大小爲 2M，默認upload_max_filesize = 2M ，即文件上傳的大小爲 2M，若是你想上傳超過8M的文件，好比 20M，
 
必須設定 upload_max_filesize = 20M。可是光設置upload_max_filesize = 20M仍是沒法實現大文件的上傳功能，你必須修改 php.ini配置文件中的post_max_size選項，
其表明容許 POST的數據最大字節長度，默認爲 8M。若是POST 數據超出限制，那麼 $_POST和$_FILES 將會爲空。要上傳大文件，
你必須設定該選項值大於 upload_max_filesize指令的值，我通常設定upload_max_filesize和 post_max_size值相等。
另外若是啓用了內存限制，那麼該值應當小於 memory_limit選項的值。
 
文件上傳的其餘注意事項 :
在上傳大文件時，你會有上傳速度慢的感受，當超過必定的時間，會報腳本執行超過 30秒的錯誤，這是由於在php.ini配置文件中 max_execution_time 配置選項在做怪，
其表示每一個腳本最大容許執行時間 (秒) ，0 表示沒有限制。你能夠適當調整 max_execution_time的值，不推薦設定爲0。
********************************************************************************************************
解釋：
具體可查看 PHP手冊 中的 〔php.ini 核心配置選項說明〕
upload_max_filesize 所上傳的文件的最大大小。 
post_max_size       設定 POST 數據所容許的最大大小。
memory_limit        設定了一個腳本所可以申請到的最大內存字節數。

通常來講：memory_limit > post_max_size > upload_max_filesize
 
upload_max_filesize是限制本次上傳的最大值
post_max_size是post數據的最大值， 經過POST提交數據的最大值
通常咱們在php中用的是POST方式上傳

=================================================================================
php.ini中記錄PHP錯誤日誌的參數：display_errors與log_errors的區別

1）display_errors 
錯誤回顯，通常經常使用語開發模式，可是不少應用在正式環境中也忘記了關閉此選項。錯誤回顯能夠暴露出很是多的敏感信息，爲攻擊者下一步攻擊提供便利。推薦關閉此選項。 

display_errors = On 
開啓狀態下，若出現錯誤，則報錯，出現錯誤提示。即顯示全部錯誤信息。 

dispaly_errors = Off 
關閉狀態下，若出現錯誤，則提示：服務器錯誤，可是不會出現錯誤提示。即關閉全部錯誤信息

2）log_errors 
在正式環境下用這個就好了，把錯誤信息記錄在日誌裏。正好能夠關閉錯誤回顯。 

log_errors = On    //注意，log_errors設置爲On後，那麼dispaly_errors就要設置爲Off，這兩個不能同時打開。

error_log = /Data/logs/php/error.log   //注意，log_errors設置爲On時，必需要設置error_log的日誌文件路徑，而且這個日誌文件要能有權限正常寫入。

也就是說log_errors = On時，必須指定error_log文件，若是沒指定或者指定的文件沒有權限寫入，那麼照樣會輸出到正常的輸出渠道，那麼也就使得display_errors 這個指定的Off失效，錯誤信息仍是打印了出來。

對於PHP開發人員來講，一旦項目上線後，第一件事就是應該將display_errors選項關閉，以避免由於這些錯誤所透露的路徑、數據庫鏈接、數據表等信息而遭到黑客攻擊。 

---------------------------------------------------
通常說來：

測試環境下的php.ini中的錯誤日誌設置：              
error_reporting = E_ALL  
display_errors = On  
html_errors = On  
log_errors = Off  

正式環境下的php.ini中的錯誤日誌設置： 
error_reporting = E_ALL &~ E_NOTICE &~ E_WARNING       //注意這個設置，記得有一次由於這個設置有誤，致使了線上一個業務訪問出現了nginx 500報錯！這個致使了php框架報錯！  
display_errors = Off  
log_errors = On  
html_errors = Off  
error_log = /Data/logs/php/error.log 
ignore_repeated_errors = On  
ignore_repeated_source = On  

簡單講解下各個配置的意義：
error_reporting ：設置報告哪些錯誤  
display_errors ：設置錯誤是否做爲輸出的一部分顯示  
html_errors ：設置錯誤信息是否採用html格式  
log_errors ：設置是否記錄錯誤信息  
error_log ：設置錯誤信息記錄的文件  
ignore_repeated_errors ：是否在同一行中重複顯示同樣的錯誤信息  
ignore_repeated_source ： 是否重複顯示來自同個文件同行代碼的錯誤 

==============================================================================
順便記錄下php的頁面總是報時區錯誤的處理過程：

Warning: phpinfo(): It is not safe to rely on the system's timezone settings. You are
*required* to use the date.timezone setting or the date_default_timezone_set()
function. In case you used any of those methods and you are still getting this
warning, you most likely misspelled the timezone identifier. We selected the
timezone 'UTC' for now, but please set date.timezone to select your timezone. in
/usr/local/www/zabbix2/phpinfo.php on line 2
date/time support enabled
"Olson" Timezone Database Version 2013.8
Timezone Database internal
Default timezone UTC

修改php.ini 文件
# vim /usr/local/php/etc/php.ini
........
[Date]
; Defines the default timezone used by the date functions
; http://php.net/date.timezone
date.timezone = Asia/Shanghai

注意必須把要 php.ini 複製一份到/usr/local/php/lib/下，不然 php 服務默認會到這個 lib 目錄下讀取 php.ini 文件，沒有的話，就是默認時區UTC，這個時區和北京時間相差8小時。
[root@i-gxcmjlge lib]# pwd
/usr/local/php/lib
[root@i-gxcmjlge lib]# ll
total 72
drwxr-xr-x 14 root root 4096 Nov 18 01:11 php
-rw-r--r-- 1 root root 65681 Nov 18 15:01 php.ini

而後重啓php服務和nginx/apache服務

除了php.ini文件，還要注意php-fpm.conf配置，以下：

[root@i-v5lmgh7y etc]# cat php-fpm.conf|grep -v "^;"|grep -v "^$"
[global]
pid = run/php-fpm.pid   //pid 設置，默認在安裝目錄中的 var/run/php-fpm.pid，建議開啓
error_log = log/php-fpm.log   //錯誤日誌，默認在安裝目錄中的 var/log/php-fpm.log
log_level = notice      //錯誤級別. 可用級別爲: alert（必須當即處理）, error（錯誤狀況）, warning（警告狀況）, notice（通常重要信息）, debug（調試信息）. 默認: notice.
emergency_restart_threshold = 60
emergency_restart_interval = 60s //表示在emergency_restart_interval所設值內出現SIGSEGV或者SIGBUS錯誤的php-cgi進程數若是超過 emergency_restart_threshold個，php-fpm就會優雅重啓。這兩個選項通常保持默認值。
process_control_timeout = 0  //設置子進程接受主進程複用信號的超時時間. 可用單位: s(秒), m(分), h(小時), 或者 d(天) 默認單位: s(秒). 默認值: 0.
daemonize = yes   //後臺執行fpm,默認值爲yes，若是爲了調試能夠改成no。在FPM中，可使用不一樣的設置來運行多個進程池。 這些設置能夠針對每一個進程池單獨設置。

[www]
user = nobody     //啓動進程的賬戶
group = nobody    //啓動進程的組
listen = 127.0.0.1:9000    //fpm監聽端口，即nginx中php處理的地址，通常默認值便可。可用格式爲: 'ip:port', 'port', '/path/to/unix/socket'. 每一個進程池都須要設置.
listen.backlog = 1024   //backlog數，，由操做系統決定，-1表示無限制。也能夠註釋掉此行。
listen.allowed_clients = 127.0.0.1  //（能夠不設置此行）容許訪問FastCGI進程的IP，若是沒有設置或者爲空，則容許任何服務器請求鏈接。設置any爲不限制IP，若是要設置其餘主機的nginx也能訪問這臺FPM進程，listen處要設置成本地可被訪問的IP。默認值是any。每一個地址是用逗號分隔. 

pm = static   //對於專用服務器，pm能夠設置爲static，如何控制子進程，選項有static和dynamic。若是選擇static，則由pm.max_children指定固定的子進程數。若是選擇dynamic，則由下開參數決定：
pm.max_children = 512   //子進程最大數
pm.start_servers = 387  //啓動時的進程數
pm.min_spare_servers = 32  //保證空閒進程數最小值，若是空閒進程小於此值，則建立新的子進程
pm.max_spare_servers = 387  //保證空閒進程數最大值，若是空閒進程大於此值，此進行清理
pm.max_requests = 1024  //設置每一個子進程重生以前服務的請求數. 對於可能存在內存泄漏的第三方模塊來講是很是有用的. 若是設置爲 '0' 則一直接受請求. 等同於 PHP_FCGI_MAX_REQUESTS 環境變量. 默認值: 0
pm.status_path = /status   //fpm狀態頁面的網址. 若是沒有設置, 則沒法訪問狀態頁面. 默認值: none. munin監控會使用到

ping.path = /ping   //fpm監控頁面的ping網址. 若是沒有設置, 則沒法訪問ping頁面. 該頁面用於外部檢測FPM是否存活而且能夠響應請求. 請注意必須以斜線開頭 (/)。能夠不設置此行。
ping.response = pong  //用於定義ping請求的返回相應. 返回爲HTTP 200的text/plain 格式文本. 默認值: pong。能夠不設置此行。
 
slowlog = var/log/slow.log   //慢請求的記錄日誌,配合request_slowlog_timeout使用
request_slowlog_timeout = 0  //設置單個請求的超時停止時間. 該選項可能會對php.ini設置中的'max_execution_time'由於某些特殊緣由沒有停止運行的腳本有用. 設置爲 '0' 表示 'Off'.當常常出現502錯誤時能夠嘗試更改此選項。
request_terminate_timeout = 10s  //當一個請求該設置的超時時間後，就會將對應的PHP調用堆棧信息完整寫入到慢日誌中. 設置爲 '0' 表示 'Off'。能夠不設置此行。
rlimit_files = 65535    //設置文件打開描述符的rlimit限制. 默認值: 系統定義值默承認打開句柄是1024，可以使用 ulimit -n查看，ulimit -n 2048修改。
rlimit_core = 0   //設置核心rlimit最大限制值. 可用值: 'unlimited' 、0或者正整數. 默認值: 系統定義值.
catch_workers_output = yes  //重定向運行過程當中的stdout和stderr到主要的錯誤日誌文件中. 若是沒有設置, stdout 和 stderr 將會根據FastCGI的規則被重定向到 /dev/null . 默認值: 空.

=================Nginx+Php中限制站點目錄防止跨站的配置方案記錄（使用open_basedir）===============
方法1）在Nginx配置文件中加入：

fastcgi_param  PHP_VALUE  "open_basedir=$document_root:/tmp/:/proc/";

一般nginx的站點配置文件裏用了include fastcgi.conf;，這樣的，把這行加在fastcgi.conf裏就OK了。
若是某個站點須要單獨設置額外的目錄，把上面的代碼寫在include fastcgi.conf;這行下面就OK了，會把fastcgi.conf中的設置覆蓋掉。
這種方式的設置須要重啓nginx後生效。

方法2）在php.ini中加入

[HOST=www.wangshibo.com]
open_basedir=/home/www/www.wangshibo.com:/tmp/:/proc/
[PATH=/home/www/www.wangshibo.com]
open_basedir=/home/www/www.wangshibo.com:/tmp/:/proc/

這種方式的設置須要重啓php-fpm後生效。

方法3）在網站根目錄下建立.user.ini文件，並在該文件中寫入下面信息：

open_basedir=/home/www/www.wangshibo.com:/tmp/:/proc/

這種方式不須要重啓nginx或php-fpm服務。安全起見應當取消掉.user.ini文件的寫權限。

php.ini中建議禁止的函數以下：

disable_functions = pcntl_alarm, pcntl_fork, pcntl_waitpid, pcntl_wait, pcntl_wifexited, pcntl_wifstopped, pcntl_wifsignaled, pcntl_wexitstatus, pcntl_wtermsig, pcntl_wstopsig, pcntl_signal, pcntl_signal_dispatch, pcntl_get_last_error, pcntl_strerror, pcntl_sigprocmask, pcntl_sigwaitinfo, pcntl_sigtimedwait, pcntl_exec, pcntl_getpriority, pcntl_setpriority, eval, popen, passthru, exec, system, shell_exec, proc_open, proc_get_status, chroot, chgrp, chown, ini_alter, ini_restore, dl, pfsockopen, openlog, syslog, readlink, symlink, popepassthru, stream_socket_server, fsocket, chdir

====================php啓動後，9000端口沒有起來？=====================
問題描述：
php服務安裝後，啓動php-fpm，啓動的時候沒有報錯。而後ps -ef|grep php沒有發現進程起來，lsof -i:9000發現端口也沒有起來。
查看日誌，發現系統所容許打開的文件數超過了預約設置。

[root@i-v5lmgh7y etc]# /usr/local/php/sbin/php-fpm
[root@i-v5lmgh7y etc]# ps -ef|grep php
[root@i-v5lmgh7y etc]#lsof -i:9000
[root@i-v5lmgh7y etc]#

查看錯誤日誌發現問題：
[root@i-v5lmgh7y log]# tail -f php-fpm.log
[15-Nov-2015 23:53:15] NOTICE: fpm is running, pid 18277
[15-Nov-2015 23:53:15] ERROR: failed to prepare the stderr pipe: Too many open files (24)
[15-Nov-2015 23:53:16] NOTICE: exiting, bye-bye!
[15-Nov-2015 23:53:59] NOTICE: fpm is running, pid 18855
[15-Nov-2015 23:53:59] ERROR: failed to prepare the stderr pipe: Too many open files (24)
[15-Nov-2015 23:54:00] NOTICE: exiting, bye-bye!

發現是系統容許打開的文件數超了預約的設置。須要調大這個值：
[root@i-v5lmgh7y etc]# ulimit -n
1024
[root@i-v5lmgh7y etc]# ulimit -n 65535    //臨時解決辦法
[root@i-v5lmgh7y etc]# ulimit -n
65535


永久解決辦法：
在/etc/security/limits.conf文件底部添加下面四行內容：
[root@i-v5lmgh7y etc]# cat /etc/security/limits.conf
.........
# End of file
* soft nproc unlimited
* hard nproc unlimited
* soft nofile 65535
* hard nofile 65535

而後再次啓動php-fpm程序，9000端口就能正常啓動了
[root@i-v5lmgh7y etc]# /usr/local/php/sbin/php-fpm
[root@i-v5lmgh7y etc]# ps -ef|grep php
root 21055 1 0 00:12 ? 00:00:00 php-fpm: master process
(/usr/local/php/etc/php-fpm.conf)
nobody 21056 21055 0 00:12 ? 00:00:00 php-fpm: pool www
nobody 21057 21055 0 00:12 ? 00:00:00 php-fpm: pool www

===============下面梳理幾個常見的php不恰當配置引起的問題=================

1）request_terminate_timeout的值若是設置爲0或者過長的時間，可能會引發file_get_contents的資源問題。
若是訪問請求的遠程資源反應過慢，php-cgi進程就會一直卡在那裏不會超時。雖然php.ini文件裏面max_execution_time能夠設置PHP腳本的最大執行時間，可是，在php-cgi(php-fpm) 中該參數不會起效。真正可以控制PHP腳本最大執行時間的是php-fpm.conf配置文件中的request_terminate_timeout參數。

request_terminate_timeout默認值爲0秒，也就是說，PHP腳本會一直執行下去。這樣當全部的php-cgi進程都卡住時，這臺Nginx+PHP的WebServer已經沒法再處理新的PHP請求了，Nginx 將給用戶返回「502 Bad Gateway」。
修改該參數，設置一個PHP腳本最大執行時間是必要的，可是治標不治本。例如改爲30s，若是發生訪問獲取網頁內容較慢的狀況，這就意味着150個php-cgi進程，每秒鐘只能處理5個請求，WebServer一樣很難避免」502 Bad Gateway」。

解決辦法是request_terminate_timeout設置爲10s或者一個合理的值。

2）max_requests參數配置不當，可能會引發間歇性502錯誤
設置每一個子進程重生以前服務的請求數. 對於可能存在內存泄漏的第三方模塊來講是很是有用的. 
若是設置爲0，則一直接受請求，等同於php_fcgi_max_requests環境變量。默認值爲 0.
好比：pm.max_requests = 1000  這個配置的意思是，當一個 php-cgi 進程處理的請求數累積到500個後，自動重啓該進程。

可是爲何要重啓進程呢？
通常在項目中，多多少少都會用到一些PHP的第三方庫，這些第三方庫常常存在內存泄漏問題，若是不按期重啓php-cgi進程，勢必形成內存使用量不斷增加。所以php-fpm做爲php-cgi的管理器，提供了這麼一項監控功能，對請求達到指定次數的php-cgi進程進行重啓，保證內存使用量不增加。正是由於這個機制，在高併發的站點中，常常致使502錯誤，
目前解決方法是，把這個值儘可能設置大些，儘量減小php-cgi從新SPAWN的次數，同時也能提升整體性能。在實際的生產環境中發現，內存泄漏若是不明顯，能夠將這個值設置得很是大（好比204800）。要根據本身的實際狀況設置這個值（好比咱們線上設置1024），不能盲目地加大。
話說回來，這套機制目的只爲保證php-cgi不過度地佔用內存，爲什麼不經過檢測內存的方式來處理呢？經過設置進程的峯值內在佔用量來重啓php-cgi進程，會是更好的一個解決方案。

3）php-fpm的慢日誌，debug及異常排查神器
request_slowlog_timeout設置一個超時的參數，slowlog設置慢日誌的存放位置

==========php報錯日誌：PHP Deprecated:Automatically populating $HTTP_RAW_POST_DATA is deprecated=========

以前將線上php服務升級到5.6.x版本後，php-error.log報出錯誤：
PHP Deprecated: Automatically populating $HTTP_RAW_POST_DATA is deprecated
緣由：
上面的報錯意思是「自動變量$HTTP_RAW_POST_DATA已過期（deprecated）」
這個問題和PHP版本有關係,PHP5.6以後的高版本都已廢棄了$HTTP_RAW_POST_DATA這個全局變量設置，可使用 php://input 替代 $HTTP_RAW_POST_DATA。
使用always_populate_raw_post_data會致使在填充$HTTP_RAW_POST_DATA時產生E_DEPRECATED 錯誤。 
設置always_populate_raw_post_data 爲-1來體驗新的行爲，由於這樣會強制 $HTTP_RAW_POST_DATA 未定義，因此也不會致使 E_DEPRECATED的錯誤） 來體驗新的行爲。

解決方法： 
修改php.ini配置文件：
[root@dev-new-test etc]# vim php.ini
........
; Always populate the $HTTP_RAW_POST_DATA variable.
;always_populate_raw_post_data = On
always_populate_raw_post_data = -1
.......

而後重啓php服務便可！

===================phpinfo.php信息泄露漏洞===================

修復:
若無須要能夠將一些php的危險函數禁用，打開/etc/php.ini文件，查找到 disable_functions，添加需禁用的如下函數名：
[root@localhost ~]# vim /usr/local/php/etc/php.ini
disable_functions = phpinfo,eval,passthru,exec,system,chroot,scandir,chgrp,chown,shell_exec,proc_open,proc_get_status,ini_alter,ini_alter,ini_restore,dl,pfsockopen,openlog,syslog,readlink,symlink,popepassthru,stream_socket_server,fsocket,fsockopen

expose_php = Off        //隱藏版本號等信息

===============php文件修改後，訪問這個文件不會當即更新內容，而是過一下子纔回更新=============

緣由是php啓動了opcache的模塊(php的代碼優化和加速模塊)！執行php-config命令能夠看到php編譯安裝時跟了--enable-opcache參賽，直接訪問以下的php的測試文件：
＃ cat test.php
<?php
phpinfo()
?>

能夠看到界面中的「Zend OPcache」模塊顯示下面兩行，表示opcache被啓用了！
Opcode Caching  Up and Running
Optimization    Enabled

[root@iZwz96p8207vmn7amyxvw6Z ~]# cat /usr/local/php/etc/php.ini|grep opcache
[opcache]
;opcache.enable=0
;opcache.enable_cli=0
;opcache.memory_consumption=64
;opcache.interned_strings_buffer=4
;opcache.max_accelerated_files=2000
;opcache.max_wasted_percentage=5
;opcache.use_cwd=1
;opcache.validate_timestamps=1
;opcache.revalidate_freq=2
;opcache.revalidate_path=0
;opcache.save_comments=1
;opcache.load_comments=1
;opcache.fast_shutdown=0
;opcache.enable_file_override=0
;opcache.optimization_level=0xffffffff
;opcache.inherited_hack=1
;opcache.dups_fix=0
;opcache.blacklist_filename=
;opcache.max_file_size=0
;opcache.consistency_checks=0
;opcache.force_restart_timeout=180
;opcache.error_log=
;opcache.log_verbosity_level=1
;opcache.preferred_memory_model=
;opcache.protect_memory=0
; opcache.validate_permission=0
; opcache.validate_root=0

[root@iZwz96p8207vmn7amyxvw6Z ~]# /usr/local/php/bin/php -m
........

[Zend Modules]
Zend OPcache
the ionCube PHP Loader (enabled) + Intrusion Protection from ioncube24.com (unconfigured)

這就致使了php文件修改後，在瀏覽器裏訪問不會立馬生效，須要過30秒左右才生效！由於有opcache緩存的緣由！

解決辦法：
在php文件內容的前面添加清理opcache的函數，即opcache_reset();  以下：
[root@iZwz96p8207vmn7amyxvw6Z itime]# cat test.php 
<?php
   opcache_reset();                      //這一行就是清理opcache緩存
   echo  'hjhjhjhjhjh';
?>

這樣訪問test.php文件，當它的內容更新時，在新的瀏覽器頁面裏打開就是更新後的內容了。
若是在老頁面裏繼續訪問，第一次刷時清理緩存，第二次刷新就是更新後的內容了！