在開發過程中，我們經常會碰到段錯誤等異常，這時我們需要有相應的機制來進行調試，特別是服務提供在線上時，面對大量的日志信息，合理的調試處理機制對於開發來說是一件非常重要的事情，幸好Nginx本身提供了很好的調試機制，主要包括以下幾個方面。
1、Core文件 默認情況下，編譯Nginx是帶上-g選項
這就意味着我們可以使用gdb進行調試，以跟蹤具體的錯誤原因。
使用Nginx自身帶有的兩個配置選擇就可以輕松配置，使它在Crash的時候產生Core文件。
worker_rlimit_core 50M; working_directory /tmp/;
其中worker_rlimit_core表示單個worker子進程所使用的Core文件大小的最大值。
working_directory表示Core文件存放的目錄，這里需要注意的一點是：該目錄nginx必須具有寫權限，屬主最好為Nginx的進程所有者。
當Nginx接收到信號結束處理時，就會產生相應的Core文件，我們就可以使用gdb來跟蹤查看具體的錯誤原因，如下： gdb /usr/local/nginx/sbin/nginx /tmp/core.xxx >>bt
2、調試模式 為了收集運行過程中的更多的信息
我們可以開啟調試模式運行Nginx，這在線上環境上收集具體的信息非常有用，我們只需要更新Nginx的配置文件，並重新加載，所有調試都會記錄在日志當中。
在編譯Nginx時加上–with-debug選項，並在配置文件中可以進行相應的配置以查看調用日志。
如下，在error_log中帶有debug選項，就會將相應的調試日志記錄下來： error_log /usr/local/nginx/logs/error.log debug; http { server { error_log /usr/local/nginx/logs/error.log debug; …. 因為日志占用的空間非常大，為了更加便於收集日志，Nginx還提供了一個配置選項用來設置只記錄特定連接的調試信息，這個配置選項為debug_connection。
比如我們只對來自192.168.1.1的連接進行調試信息的記錄，配置如下： events { debug_connection 192.168.1.1; }
這時我們可以通過tail -f /usr/local/nginx/logs/error.log -n 100|grep debug來進行日志過濾，查看相應的具體調試信息。
3、單進程非守護模式
Nginx有兩種進程模型可以選用，為單進程和多進程兩種，默認情況下使用的是多進程模型，Nginx以守護進程的方式運行，但為了方便開發和調試，Nginx提供了單進程模型和非守護進程的方式，由兩個配置選項來控制：
守護進程: daemon Syntax: daemon on | off Default: on
多進程模型配置： master_process Syntax: master_process on | off Default: on