Swagger重定向到可用URL时报TypeError: failed to fetch错误如何解决

可行解决方案如下： #

1. 先修正URL构造笔误
   你当前拼接的OAuth授权链接中redirect_uri={redirect_uri}k末尾多了1个多余的k字符，首先删除该错误字符，避免Facebook校验回调地址失败。

2. 避开Swagger的调用限制
   Swagger UI内部通过fetch API发起请求，默认会自动跟随3xx重定向，而Facebook OAuth授权页设置了X-Frame-Options: DENY禁止被嵌入iframe，同时跨域规则拦截了fetch的跨域访问请求，才会返回TypeError:Failed to fetch错误，这属于Swagger的特性限制，并非接口逻辑问题。
   直接在浏览器地址栏输入你的接口地址（如https://你的服务地址/login）测试即可，不要通过Swagger调用该重定向接口。

3. 兼容API调用场景的调整方案
   如果需要同时支持前端API调用和浏览器直接访问，可以调整接口逻辑，根据请求头判断返回形式：

[Route("login")]
public async Task<IActionResult> Authorize ()
{
    // 修正后的授权链接
    var url = "https://www.facebook.com/v2.6/dialog/oauth?client_id={appID}&state={state}&response_type=code&redirect_uri={redirect_uri}&scope=email";
    // 判断是否为API请求
    if (Request.Headers.Accept.Any(val => val.Contains("application/json")))
    {
        return Ok(new { redirect_url = url });
    }
    // 浏览器访问直接返回重定向
    return Redirect(url);
}

前端拿到返回的redirect_url后自行执行顶层页面跳转即可。

4. 校验OAuth配置正确性
   确认Facebook开发者后台配置的合法重定向地址，和你代码中{redirect_uri}占位符替换后的实际地址完全一致，包括协议、域名、端口、路径所有部分，不匹配会导致授权失败。

5. 反向代理配置校验
   如果服务部署在Nginx、IIS等反向代理后，确保代理层转发请求时保留了Host头和X-Forwarded-Proto、X-Forwarded-Host头，避免ASP.NET Core生成的重定向地址错误。

内容的提问来源于stack exchange，提问作者Tabris