为何独立API控制器可通过Identity Server基础URL直接访问？

这种向5000端口直接发送请求拿到31000端口API响应的现象，完全不属于Identity Server 4或ASP.NET Core框架的设计预期，是开发或部署环节存在的配置错误，不存在“跨应用自动解析其他服务控制器”的框架逻辑。

常见的触发原因 #

• 控制器被误引入Identity Server项目编译产物
  不少开发者在测试IS4鉴权流程时，会将API项目的ValuesController以链接文件的方式添加到IS4项目目录，方便快速验证无鉴权场景的接口连通性，后续忘记移除该引用。这种情况下控制器会被编译进IS4的程序集，被IS4自身的路由系统直接识别处理，你拿到的响应完全来自IS4进程本身，和31000端口的API没有任何关联。
• 进程与端口绑定配置错误
  如果启动项目时没有正确分离两个应用的Kestrel实例，比如将API项目的Startup类直接导入IS4的宿主启动逻辑中，实际两个应用的所有路由都会被挂载到5000端口的Kestrel实例上，31000端口的监听从未真正启动。这种情况下你以为是两个独立运行的应用，实际是同一个进程内挂载了两套接口路由。
• 隐式配置了请求转发规则
  部分本地调试教程会在IS4的开发环境中添加简易反向代理规则解决跨域问题，规则可能默认将所有/values路径的请求直接转发到31000端口的API地址。这种情况下IS4作为代理服务器帮你请求了API资源，再把响应返回给你，本质还是IS4收到了5000端口的请求，内部完成了转发，并非路由无匹配的跨应用无授权访问。

正确的框架设计预期 #

按照ASP.NET Core的基础设计逻辑，两个完全独立的应用会各自维护独立的路由表、依赖注入容器和端口监听规则。5000端口的进程收到请求时，如果自身路由表中没有对应路径的匹配项、也没有配置请求转发逻辑，必然会返回404状态码，不可能无权限访问到其他端口进程下的控制器资源。

快速定位问题的验证操作：

1. 完全停止31000端口运行的API项目
2. 重新向5000端口发送GET /values请求
3. 根据返回结果定位具体问题：
   • 仍能正常返回预期响应：说明控制器已被编译进IS4程序集，属于控制器误引入的问题
   • 返回502/503连接错误：说明IS4中配置了请求转发规则
   • 停掉API后31000端口仍可正常访问：说明端口绑定配置错误，两个应用并未独立运行

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