很多人给 Ollama 配了局域网访问，浏览器里打开网页版却一直报跨域错误，控制台一行 CORS 提示，回头翻文档才发现还有个 ollama_origins。这篇就从这个卡点讲起：它管的是浏览器来的请求，不管命令行和脚本；什么场景要配、值该怎么写、配完怎么验证，一步步来。
不少人把 Ollama 开到局域网，想着浏览器里打开个网页版就能用，结果面板一打开全是红的，控制台飘一行跨域提示。回头翻文档，才发现还有个 ollama_origins 没动过。这个变量的位置很尴尬：说它是网络配置吧，它不影响端口通不通；说它是安全设置吧，它又拦不住谁。搞清楚它到底拦的是谁，后面就顺了。
先说结论：它管的是浏览器发来的请求，不管你的 curl、Python 脚本或者后端服务。所以终端里测得好好的，网页一调就挂，八成就是这一层的事。下面按「它拦什么、什么场景要配、值怎么填、配完怎么验」的顺序讲，中间穿插几个容易填错的格子。
它拦的是浏览器，不是你的 curl
ollama_origins 是 Ollama 服务读的一个环境变量，作用是声明哪些网页来源被允许跨域调用接口。关键词是「网页来源」。浏览器在发跨域请求前会带上 Origin 头，服务端拿这个头跟允许列表比对，不在列表里就放行失败，浏览器控制台就会报 CORS 相关的错。而你直接在终端敲 curl，压根没有 Origin 这一层，所以同一个服务，命令行能通、网页不能通，是很常见的组合。
还有个默认行为要记住：不配这个变量时，服务只放行本机来源。所以外部页面调那个监听端口，被挡下来是预期内的，不代表服务没起。判断要不要动它，只看一件事——报错出现在浏览器开发者工具里，还是在终端里。终端报连接拒绝那是端口和监听地址的问题，跟这个变量没关系，别在这上面浪费时间。
| 现象 | 大概率原因 | 先查哪里 |
|---|---|---|
| 终端 curl 正常，网页请求报 CORS | 来源没被允许 | ollama_origins 的当前值 |
| 终端 curl 也连不上 | 服务没起或监听地址不对 | 服务状态、监听地址 |
| 换台机器浏览器打不开，本机能开 | 监听只绑了本机回环 | 启动参数里的监听地址 |
| 配了变量还是报同样的错 | 没重启或值写错 | 重启服务、逐字符对值 |
这几种情况才真需要配
不是所有跨机器访问都要动它。真正需要的场景，基本都跟「浏览器直接打 Ollama 接口」有关。比如你自己写了个纯前端的聊天页面，用 fetch 直连服务；或者把 Open WebUI、Chatbox 这类界面跑在另一个端口、另一台机器上，并且绕开了它自带的后端转发，让浏览器直接连过去；再比如内网里同事用浏览器开你机器的服务地址，前端页面和服务地址不同源。这几种都躲不开来源校验。
反过来，下面这些情况配了也白配，甚至把暴露面搞大：后端服务统一转发请求（浏览器只跟你的后端说话）、页面和服务在同一台机器同一端口、只在本机终端里用。尤其是中间那类「有反代或后端中转」的架构，跨域这层根本不经过浏览器，问题多半出在反代配置或者请求路径上，往 ollama_origins 上找会走偏。
- 浏览器前端 fetch 直连 Ollama 接口——要配
- 界面跑在别的端口或别的机器且直连——要配
- 内网同事浏览器访问你的服务地址——要配
- 后端统一转发、浏览器不直连——不用配
- 同机同端口的页面——不用配
- 只在本机终端里跑脚本——不用配
配的时候容易填错的那一格
这个值最容易错的地方，是把它当成 IP 或者域名来写。它要的是完整来源，协议、主机、端口都得带上，而且要跟浏览器地址栏里看到的那个来源一模一样。只写个 IP，或者随手加个结尾斜杠，都会对不上。多个来源之间按官方要求的分隔方式写，别拿空格凑，也别图省事直接写通配符。
改完必须重启服务才生效。Linux 下如果是用 service 管理的，改 service 文件里的环境变量再重启；临时测试可以在启动命令前带上变量。Windows 下改的是系统环境变量，改完要把终端整个关掉重开，不然读到的还是旧值。这一步漏掉，就会出现「明明配了却没反应」的假象。
- 先确认服务本身通不通在服务所在机器上 curl 一下接口，返回正常说明监听没问题，问题在浏览器那一侧。
- 看浏览器的 Origin 头打开开发者工具，找到那条失败的请求，看请求头里的 Origin 具体是什么值，一个字一个字跟配置对。
- 核对配置值确认协议、主机、端口齐全，没有结尾斜杠，多个来源分隔方式正确。
- 重启并复测重启服务，硬刷新页面再发一次请求，看控制台报错是否消失。
它不是鉴权，别指望拿它当安全开关
这点得说透。放行某个来源，只是告诉浏览器「这个页面可以调我」，不等于限制谁能访问接口。Ollama 接口本身没有身份校验，谁摸到地址谁就能用。把服务暴露到公网，再配个宽松的来源列表，等于门开着还贴了张「欢迎光临」。真要防护，得落在网络层：只监听内网地址、前面加个带鉴权的反向代理、别把端口直接映射出去。
还有一种常见误判：为了省事把来源写成通配符，觉得「反正内网」。实际效果是任何网页都能从访问者的浏览器里打你的服务，风险比不配还大。改完不确定暴露面多大，可以顺着监听地址、端口映射、反代规则过一遍。想知道自己当前这套配置在中转和直连之间处于什么位置，也可以到站内的工具目录对照着看，别凭感觉。
ollama_origins 决定的是浏览器肯不肯替你发这个请求，不是谁有资格用你的服务。下一步把来源、监听地址、端口映射三件事对着过一遍，再决定要不要放开；站内的检测工具和导航页能帮你判断当前这套配置的暴露面。→
常见问题
配了 ollama_origins 浏览器还是报跨域，先查什么？
先确认服务是不是真重启了，旧进程还挂着的话新值没生效。再看报错里的来源和你填的值是否完全一致，协议、端口、有没有 www 都算不同源。最后确认请求到底是打到 Ollama 还是打到了前面的反向代理，代理那层也会拦。
本地脚本调用正常，网页却失败，是 ollama_origins 的问题吗？
大概率是。脚本和 curl 不走浏览器的同源策略，服务能通就说明模型和端口没问题。浏览器这边多了一道来源校验，所以现象是终端正常、页面报错，这一类先往环境变量和反向代理配置上找。
不配这个变量，只把监听改成对外，会怎样？
服务能被访问到，但浏览器页面调接口时仍会被拦，表现为网络面板里有请求、控制台报跨域。同时把监听开大却不做任何限制，等于把没有鉴权的接口摊在网络上，风险比跨域报错大得多。
