openclash如何配置本地ollama

装了 OpenClash 之后，浏览器能翻墙了，本地 Ollama 却连不上了——这是很多人第一次踩的坑。问题通常不在模型，而在 Clash 的 TUN 模式和默认路由把 127.0.0.1 以外的本机流量也接管了。这篇按「先确认走哪条路、再写分流、最后逐项排查」的顺序，把代理与本地推理共存的配置动作拆开讲。

装了 OpenClash 之后浏览器能翻墙了，本地 Ollama 却连不上——这个坑很多人都踩过。问题通常不在模型本身，而在 Clash 的 TUN 模式和默认路由把除了本机回环以外的流量一并接管了。先别急着改模型参数，先把「谁该走代理、谁必须直连」这件事分清楚。

这篇按「先确认路径、再写分流、最后逐项排查」的顺序讲。你要做的是三步：判断请求目标属于回环、内网还是公网；在 OpenClash 里给本机服务补一条直连规则；连不上时按固定顺序从服务端往客户端查。下面每一步都给了验证方法，改完要看日志命中，不要只看界面显示已保存。

先想清楚：哪些请求该走代理，哪些必须直连

本地推理本质是进程到进程的通信，走代理只会绕远路，甚至因为代理不理解这个协议而直接断连。真正需要代理的只有三类：拉模型、装依赖、调云端 API。判断方法很简单，看请求的目标地址类型就行。

什么情况下这一套不适用？如果你的模型全部本地跑、从不联网拉取，其实可以不装代理，先问自己有没有必要开。反过来，如果你既要用云端 API 又要跑本地服务，那就必须把两类流量分开。

在 OpenClash 里给本地服务开一条直连通道

规则的核心只有一句话：把回环地址、本机网段、内网网段写进直连列表，并且顺序放在兜底规则之前。顺序错了，前面一条 catch-all 就把流量全吃掉了，后面写多少条都没用。

1. 加直连规则在自定义规则或规则集里补充回环、本机网段、内网网段，确保排在兜底规则之前。
2. 补端口规则把 Ollama 的监听端口也写进直连，避免同网段设备访问时被代理劫持。
3. 看命中日志改完切到 OpenClash 运行日志，实际请求一次本地接口，确认日志里出现这条规则的命中记录，命中才算生效。
4. 备份规则代理规则改动频繁的话，把直连部分单独存一份，升级订阅后重新贴回。

如果只开放给本机用，保持默认只监听回环就够了，不用额外改绑定地址；要给局域网其他机器用才改绑定，同时记得那条地址也要走直连。另外提醒一句，别只看界面显示已保存就以为完事，日志没命中等于没生效。

Ollama 这侧要改的几项

代理规则对了，服务端本身也得对。常见错误是以为服务在跑，其实监听地址和端口跟你想的不是一个。先用命令行确认，再动别的。

# 看服务是否在跑、监听在哪个地址端口
ss -lntp | grep ollama
# 本机直接请求一次接口，确认服务本身可用
curl http://127.0.0.1:11434/api/tags

需要跨机器访问时才改绑定地址，改完必须重启服务，环境变量对已经运行的进程不生效，这点最容易漏。端口放行要看两层：系统防火墙和路由器，代理规则没挡住却被系统防火墙挡住的情况很常见。想知道改了之后的基线数字，可以到 接口测速（/tools/speed-test） 先量一遍本机和服务端的延迟，方便后面出问题时对照。

连不上时的排查顺序

不要一上来就怀疑代理，按下面的顺序从里往外查，能省掉大量来回试错的时间。每一层都有明确的判断动作，通不过就别往下走。

• 第一层看服务：本机请求接口都通不了，先修服务，和代理无关
• 第二层看监听：换成绑定地址去访问，排除只听回环导致的外部不可达
• 第三层看代理：规则模式和直连模式行为不同，说明是分流规则的问题
• 第四层看客户端：报错里的地址、端口、协议三者逐字核对

长期跑之前值得做的两项确认

能通了只是开始，长期稳定还要做两件事。一是把直连规则独立保存，订阅更新时贴回，避免被覆盖导致某天突然又连不上；二是记录一次延迟基线，之后出问题时有对照物。

规则备份

把直连部分单独存一份，订阅更新后重新贴回

延迟基线

用测速页面记录一次本机到服务端的延迟，作为异常时的对照

暴露面

只在本机用就别对外暴露端口，对外暴露要想清楚风险

注意，推理时的实际延迟和吞吐主要取决于你的机器，跟代理没关系，所以基线要在同一台机器、同一时段测，才有可比性。换机器或换网络环境后，基线要重测。