跨域请求超时本质是网络或脚本执行超时，非cors配置问题；需区分err_connection_timed_out（未连上）与预检后卡住（php执行超时），并同步调优web服务器、php-fpm及nginx超时参数。
PHP 跨域请求超时，本质是后端连接或响应超时，不是 CORS 配置问题
跨域请求超时，90% 的情况跟 Access-Control-Allow-Origin 这类头无关。浏览器报 net::ERR_CONNECTION_TIMED_OUT 或 Failed to fetch 且没发出去请求，说明根本没连上 PHP 服务；如果看到预检（OPTIONS）成功但后续 POST/GET 卡住，才可能是 PHP 脚本执行太久被中断。先分清是网络层超时，还是脚本执行超时。
检查并延长 PHP-FPM 或 Apache 的超时配置
PHP 本身没有“跨域超时”这个概念，超时由 Web 服务器或 PHP 运行时控制。常见组合下关键参数如下：
- Apache + mod_php：调整
Timeout指令（单位秒），默认 300，建议设为600或更高 - PHP-FPM：修改
request_terminate_timeout（硬性杀死），和request_slowlog_timeout（记录慢日志），两者都需在www.conf中设置，例如request_terminate_timeout = 600s - Nginx：必须同步调大
fastcgi_read_timeout和proxy_read_timeout（如果用了反向代理），否则 Nginx 会在 PHP 还没返回时就断开连接
改完记得重启对应服务：systemctl restart php-fpm、systemctl restart nginx 或 apachectl graceful。
PHP 脚本内避免阻塞，用 set_time_limit(0) 要谨慎
set_time_limit(0) 确实能禁用脚本执行时间限制，但它只对 CLI 和部分 SAPI 生效，在 PHP-FPM 下可能被 request_terminate_timeout 强制覆盖，反而造成不一致行为。更稳妥的做法是：
立即学习“PHP免费学习笔记（深入）”；
- 确认业务是否真需要长连接 —— 大文件上传、批量导出等场景应改用异步任务（如队列 + WebSocket 回推），而不是拖长 HTTP 请求
- 若必须同步处理，优先优化逻辑：比如用
yield分块处理数据，配合ob_flush()+flush()输出进度，让前端感知“还在跑” - 避免在脚本中调用未设超时的外部 API（如
file_get_contents($url)），务必显式传stream_context_create(['http' => ['timeout' => 30]])
CORS 头本身不会导致超时，但错误写法会干扰调试
加了 Access-Control-Allow-Origin: * 后仍超时？那它不是原因，只是你误判了问题方向。真正容易踩的坑是：
- 在响应体已输出后才写 CORS 头 → 报
Cannot modify header information，脚本崩溃，看起来像“卡住” - 对 OPTIONS 预检返回了
Content-Type: application/json，但没给空响应体，某些客户端会拒绝继续 - 把
Access-Control-Max-Age设得极大（如 31536000），结果缓存了错误的预检结果，掩盖了后续真实超时
验证是否真由 CORS 引发问题，最直接方式：关掉浏览器 CORS 检查（仅测试用，chrome --disable-web-security --user-data-dir=/tmp），如果依然超时，问题一定不在头字段。
超时问题最难缠的地方，往往在于多层超时叠加 —— Nginx 断了，PHP-FPM 还在等，而你只盯着 PHP 代码里的 sleep(10)。逐层确认谁先喊停，比盲目加 set_time_limit 有用得多。
