我在Azure App Service中托管了一个.NET Core Web API，并在其前面拥有API管理。
我添加了API管理的IP，可以在我的应用服务中进入入口流量：
If i send a request without a subscription key to the API Management endpoint i get
{
"statusCode": 401,
"message": "Access denied due to missing subscription key. Make sure to include subscription key when making requests to an API."
}
When i add subscription key and send request through postman, it will just be infinitely loading unless i set a timeout.
我可以将请求直接发送到应用程序服务端点URL（通过将IP暂时添加到网络设置中允许的IP地址），并且效果很好，当我检查LogStream时，我可以看到我的请求在中间件中成功处理的日志。
但是，当我将请求发送到API管理端点时，中间件中的App Service LogStream中没有日志。
当我检查API管理中的日志时，我会发现此错误，这对我没有太大帮助：
Any idea what could cause this?也许我在设置应用程序服务 / API管理方面做了一些问题。
I have a .NET Core Web API hosted in Azure App Service, with API Management in front of it.
I have added the IP of API Management to be allowed in inbound traffic to my App Service:
If i send a request without a subscription key to the API Management endpoint i get
{
"statusCode": 401,
"message": "Access denied due to missing subscription key. Make sure to include subscription key when making requests to an API."
}
When i add subscription key and send request through postman, it will just be infinitely loading unless i set a timeout.
I can send requests directly to the App Service endpoint url (by temporarily adding my IP to allowed IP addresses in network settings) and it works perfectly fine, and when i check logstream i can see logs that my request was successfully handled in my middleware.
But when i send requests to the API Management endpoint, there are no logs in the App Service logstream from my middleware.
When i check the logs in API Management i find this error, which doesn't help me much:
Any idea what could cause this? Maybe i've done something wrong with how i've set up App Service / API Management.
发布评论
评论（1）
gh，发现了错误。我意外地将API管理设置中的“ Web Service URL”设置为API管理URL，而不是App Service URL，因此本质上是试图将请求发送给自己，也许导致无尽的循环。
Ugh, found the mistake. I had accidentally set the "Web service URL" in API Management settings to the API Management URL instead of the App service URL, so it was essentially trying to send requests to itself, perhaps resulting in an endless loop.