php通过$_server['http_origin']获取跨域请求的origin头（需nginx配置fastcgi_pass_request_headers on），过滤options预检请求后，结合remote_addr、x_forwarded_for、请求方法及唯一id记录完整跨域上下文。
PHP里怎么捕获跨域请求的原始来源
跨域请求本身不会在 $_SERVER 中留下特殊标记，但关键信息藏在请求头里。真正能反映跨域来源的是 Origin 头，而不是 Referer（后者可能被浏览器省略或伪造）。
-
Origin是浏览器强制添加的跨域请求头，格式固定为https://example.com，不含路径和参数，可靠度高 - 用
getallheaders()或$_SERVER['HTTP_ORIGIN']获取，注意大小写：Apache 下是HTTP_ORIGIN，Nginx 需显式传递（如fastcgi_pass_request_headers on;） - 如果
Origin为空或为null，说明不是跨域请求（可能是同源 AJAX、curl 或表单提交）
记录日志时要避开 CORS 预检请求的干扰
浏览器对非简单请求会先发 OPTIONS 预检，它不携带业务数据，但会触发 PHP 脚本执行——如果不加判断，日志里就会混入大量无意义的 OPTIONS 记录。
- 在写日志前加判断：
if ($_SERVER['REQUEST_METHOD'] !== 'OPTIONS') - 预检请求通常没有
Content-Type: application/json或Authorization等业务头，可结合$_SERVER['CONTENT_LENGTH'] > 0过滤 - 不要在预检响应中写日志，否则会掩盖真实请求的上下文
把跨域上下文写进日志的实用字段组合
光记 Origin 不够，得把跨域调用链的关键节点串起来。建议至少记录以下字段：
-
Origin：发起方域名（用于识别调用方系统） -
Access-Control-Request-Method（如果是预检）或REQUEST_METHOD（实际请求） -
HTTP_AUTHORIZATION或HTTP_X_API_KEY（如有认证，便于关联账号） -
$_SERVER['REMOTE_ADDR']和$_SERVER['HTTP_X_FORWARDED_FOR']（注意代理穿透） - 加上唯一请求 ID（如
uniqid('', true)），方便后续查 Nginx / MySQL / Redis 日志联动
示例写法：
error_log(sprintf('[CORS] %s %s %s %s %s', $_SERVER['REQUEST_METHOD'], $_SERVER['HTTP_ORIGIN'] ?: '-', $_SERVER['HTTP_X_FORWARDED_FOR'] ?: $_SERVER['REMOTE_ADDR'], $_SERVER['REQUEST_URI'], uniqid('', true)), 3, '/var/log/php-cors.log');
立即学习“PHP免费学习笔记（深入）”；
为什么不能只靠浏览器开发者工具查跨域问题
开发者工具看到的“跨域失败”往往是最终结果，但真正卡点常在服务端中间层：Nginx 的 add_header Access-Control-Allow-Origin 覆盖了 PHP 设置、CDN 缓存了错误的 CORS 响应头、甚至某些 PHP 框架（如 Laravel）的中间件顺序导致 CORS 头未生效。
- PHP 日志里没出现对应
Origin，说明请求根本没进 PHP（被 Nginx 拦截或 4xx/5xx 返回） - 日志里有
Origin但浏览器仍报错，大概率是响应头缺失Access-Control-Allow-Credentials: true（当带 cookie 时必须显式设置）或Vary: Origin（CDN 场景下防止缓存污染） - 多个子域名共用 API 时，
Origin可能是https://a.example.com或https://b.example.com，别用硬编码白名单
跨域日志真正的价值不在“有没有”，而在“谁、什么时候、从哪来、带了什么头、走了哪条路由”。这些细节一旦漏掉，排查就只能靠猜。
