当 Microsoft 已经返回
code，浏览器却再次进入知行之桥登录页时，问题通常已经进入 OAuth 回调处理阶段。此时应优先检查 Callback URL、知行之桥访问入口、浏览器会话、基础 URL 和反向代理配置是否一致。本文结合 Email Receive 端口的 OAuth 工作方式，介绍如何判断故障阶段，并逐层缩小问题范围。
本文中的界面名称和配置路径以知行之桥 26.3 自托管版本为参考；其他版本或部署方式的界面可能略有不同。
问题场景
使用知行之桥 Email Receive 端口连接 Microsoft 邮箱时，常见的 OAuth 授权过程是：在端口中点击连接，进入 Microsoft 登录和授权页面。用户完成登录和授权后，浏览器会自动跳转到知行之桥生成的 Callback URL，并携带一次性 OAuth 授权码。
在一个典型问题中，用户已经完成 Microsoft 登录和授权同意，浏览器也携带授权码返回了类似下面的地址：
https://test.edi.com:8001/src/oauthCallback.rst?code=...&state=...&session_state=...
但知行之桥没有显示连接成功，而是出现以下情况之一：
- 跳转到
/login.rst，要求重新登录； - 返回
401 Unauthorized； - Email Receive 端口始终没有保存新的 OAuth 授权状态。
看到 URL 中已经有 code，很容易认为 Microsoft 已经返回了 token。实际上，这里的 code 只是一次性 OAuth 授权码。知行之桥还需要接收并处理该授权码，再调用 Access Token URL 换取 access token。如果回调没有被正确处理，这一步就不会发生。
Email Receive 的 OAuth 连接是怎样完成的
知行之桥 Email Receive 端口通过 IMAP 接收邮件，并支持 OAuth 2.0 认证。与 OAuth 相关的主要配置包括：
| 配置项 | 作用 |
|---|---|
| Auth URL | 将用户引导至 Microsoft 登录和授权页面 |
| Access Token URL | 使用授权码换取 access token |
| Client Id | 标识 Microsoft Entra ID 中注册的应用 |
| Client Secret | 用于验证 OAuth 应用身份 |
| Scope | 定义应用申请的邮箱访问权限 |
| Callback URL | Microsoft 完成授权后返回知行之桥的地址 |
完整流程可以分为两个阶段：
第一阶段：申请授权码
登录知行之桥
→ 在 Email Receive 中点击 Connect
→ 知行之桥生成授权地址
→ Microsoft 完成登录和授权
→ Microsoft 返回 code
第二阶段：用授权码换取 token
知行之桥接收 Callback 请求
→ 处理回调参数并恢复本次 OAuth 授权上下文
→ 调用 Access Token URL
→ 用 code 换取 token
→ 保存授权结果
→ Email Receive 连接完成
因此，"URL 中出现 code"只能证明第一阶段基本完成，不能证明知行之桥已经取得 token。
如何判断问题发生在哪个阶段
如果日志只出现以下内容：
Starting Auth. Type: GetOAuthAuthorizationURL
Auth Status: OAuth - Generating authorization URL
Authorization URL generated.
Finish Auth. Type: GetOAuthAuthorizationURL说明知行之桥成功生成了 Microsoft 授权地址。
如果已启用适当的日志级别，但随后没有出现回调处理、获取 access token 或连接成功的记录，同时浏览器又跳转到登录页，那么可以优先怀疑：
Microsoft 已返回授权码，但 Callback 请求可能没有顺利完成后续的 OAuth 处理。
此时不应优先检查 IMAP Host、邮箱密码或邮件下载配置，因为流程尚未运行到连接邮箱的阶段。更有价值的检查对象是 Callback URL、浏览器 Cookie、知行之桥登录会话和反向代理。
优先检查：登录入口与回调地址不一致
OAuth 授权开始前，浏览器已经登录知行之桥，并建立了相应的会话。Microsoft 完成授权后，浏览器访问 Callback URL。如果回调地址与最初访问知行之桥时使用的地址不一致，可能出现 Cookie 不满足发送条件、反向代理路由错误或应用会话无法延续等问题。
例如，操作人员通过下面的内部地址登录：
http://192.0.2.10:8001而系统生成的 Callback URL 是：
https://test.edi.com:8001/src/oauthCallback.rst这两个地址使用了不同的主机名和协议。即使它们最终指向同一台服务器，按域名限定的 Cookie 也不能直接从 IP 地址复用到正式域名；协议、端口或代理路由不一致，也可能使 Callback 请求进入与原访问入口不同的处理路径。最终表现可能是重新进入登录页或返回 401 Unauthorized。
为避免 Callback URL、反向代理路由和应用会话不一致，建议基础 URL、实际登录地址和 Redirect URI 使用相同的协议、主机名和端口：
https://test.edi.com:8001排查期间不要混用以下入口：
- HTTP 与 HTTPS；
- 公网域名与服务器 IP；
- 公网域名与内部服务器名；
- 不同端口；
localhost与正式访问域名。
需要注意：浏览器 Cookie 是否发送主要取决于 Domain、Path、Secure 和 SameSite 等属性，不能仅凭端口不同就判断 Cookie 一定缺失。这里要求统一端口，主要是为了确保访问入口、Callback URL 和代理路由保持一致。
第一步：统一知行之桥基础 URL
在知行之桥中进入：
系统设置 → 高级 → 附加设置 → 基础 URL将基础 URL 设置为实际对外访问地址，例如：
https://test.edi.com:8001知行之桥默认会根据当前网页请求生成应用中的公共端点。部署在 Nginx、负载均衡器或其他代理服务器之后时，内部请求的协议、主机名和端口可能与浏览器看到的地址不同。明确设置基础 URL，可以让系统持续生成正确的外部 Callback URL。
保存后重新打开 Email Receive 连接配置，确认 Callback URL 已变为：
https://test.edi.com:8001/src/oauthCallback.rst第二步：核对 Microsoft Redirect URI
在 Microsoft Entra ID 的应用注册中，将 Redirect URI 配置为知行之桥显示的完整 Callback URL：
https://test.edi.com:8001/src/oauthCallback.rst以下部分必须一致：
https协议；test.edi.com域名；8001端口；/src/oauthCallback.rst路径；- 路径大小写和结尾斜杠。
完成调整后，先退出旧的知行之桥会话，再通过 https://test.edi.com:8001 重新登录，并在同一浏览器会话中重新发起 OAuth 授权。
第三步：检查 Callback 请求有没有携带 Cookie
如果仍然跳转登录页，可以通过浏览器开发者工具继续定位：
- 按
F12打开开发者工具。 - 进入 Network。
- 重新执行一次 Microsoft OAuth 授权。
- 找到
/src/oauthCallback.rst?code=...请求。 - 检查 Request Headers 中的
Cookie。
为了保护账号安全，不要复制或公开完整的 code、token、Client Secret 或 Cookie 值。
Callback 请求没有携带知行之桥会话相关 Cookie
这通常指向浏览器侧的 Cookie 发送条件没有满足。建议检查：
- 发起授权时是否通过
https://test.edi.com:8001登录； - Cookie 的 Domain 和 Path 是否覆盖 Callback URL；
- Cookie 是否包含 Secure 属性，并且全程使用 HTTPS；
- Cookie 的 SameSite 策略是否允许在 Microsoft 返回的顶层导航请求中携带；
- Nginx 是否改写了 Host、协议、端口或 Cookie 属性。
Callback 已携带 Cookie，但仍然返回 401 或跳转登录页
这时不能再简单归因于浏览器没有发送 Cookie，需要继续检查 Cookie 对应的会话是否有效，以及代理和后端节点是否正确处理了请求：
- 登录会话是否已经过期；
- Nginx 是否将 Cookie 完整转发至知行之桥；
- 是否存在多个知行之桥后端节点；
- 多节点是否按照集群要求共享应用程序数据库和应用程序数据目录；
- 负载均衡器是否将请求转发到了预期的知行之桥实例。
这两种情况的处理方向不同，所以确认 Callback 请求是否携带会话相关 Cookie，是缩小问题范围的重要证据之一。
一套可复用的排查顺序
遇到同类问题时，可以按照下面的顺序处理：
- 确认回调 URL 中是否已经出现
code。 - 确认
code是授权码，而不是 access token。 - 检查知行之桥日志是否只完成了授权 URL 生成。
- 统一基础 URL、实际登录地址和 Microsoft Redirect URI。
- 退出旧会话，通过统一域名重新登录并重新授权。
- 在浏览器 Network 中检查 Callback 请求是否携带知行之桥会话相关 Cookie。
- 没有 Cookie 时，检查 Domain、Path、Secure、SameSite 和代理改写。
- 有 Cookie 仍失败时，检查会话过期、代理转发和多节点部署配置。
- 只有在使用 Windows/.NET 版且证据明确指向 SameSite Cookie 限制时，才评估 Web.Config 设置。调整前应确认产品版本、备份配置并评估 CSRF 风险；官方文档中的相关配置主要用于特定 SAML 2.0 兼容问题，并不是 Email Receive OAuth 的通用修复方案。
- 不要未经确认就将 OAuth Callback 后台路径开放为匿名访问。
如何确认问题已经解决
修复完成后，应看到以下结果：
- 操作人员始终通过
https://test.edi.com:8001访问知行之桥； - Email Receive 自动生成的 Callback URL 与 Microsoft Redirect URI 完全一致；
- Microsoft 授权后不再跳转
/login.rst； - Callback 请求不再返回
401 Unauthorized； - 知行之桥继续执行授权码换取 token 的步骤；
- Email Receive 显示 OAuth 连接成功；
- Add and Test 可以成功连接目标邮箱；
- 重新打开连接配置后，授权状态仍然有效。
总结
当 Microsoft OAuth 回调地址中已经出现 code，但知行之桥仍然跳转登录页时，最重要的判断是：Microsoft 已经完成登录和授权同意，并返回了授权码；问题大概率位于知行之桥接收回调、恢复本次授权上下文或换取 token 的阶段。
排查时应优先统一基础 URL、登录地址和 Redirect URI，然后通过浏览器 Network 判断 Callback 请求是否携带知行之桥会话相关 Cookie。结合 Callback 的响应状态、跳转链路和知行之桥日志，才能进一步判断问题来自浏览器 Cookie 策略、Nginx 转发、会话过期还是多节点部署配置。