我嘗試在 StackOverflow 上詢問但沒有成功，所以我希望這個社區可以幫助我找到這個問題。我們有一個網路應用程序，公司中的許多人都需要訪問。有時，網路應用程式似乎會停止回應請求。
例如，如果資源索引頁面（例如訂單表）在中斷期間嘗試刷新資源列表，它將透過 API 請求數據，但該請求在一段時間後會默默失敗。由於一次向公司幾乎每個人發出持續幾分鐘的長期請求，該應用程式變得無法訪問，但在此中斷/遲緩期間從另一個網路（例如行動數據）訪問該應用程式可以正常工作。在此期間其他網站似乎也沒有受到影響。
瀏覽器網路標籤顯示請求在 20-40 秒後失敗，但沒有狀態代碼。選擇請求時的狀態文字為 failed net::ERR_CONNECTION_TIMED_OUT。似乎當您在處理請求時未單擊該請求並稍後打開詳細資訊時，計時選項卡會顯示它卡在“停滯”階段。但是，如果您在處理請求詳細信息時打開請求詳細信息，它會說它卡在初始連接階段。這使得請求詳細資訊的計時標籤看起來不可靠，因為它顯示的內容似乎取決於我在處理請求時是否正在檢查請求。
伺服器設定：
在此期間，伺服器似乎沒有顯示出嚴重過載 - CPU/記憶體使用率最多為 30%。該伺服器在 Digital Ocean Droplet 上運行，並使用 nginx 託管 Laravel 應用程式。
我考慮/嘗試過的： 公司連接來自同一 IP。但是，雖然應用程式本身確實啟用了限制，但它綁定到用戶 ID，返回「嘗試次數過多」錯誤訊息和 429 狀態代碼。如果這是限制的情況，則不應在應用程式層級進行限制，因為可以透過錯誤訊息和狀態代碼來識別限制。
我嘗試檢查 nginx 配置以查找啟用的任何限制，但似乎沒有明確啟用，除非 nginx 強制執行某種預設設定。但即使啟用 nginx 也應該回傳 429/503 據我所讀的內容。但在我們的例子中，似乎沒有回傳錯誤或程式碼。
我嘗試聯繫 DigitalOcean 和該公司的 ISP，他們都聲稱沒有使用任何類型的節流/速率限制機制。公司網路管理員也表示，目前還沒有這樣的機制。
我可以做什麼來調試/調查問題的根源？據我了解，問題可能出在從 nginx 配置到 ISP 提供者限制的任何地方。我認為目前這是某種限制，但我可能錯過了一些東西。
答案1
使用診斷工具來識別基礎設施各個部分（nginx、Digital Ocean、內部網路）中的瓶頸或錯誤。記錄停電期間的數據以便稍後分析。
# nginx logs
tail -f /var/log/nginx/access.log
tail -f /var/log/nginx/error.log
# Network diagnostics (replace x.x.x.x with server IP)
traceroute x.x.x.x
mtr --report --report-cycles=10 x.x.x.x
# Laravel logs
tail -f /path/to/laravel/storage/logs/laravel.log
# Digital Ocean droplet metrics
# Check droplet metrics via Digital Ocean dashboard
這將幫助您找出問題是否出在您的 nginx 設定、Digital Ocean Droplet、內部網路或其他地方。日誌和網路診斷可以提供線索。
回覆評論
• 若要檢查是否有使用該tc指令套用的任何流量整形或限制規則，這可能會影響網路流量：
# Display all the traffic control (qdisc) settings on all interfaces:
tc qdisc show dev [interface-name]
# Example for eth0 interface:
tc qdisc show dev eth0
如果應用了特定的流量控制規則，它們將在此處列出。可以進一步分析它們，以確定它們是否導致了報告的逾時。