跨域问题排查实战：一个困扰两天的线上问题

"老师,我们的新功能上线后接口突然调不通了！"周一早上,实习生小李急匆匆地跑来找我。我打开监控面板,发现生产环境的错误日志突然暴增,全是 CORS 相关的报错。作为技术导师,我立即和小李一起开始排查这个问题。

说实话,跨域问题在本地开发时很常见,但在生产环境突然出现还是第一次。更让人困惑的是,这些接口在上周五还是好好的,周末发版后就出问题了。带着这些疑问,我们开始了一场"破案"之旅。

问题的表象

首先,我让小李演示了一下具体的错误场景。在浏览器控制台里,我们看到了这样的报错：

Access to XMLHttpRequest at 'https://api.example.com/data'
from origin 'https://www.example.com' has been blocked by CORS policy:
No 'Access-Control-Allow-Origin' header is present on the requested resource.

"奇怪了,我们的 CORS 配置明明一直都在啊。"小李一脸困惑。我们开始仔细梳理上周的发版内容：

// 上周的发版记录
const deployChanges = {
  frontend: {
    'feat: 新增数据分析页面': {
      api: 'https://api-analysis.example.com/v1',
      changes: ['新增数据大屏', '接入实时数据接口', '对接新的认证服务']
    }
  },
  backend: {
    'refactor: 服务架构调整': {
      changes: ['网关服务升级', '认证服务重构', '引入服务网格']
    }
  }
}

深入排查

通过对比测试环境和生产环境的请求,我们发现了一些线索：

// 测试环境的请求（正常）
fetch('https://api-test.example.com/data', {
  headers: {
    Authorization: 'Bearer token123',
    'Content-Type': 'application/json'
  }
}).then(response => {
  console.log('响应头:', response.headers)
  // Access-Control-Allow-Origin: https://www.example.com
  // Access-Control-Allow-Methods: GET, POST, OPTIONS
  // Access-Control-Allow-Headers: Content-Type, Authorization
})

// 生产环境的请求（异常）
fetch('https://api.example.com/data', {
  headers: {
    Authorization: 'Bearer token123',
    'Content-Type': 'application/json'
  }
}).then(response => {
  console.log('响应头:', response.headers)
  // 缺少 CORS 相关的响应头
})

通过进一步分析,我们发现问题出在新引入的服务网格配置上：

# 原来的网关配置
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: api-gateway
spec:
  hosts:
    - 'api.example.com'
  gateways:
    - api-gateway
  http:
    - route:
        - destination:
            host: api-service
            port:
              number: 80
      # 这里缺少了 CORS 策略配置

问题的根源

原来是这样！在服务架构调整时,我们将原来网关层的 CORS 配置迁移到了服务网格,但是漏掉了一些细节：

1. 预检请求(OPTIONS)没有正确配置
2. 多级域名的跨域配置缺失
3. 认证头信息没有加入允许列表

解决方案

知道问题后,解决方案就比较清晰了：

# 修复后的配置
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: api-gateway
spec:
  hosts:
    - 'api.example.com'
    - 'api-analysis.example.com'
  gateways:
    - api-gateway
  http:
    - corsPolicy:
        allowOrigins:
          - exact: 'https://www.example.com'
          - regex: 'https://*.example.com'
        allowMethods:
          - GET
          - POST
          - OPTIONS
        allowHeaders:
          - Authorization
          - Content-Type
        maxAge: '24h'
      route:
        - destination:
            host: api-service
            port:
              number: 80

同时,我们在前端也增加了错误处理机制：

// utils/request.ts
class APIClient {
  private async request(url: string, options: RequestOptions) {
    try {
      const response = await fetch(url, {
        ...options,
        headers: {
          ...options.headers,
          'Content-Type': 'application/json'
        }
      })

      if (!response.ok) {
        // 处理 HTTP 错误
        throw new HTTPError(response.status, response.statusText)
      }

      return await response.json()
    } catch (error) {
      if (error instanceof HTTPError) {
        // 处理 HTTP 错误
        if (error.status === 0) {
          console.error('可能是跨域问题:', error)
          // 显示友好的错误提示
          notification.error({
            message: '网络请求失败',
            description: '请检查网络连接或联系技术支持'
          })
        }
      }
      throw error
    }
  }

  // 提供重试机制
  async requestWithRetry(url: string, options: RequestOptions, retries = 3) {
    for (let i = 0; i < retries; i++) {
      try {
        return await this.request(url, options)
      } catch (error) {
        if (i === retries - 1) throw error
        // 延迟重试
        await new Promise(resolve => setTimeout(resolve, 1000 * Math.pow(2, i)))
      }
    }
  }
}

预防措施

为了防止类似问题再次发生,我们建立了一套完整的测试机制：

// tests/cors.spec.ts
describe('CORS Configuration Tests', () => {
  const origins = ['https://www.example.com', 'https://admin.example.com', 'https://data.example.com']

  const endpoints = ['/api/v1/data', '/api/v1/analysis', '/api/v1/auth']

  origins.forEach(origin => {
    endpoints.forEach(endpoint => {
      it(`should allow CORS from ${origin} to ${endpoint}`, async () => {
        const response = await fetch(`https://api.example.com${endpoint}`, {
          method: 'OPTIONS',
          headers: {
            Origin: origin,
            'Access-Control-Request-Method': 'POST',
            'Access-Control-Request-Headers': 'Content-Type,Authorization'
          }
        })

        expect(response.headers.get('Access-Control-Allow-Origin')).to.include(origin)
        expect(response.headers.get('Access-Control-Allow-Methods')).to.include('POST')
        expect(response.headers.get('Access-Control-Allow-Headers')).to.include('Authorization')
      })
    })
  })
})

经验总结

这次问题排查让我们学到了很多：

1. 架构 设计 更要特别注意配置迁移的完整性
2. 跨域配置要考虑全面,包括预检请求和各种场景
3. 要建立完善的测试机制,及早发现问题
4. 前端要有合适的错误处理机制

就像搬家时要仔细检查有没有遗漏重要物品一样,系统架构调整时也要特别注意配置的完整性。而且要像检查清单一样,把所有可能的场景都测试一遍。

写在最后

跨域问题虽然常见,但解决起来并不简单,特别是在复杂的微服务架构中。关键是要理解背后的原理,建立完善的测试机制,这样才能及时发现和解决问题。

有什么问题欢迎在评论区讨论,让我们一起提高技术水平！

如果觉得有帮助,别忘了点赞关注,我会继续分享更多实战经验~