PHP调用Ollama超时本质是PHP执行限制与cURL网络等待叠加所致，需同步调整set_time_limit(600)、curl_setopt($ch, CURLOPT_TIMEOUT, 600)及反向代理超时，并预加载模型、启用流式响应优化。
PHP 8.0 调用 Ollama（如通过 cURL 或 file_get_contents 请求本地 http://localhost:11434）时出现执行超时，本质是“PHP脚本等不到Ollama响应就自己终止了”。这不是Ollama的问题，而是PHP默认30秒限制 + 网络等待叠加导致的。解决需分两层：PHP自身执行时间、以及网络请求等待时间。
调整PHP脚本最大执行时间
确保PHP允许脚本运行足够久，尤其Ollama推理可能耗时几十秒甚至更长：
-
推荐方式：在脚本开头调用
set_time_limit(600)（设为600秒即10分钟），该函数会重置计时器，且无需服务器权限；传入0表示取消限制（生产环境慎用） - 若需全局生效，修改
php.ini中的max_execution_time = 600，然后重启 PHP-FPM 或 Web 服务 - 也可用
ini_set('max_execution_time', '600')，但需确认该指令未被禁用（max_execution_time属于INI_ALL，PHP 8.0+ 支持运行时修改）
设置cURL请求超时（关键！）
Ollama接口响应慢，真正卡住的是网络层。仅延长PHP执行时间不够，必须显式控制cURL的等待行为：
- 使用
curl_setopt($ch, CURLOPT_TIMEOUT, 600)—— 整个请求生命周期上限（含DNS、连接、发送、接收） - 同时设置
curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, 10)—— 连接阶段最多等10秒，避免卡在无法建连上 - 若Ollama返回流式响应（如
/api/chat的 SSE），还需加curl_setopt($ch, CURLOPT_LOW_SPEED_LIMIT, 1)和curl_setopt($ch, CURLOPT_LOW_SPEED_TIME, 30)防止因传输缓慢被中断
同步检查Web服务器与反向代理超时
如果你走 Nginx/Apache 访问 PHP，而PHP再调Ollama，中间存在多级超时链：
立即学习“PHP免费学习笔记（深入）”；
-
Nginx：检查
fastcgi_read_timeout（PHP-FPM场景）或proxy_read_timeout（反代PHP入口），应 ≥ PHP的max_execution_time，例如设为600 -
PHP-FPM：确认
request_terminate_timeout未设为过短值（如30秒），否则会强杀进程，PHP层设置无效 - 宝塔用户注意：站点设置中“最大脚本运行时间”优先级高于全局 php.ini，务必在此处也设为600
优化Ollama调用逻辑（治本）
单纯延长超时只是兜底，实际应减少等待：
- 避免在HTTP请求中同步等待Ollama完成——改用异步任务队列（如Redis + Worker）处理推理，PHP只返回任务ID
- 对大模型请求，启用Ollama的
stream: true并配合curl_setopt($ch, CURLOPT_WRITEFUNCTION, ...)边收边处理，防止内存积压和单次阻塞过久 - 确认Ollama模型已预加载（
ollama run llama3后再调用），避免首次请求触发拉取+加载，耗时数分钟 - 检查本地资源：Ollama是否在低配机器上运行？GPU未启用？可用内存不足会导致推理极慢
