12.3. 识别 API 请求问题

登录正在运行网关的计算机。如果此操作失败，您的网关服务器可能会停机。

登录后，检查 NGINX 进程是否正在运行。为此，请运行 ps ax | grep nginx 或 htop。

如果您看到列表中看到 nginx master process 和 nginx worker process，则代表 NGINX 正在运行。

以下是您可能在网关日志中看到的一些常见错误，例如在 error.log 中：

如果您使用 NGINX 作为 API 网关，当网关无法联系 3scale 时，nginx 错误日志中会显示以下消息：

2015/11/20 11:33:51 [error] 3578#0: *1 upstream timed out (110: Connection timed out) while connecting to upstream, client: 127.0.0.1, server: , request: "GET /api/activities.json?user_key=USER_KEY HTTP/1.1", subrequest: "/threescale_authrep", upstream: "https://54.83.62.186:443/transactions/authrep.xml?provider_key=YOUR_PROVIDER_KEY&service_id=SERVICE_ID&usage[hits]=1&user_key=USER_KEY&log%5Bcode%5D=", host: "localhost"

在这里，记录下上游值。此 IP 对应于 3scale 产品解析到的 IP 地址之一。这意味着到达 3scale 存在问题。您可以通过调用 nslookup 进行反向 DNS 查找来检查 IP 的域。

例如，由于 API 网关无法访问 3scale，这并不表示 3scale 已关闭。其中一个最常见的原因是防火墙规则阻止 API 网关连接到 3scale。

网关和 3scale 之间可能存在网络问题，可能会导致连接超时。在这种情况下，您应该执行对 通用连接问题进行故障排除 的步骤，以确定问题所在的位置。

要排除网络问题，请使用 traceroute 或 MTR 来检查路由和数据包传输。您也可以从能够连接到 3scale 和 API 网关并比较输出的计算机运行相同的命令。

此外，若要查看 API 网关和 3scale 之间发送的流量，只要您临时切换为 3scale 产品(su1.3scale.net)的 HTTP 端点，就可以使用 tcpdump。

确保已将 resolver 指令添加到 nginx.conf 中。

例如，在 nginx.conf 中：

http {
  lua_shared_dict api_keys 10m;
  server_names_hash_bucket_size 128;
  lua_package_path ";;$prefix/?.lua;";
  init_by_lua 'math.randomseed(ngx.time()) ; cjson = require("cjson")';

  resolver 8.8.8.8 8.8.4.4;

您可以将 Google DNS（8.8.8.8 和 8.8.4.4）替换为您首选的 DNS。

要从 API 网关检查 DNS 解析，请按指定解析器 IP 调用 nslookup：

nslookup su1.3scale.net 8.8.8.8
;; connection timed out; no servers could be reached

上面的例子显示了如果无法到达 Google DNS，则返回的响应。如果出现这种情况，您必须更新解析器 IP。您可能还会在 nginx error.log 中看到以下警报：

2016/05/09 14:15:15 [alert] 9391#0: send() failed (1: Operation not permitted) while resolving, resolver: 8.8.8.8:53

最后，运行 dig any su1.3scale.net 以查看 3scale 服务管理 API 当前运行的 IP 地址。请注意，这不是 3scale 可能使用的整个 IP 地址范围。一些可能因为容量原因而被交换和移出。此外，未来您可以为 3scale 服务添加更多域名。对于这一点，您应该始终针对集成期间为您提供的特定地址进行测试（如果适用）。

如果要检查 API 网关是否要进行 3scale 来满足故障排除的需要，将以下代码片段添加到 3scale authrep nginx.conf（/threescale_authrep 用于 API Key，App\_id 验证模式）

body_filter_by_lua_block{
  if ngx.req.get_headers()["X-3scale-debug"] == ngx.var.provider_key then
    local resp = ""
    ngx.ctx.buffered = (ngx.ctx.buffered or "") .. string.sub(ngx.arg[1], 1, 1000)
    if ngx.arg[2] then
      resp = ngx.ctx.buffered
    end

    ngx.log(0, ngx.req.raw_header())
    ngx.log(0, resp)
  end
}

当发送 X-3scale-debug 标头 时，此片段会将以下额外日志记录添加到 nginx error.log 中，例如 curl -v -H 'X-3scale-debug:YOUR_PROVIDER_KEY' -X GET "https://726e3b99.ngrok.com/api/contacts.json?access_token=7c6f24f5"

这会生成以下日志条目：

2016/05/05 14:24:33 [] 7238#0: *57 [lua] body_filter_by_lua:7: GET /api/contacts.json?access_token=7c6f24f5 HTTP/1.1
Host: 726e3b99.ngrok.io
User-Agent: curl/7.43.0
Accept: */*
X-Forwarded-Proto: https
X-Forwarded-For: 2.139.235.79

 while sending to client, client: 127.0.0.1, server: pili-virtualbox, request: "GET /api/contacts.json?access_token=7c6f24f5 HTTP/1.1", subrequest: "/threescale_authrep", upstream: "https://54.83.62.94:443/transactions/oauth_authrep.xml?provider_key=REDACTED&service_id=REDACTED&usage[hits]=1&access_token=7c6f24f5", host: "726e3b99.ngrok.io"
2016/05/05 14:24:33 [] 7238#0: *57 [lua] body_filter_by_lua:8: <?xml version="1.0" encoding="UTF-8"?><error code="access_token_invalid">access_token "7c6f24f5" is invalid: expired or never defined</error> while sending to client, client: 127.0.0.1, server: pili-virtualbox, request: "GET /api/contacts.json?access_token=7c6f24f5 HTTP/1.1", subrequest: "/threescale_authrep", upstream: "https://54.83.62.94:443/transactions/oauth_authrep.xml?provider_key=REDACTED&service_id=REDACTED&usage[hits]=1&access_token=7c6f24f5", host: "726e3b99.ngrok.io"

第一个条目(2016/05/05 14:24:33 [] 7238#0: *57 [lua] body_filter_by_lua:7:)显示发送到 3scale 的请求标头，本例中为：Host, User-Agent, Accept, X-Forwarded-Proto 和 X-Forwarded-For。

第二个条目(2016/05/05 14:24:33 [] 7238#0: *57 [lua] body_filter_by_lua:8:)从 3scale 打印出响应，本例中为 <error code="access_token_invalid">access_token "7c6f24f5" is invalid: expired or never defined</error>。

两者都将打印出原始请求(GET /api/contacts.json?access_token=7c6f24f5)和 subrequest 位置(/threescale_authrep)以及上游请求（upstream: "https://54.83.62.94:443/transactions/threescale_authrep.xml?provider_key=REDACTED&service_id=REDACTED&usage[hits]=1&access_token=7c6f24f5"） 通过这个最后一个值，您可以查看 3scale IP 中的哪些已被解决，以及向 3scale 发出的确切请求。

3scale 也可能可用，但会向您的 API 网关返回错误，防止调用进入您的 API。尝试直接在 3scale 中发出授权调用并检查响应。如果遇到错误，请检查 #troubleshooting-api-error-codes[Error Codes] 部分以查看问题所在。

您还可以通过调用 X-3scale-debug 标头来打开 3scale 调试标头，例如：

curl -v -X GET "https://api.example.com/endpoint?user_key" X-3scale-debug:YOUR_SERVICE_TOKEN

这将返回带有 API 响应的以下标头：

X-3scale-matched-rules: /, /api/contacts.json
< X-3scale-credentials: access_token=TOKEN_VALUE
< X-3scale-usage: usage[hits]=2
< X-3scale-hostname: HOSTNAME_VALUE

您还可以检查管理门户中的集成错误，以检查是否报告流量到 3scale。请参阅 https://YOUR_DOMAIN-admin.3scale.net/apiconfig/errors。

集成错误的原因之一是在标头中发送凭据，并附带 underscores_in_headers 指令未在 server 块中启用。

尝试将浏览器定向到网关服务器的 IP 地址（或域名）。如果此操作失败，请确保您已在相关端口上打开防火墙。

如果可能，尝试使用前面概述的方法之一（telnet、curl 等）从客户端连接到 API 网关。 如果连接失败，问题在于这两者之间的网络。

否则，您应该继续对 API 发出调用的客户端进行故障排除。

如果请求没有返回预期结果，请使用不同的 HTTP 客户端进行测试。例如，如果您使用 Java HTTP 客户端调用 API，您会看到错误，使用 cURL 进行交叉检查。

您还可以通过客户端和网关之间的代理调用 API，以捕获客户端发送的确切参数和标头。

使用 Wireshark 等工具来查看客户端发出的请求。这样，您可以识别客户端是否在调用 API 以及请求的详细信息。