我尝试在 StackOverflow 上提问，但没有成功，所以我希望这个社区能帮我找到这个问题。我们有一个 Web 应用程序，公司里很多人都需要访问。有时 Web 应用程序似乎会停止响应请求。
例如，如果资源索引页（例如订单表）在停机期间尝试刷新资源列表，它将通过 API 请求数据，但请求会在一段时间后悄无声息地失败。该应用程序无法访问，因为公司几乎所有人同时发出的请求持续了几分钟，但在此停机/低迷期间从其他网络（例如移动数据）访问该应用程序是可行的。在此期间，其他网站似乎也没有受到影响。
浏览器网络选项卡显示请求在 20-40 秒后失败，但没有状态代码。选择请求时的状态文本为失败 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
如果应用了特定的流量控制规则，它们将在此处列出。可以进一步分析它们以确定它们是否导致了所报告的超时。