我们有一些超时让我抓狂，几乎没有负载（每分钟可能有几个人访问服务器）。
我们使用 nginx 将非 SSL 重定向到 SSL，终止 SSL，然后将请求反向代理到 haproxy，后者将其发送到我们的一个应用服务器。
我们的应用服务器运行的是 Passenger (rails) + nginx。我们有一个 mysql master + slave 和一个 memcached 实例，最近我们开始用它来进行一些查询。
下面是我在将请求传递给 haproxy 的 nginx 错误日志的第一层中看到的典型错误（详细信息已混淆）：
2012/02/25 06:42:15 [错误] 7838#0：*60797 上游读取响应标头时超时（110：连接超时），客户端：1.2.3.4，服务器：domain.com，请求：“GET /api/v1/some_route HTTP/1.1”，上游：“http://127.0.0.1:82/api/v1/some_route", 主机: "domain.com"
我不确定是 haproxy、passenger+nginx、rails 还是 memcached。一个经验数据点是它们似乎成群出现，也就是说，如果我们遇到一次超时，我们会看到其他几次超时，然后它们就会消失。
任何帮助都将不胜感激。很高兴发布任何配置或任何有帮助的内容。
答案1
（可能值得一提的是，我既不是 nginx 用户，也不是 rails 用户，所以这只是初步猜测，也许可以用一些想法来开启这个话题）
从您的日志条目的详细信息来看，似乎外部请求正在由服务器上的 nginx 在主机字符串为 domain.com" 的情况下内部转发到在 localhost:82 上运行的本地 haproxy 上？
如果是这样的话，那么我确实会寻求将 nginx 的日志条目与 haproxy 关联起来，即在 haproxy 日志中找到相同的请求。
鉴于我不了解 nginx，所以我猜测，我认为你需要确定这个 110 消息是否对应于 proxy_connect_timeout 或proxy_read_timeout，前者意味着 nginx 没有从 haproxy 收到任何响应（主机 A 发送 SYN，你的 localhost:82 丢弃了数据包），后者意味着它已连接但未发回任何数据（Syn-Syn-ack 确认，但流上没有数据）。
如果是后者，那么问题很可能出在您的 Web 堆栈中，您应该在 memcache 或 mysql 日志中查找相同的日志条目。
例如设置你的慢查询日志 my.conf 配置在 mysql 上查看日志文件中是否有与您的请求相对应的条目。我认为我的默认位置是在 /var/lib/mysql/slow.log 中，但我猜可能有一些自定义。
更一般地，在这些平台上，你已经创建了一个相当复杂的系统，拥有一些集中式日志记录基础设施来处理事件关联是有帮助的。我目前正在部署日志存储, 用于此类目的，显然还有 splunk 和 logblaze 作为商业替代品。
答案2
我遇到了一个问题，即 http 响应仅部分返回到我的浏览器。问题出在 nginx 的自动缓存上。我已将 nginx 安装到一个特殊目录中。我发现，如果我添加以下行
在http中proxy_cache_path /var/lib/nginx/proxy levels=1:2 keys_zone=my-cache:8m max_size=1000m inactive=600m; proxy_temp_path /var/cache/tmp;
并在位置 proxy_cache my-cache; proxy_cache_valid 200 302 60m; proxy_cache_valid 404 1m;
并更改了 tmp 和代理目录的权限，然后整个 http 响应被发送到我的浏览器