装了 Ollama，命令行跑得好好的，一接网页前端就报跨域，或者模型每次都重新加载、跑起来比预期慢——问题多半不在模型，而在几个环境变量没配。这篇按「先能通、再稳、最后调优」的顺序走一遍，讲清 OLLAMA_ORIGINS 到底管什么、哪些配置改了才有用、哪些改了反而出问题。
装了 Ollama，命令行里跑得好好的，一接网页前端就报跨域；或者模型每问一句都像重新加载，等得人心烦。问题多半不在模型本身，而在几个环境变量没配对。这篇按「先能通、再稳、最后调优」的顺序走一遍，讲清 OLLAMA_ORIGINS 到底管什么、哪些配置改了才有用。
先说个前提：Ollama 的配置项说多不多，但每个都有它的生效位置。在错误的文件里改值，服务重启后照样读旧的，排查半天还以为是版本问题。所以下面每讲一个变量，都会顺带说清该写在哪儿、改完怎么验证。
先搞清 OLLAMA_ORIGINS 到底在拦谁
这个变量只影响浏览器发起的跨域请求。前端页面在 A 域名，Ollama 服务在 B 地址，浏览器会先发一个预检请求，服务端没回允许头，请求直接断。命令行、Python 脚本、后端服务直连一般不受影响——所以「curl 能通、网页不行」是最典型的信号。
值写的是来源，格式是协议加域名加端口，不是目标地址。最常见的写错方式就是把 Ollama 自己的地址填了进去，看着像配了，实际拦住的是自己。多个来源用逗号分隔，别用空格也别换行。
| 现象 | 大概率原因 | 先看哪里 |
|---|---|---|
| curl 正常，网页报跨域 | OLLAMA_ORIGINS 没配或来源写错 | 浏览器开发者工具的预检请求 |
| 换台机器完全连不上 | 监听地址只绑了本机回环 | Ollama 启动日志里的监听地址 |
| 配了来源还是被拦 | 来源带了多余路径或端口不一致 | 对比前端地址与配置值是否完全一致 |
| 内网临时能用，公网不行 | 通配符放开但有防火墙拦截 | 防火墙规则与服务监听范围 |
环境变量写在哪一格，决定它生不生效
Linux 走 systemd 时，改服务单元文件再重载，直接在终端 export 只对当前 shell 有效，重启服务就丢。Windows 和 macOS 图形版要在启动项或服务配置里写，改完必须完整重启进程，不是关窗口再开。容器部署时变量要传进容器，宿主上设了不等于容器里有。
- 定位实际读取的配置位置先确认 Ollama 是以服务方式还是手动进程方式跑，查清它读的是哪个单元文件或启动脚本，别凭经验猜。
- 写入变量并完整重启改完配置后重载服务或结束进程重开，只关窗口不算重启。
- 确认服务真的读到了看启动日志有没有反映新的监听地址，或从另一台机器发请求验证，别只看本机回环通不通。
- 回归原来的用法把之前能跑通的命令行请求再跑一遍，确认没被新配置弄坏。
这一步最容易出的错是改对了值、没重启对进程。症状和没配一模一样，于是又回头翻文档，浪费一整轮。
能通之后，再谈显存和驻留的调优
模型每次请求都重新加载，通常是驻留时间太短，调大 keep_alive 比换卡更立竿见影。显存这边，层数卸载参数决定多少层放显卡，显存不够时全塞进去会退化到 CPU，速度断崖式下跌——这种慢不是模型差，是配置逼的。
调优要有基线。先量一次当前首字延迟和生成速度，改一项再量一次，否则分不清是配置起了作用还是网络波动。至于模型存储路径、并发数这类，属于后期调整，先保证单请求稳，再考虑多路。
- keep_alive
- 控制模型加载后驻留多久，调大能减少重复加载，显存紧张时别贪长
- 层数卸载
- 决定多少层放显卡，按显存余量设，设过头会退到 CPU
- 监听地址
- 决定服务能被哪些机器访问，先改这个解决连不通
- OLLAMA_ORIGINS
- 只决定浏览器跨域是否放行，不解决连接和速度
一份照着做的顺序，别一次全改
一次全改看着高效，出问题时根本不知道是哪一项引起的。下面这个顺序，每一步都有明确的验证信号，过不了就别往下走。
- 第一步只解决连通：监听地址改到能被目标机器访问，其他不动，用另一台机器验证
- 第二步解决浏览器：按前端实际来源填 OLLAMA_ORIGINS，用开发者工具看预检是否通过
- 第三步解决重复加载：调驻留时间，观察第二次请求是否明显变快
- 第四步才是显存与并发：一次只动一个参数，改完回归一次原来的用法
- 每一步都留个记录：改了什么、什么现象、有没有变好，出问题好回退
如果第二步过了、第三步没变化，先别怀疑变量没生效，看看是不是请求每次都换了不同模型或者不同参数——那样本来就不会复用已加载的实例。这种情况调驻留时间没意义。
几个常见的误判
把跨域失败当成模型没装好，反复拉模型，实际报错在浏览器控制台而不是 Ollama 日志里，拉一百次也不会好。监听地址开了全网卡但防火墙没放行，症状看起来和没配一样，查配置前先确认端口通不通。
还有一种：在错误的配置文件里改了值，服务重启后依旧读旧配置，排查半天以为是版本问题。调参调得太猛导致显存吃紧，反而比默认配置更慢，这种情况回退到上一步的配置再测一遍，比继续加参数快。
判断配置是否生效，别只看本机回环。换一台机器、换个来源、用浏览器实际发一次请求，这几条比盯着配置文件靠谱。各家模型对显存的要求不同，具体数字到站内模型资料库核对当时的记录。
下一步配完之后想确认实际延迟和生成速度有没有改善，可以去测速工具跑一次基线对比；各模型的显存占用和上下文参数，到模型资料库按当时的数字核对。→常见问题
OLLAMA_ORIGINS 设了还是跨域失败，先查什么？
先看浏览器开发者工具里的请求状态和响应头，确认预检请求是否发出、服务端有没有回允许来源。再确认服务是否真的重启并读到了新值，以及填的来源是否和页面实际地址完全一致（端口、协议都要对上）。
这些配置会影响模型效果吗？
基本不会。监听地址、跨域来源、驻留时间、卸载层数这些属于运行时和资源调度层面的开关，改的是能不能连、跑得快不快、显存怎么用，不改变模型权重本身的能力。效果层面的差别要看模型和量化档位。
本地自己用，能不能直接把来源放开？
临时调试可以，长期不建议。放开后任意网页都能调用你本机的模型服务，等于把接口暴露给浏览器里打开的任何页面。内网固定几个前端地址的话，逐个列出来更稳妥。
