你在自己电脑上跑着 Ollama,写了个网页想直接调它,控制台却甩出 CORS 或连接被拒的报错。大概率不是模型的问题,而是 Ollama 默认只认本机、且不放行浏览器跨源请求。这篇按排查顺序走一遍:先确认服务监听在哪,再配放行来源,最后用简单请求验证,并说清哪些场景不该直接暴露。
你在本机跑着 Ollama,顺手写了个网页想直接调它,结果控制台要么甩一条 CORS 报错,要么干脆连接被拒。这时候先别急着重装模型或者换端口,绝大多数情况跟模型无关,是 Ollama 默认只肯跟本机说话、而且不放行浏览器跨源请求。下面按排查顺序走一遍,从判断报错类型开始,到绑定地址、放行来源、验证收尾。
整个过程的核心就一句话:先让服务能被那个来源「连上」,再让浏览器「放行」这个来源,最后用最小的请求验证一遍。中间任何一步跳过,后面都会绕回来重新查。
先分清是连不上还是被浏览器拦了
两种报错长得像,处理方向却完全不同。连接被拒是网络层没通,服务压根没监听在那个地址上;CORS policy 是服务通了,但浏览器发现响应头里没有允许你这个来源,于是把结果扣下不给你。
| 现象 | 含义 | 先查哪里 |
|---|---|---|
| ERR_CONNECTION_REFUSED | 服务没监听在该地址/端口 | 绑定地址与端口是否对得上 |
| CORS policy 报错 | 服务通了,但没放行你的来源 | 放行名单里的来源写法 |
| Mixed Content 被拦 | https 页面请求 http 接口 | 这不是放行能解决的,需换协议或走代理 |
- 浏览器里直接打开 Ollama 的本地端口能看到返回内容,说明服务活着,问题基本在跨源放行那一层
- 命令行 curl 能通、网页不通,几乎可以锁定是浏览器侧放行问题
- 网页是 https 而 Ollama 是 http,属于混合内容拦截,改放行名单也解决不了,得先解决协议
让它先能被那个来源访问到
Ollama 默认只监听回环地址,也就是只有同一台机器上的程序能连。同机网页够用;局域网里的另一台设备、或者跑在容器里的前端,就连不上,这时候才需要改绑定地址。
改绑定前先想清楚代价:绑到所有网卡,等于同网段里谁都能连你这台机器的这个端口。家庭网络和公司内网的风险不一样,后者往往还有其他人共用同一网段。环境变量的具体名字和取值写法,到 /tools 的相关检测页以及 /ai-dict/category/infra 对照着看,别照抄来路不明的命令。
- 确认现在监听在哪用系统自带的端口查看命令,看 Ollama 服务的监听地址是回环还是全部;只显示 127.0.0.1 就说明外部连不上
- 按需改绑定如果确实需要跨机器访问,再改绑定地址;只是本机网页调试,这一步可以先跳过
- 重启并复查改完必须重启服务,再用同一条端口查看命令确认生效;不同系统的服务形态不一样,Linux 上可以到 /ai-dict/category/hardware 先确认是哪种启动方式
绑得越宽,能连上的人越多;能连上的人越多,越需要一个自己的后端挡在前面。
把来源加进放行名单
服务能连上之后,还差浏览器这一关。放行值要写到来源粒度,也就是协议加域名加端口,三者任一不同都算不同来源。写成通配等于对所有网站开放,公网环境下不要这么干。
| 写法 | 含义 | 适用场景 |
|---|---|---|
| 精确来源(含协议与端口) | 只放行这一个页面 | 推荐,尤其是长期使用 |
| localhost 与 127.0.0.1 分别列 | 两者浏览器视为不同来源 | 本地开发常见,两个都要写 |
| 通配符 | 任何网站都能调 | 仅限完全隔离的临时环境,不要长期保留 |
- 端口不同也算不同来源,前端换个端口跑,名单就得跟着加
- 放行值末尾多一个斜杠、大小写不一致,都可能匹配不上,逐字符比对
- 改完放行名单同样要重启服务才生效,改一半不重启等于没改
- 多人共用一台机器时,这份名单是全局的,改动会影响别人,先打招呼
三步验证,别靠猜
配置这种东西,靠肉眼读配置文件的正确率不高,走三步从外到内验证更省事。每一步都只回答一个问题,答案对了再往下走。
- 命令行直连接口绕过浏览器直接请求接口,能返回模型列表说明服务本身正常,此时问题只剩浏览器侧
- 比对报错来源与放行值在浏览器控制台看报错里点名的来源,和你配置的放行值逐字符比对,协议、大小写、末尾斜杠都算数
- 换干净窗口复测开一个无痕窗口再试,排除浏览器插件和缓存干扰;无痕里通了、普通窗口不通,优先怀疑插件
如果你还想顺带看一眼自己这台机器跑这类本地服务的实际响应快慢,可以到 /tools/speed-test 做一次测速,把「服务慢」和「连不上」这两类问题分开,避免混在一起排查。
什么情况下不该这么开
Ollama 自身没有账号体系,谁能连上就能调用你的机器资源。所以「放行」这件事不是越宽越好,下面几种情况要格外谨慎。
- 暴露到公网等于任何人可调用你的机器,非本机访问更稳的做法是走一层自己的后端代理,在代理里做鉴权和限流
- 多人共用的一台机器上,绑定地址和放行名单都是全局的,你改了别人也会受影响,动之前先确认
- 只是临时调试,用完就把绑定地址和放行名单改回去,别留在配置里当默认值
- 公司内网环境尤其要注意,同网段里可能有你都不认识的设备
常见问题
配了放行来源还是报跨域,最可能是哪里错了?
先看报错里点名的来源和你写的值是不是一个字都不差,协议、端口、尾斜杠都算。再看服务改完有没有重启,老进程不会读新配置。如果网页是 https、Ollama 是 http,那是混合内容问题,光加放行解决不了,得换成同协议或走代理。
能不能直接放行所有来源图省事?
本机自己调试、且这台机器只有你用,短期可以;但只要服务绑到了局域网或公网地址,放行所有来源就相当于对所有网站开放你的模型接口,别人写的页面也能调。稳妥做法是只列你实际用到的那几个来源,需要对外时在前面加一层自己的服务端。
局域网里别的设备要用,和网页跨域是一回事吗?
不是。局域网设备连不上是监听地址的问题,先把绑定地址改对;网页调不通是放行来源的问题,两件事要分开配。改完监听还要确认防火墙放行了对端口的访问,具体端口口径到 /ai-dict/category/infra 核对,别凭记忆填。