代理

Claude 桌面版的 Code 标签页可以直接添加 SSH 连接，在远程服务器上跑 Claude Code。桌面版会自己把程序传到服务器上，登录凭证也由桌面版负责，服务器上不用装 Claude，也不用登录。 问题是：如果服务器的出口访问不了 Anthropic（比如服务器在香港等 Anthropic 不提供服务的地区，直连会被拒），或者你想指定它走某个网络出口，远端 Claude 就发不出请求。解决办法是在服务器上给 Claude 单独配一个代理，只影响 Claude，不动整台机器的网络。 不想手动配？我把这套流程做成了一个 skill，装上之后跟 Claude 说一句「帮我给 xxx 服务器配 Claude 代理」，它会自己检查、写配置、重启、验证。安装方法、以及复制一句话交给 AI 的用法，见文末「用 skill 自动配置」。 症状 在桌面版里连上服务器、发消息，一直没有回复，或者卡在「Starting session…」。 在服务器上直接请求 API 看一下： curl -sI https://api.anthropic.com | head -1 返回 403 基本就是出口地区被拦了。能正常连通的机器，不带凭据请求一般回的是 401 或 405。 一、在服务器上写 Claude 的配置 先 SSH 登录服务器，在你用来连接的那个用户的家目录下编辑 ~/.claude/settings.json： { "env": { "HTTPS_PROXY": "http://127.0.0.1:7890", "HTTP_PROXY": "http://127.0.0.1:7890", "NO_PROXY": "localhost,127.0.0.1,192.168.0.0/16" } } 127.0.0.1:7890 换成你自己的代理地址。可以是服务器本机跑的代理，也可以是局域网里旁路由的地址，比如 http://192.168.1.2:7890。 只能用 HTTP / HTTPS 代理。 官方文档写明 Claude Code 不支持 SOCKS 代理。Clash / mihomo 的 mixed 端口同时支持 HTTP，用 http:// 就行。 代理需要认证的话，把用户名和密码写进地址：https://user:pass@proxy.example.com:443。密码里有 @、: 这类特殊字符要做 URL 编码。密码是明文存在文件里的，记得 chmod 600 ~/.claude/settings.json。 NO_PROXY 里放不需要走代理的地址，比如本机和内网网段。用 Tailscale 的话，可以再加上 100.64.0.0/10,.ts.net。 如果文件已经存在，把 env 这一段合并进去，别整个覆盖掉。 改完检查一下 JSON 格式： ...

在 OpenWrt 上新建一个独立网段并绑定独立 WiFi，用源地址策略路由把整个网段的流量指向另一个网段里的 mihomo TUN 旁路由。客户端零配置，连上这个 SSID 就自动走代理，切回主网 WiFi 就恢复直连。文末附一个挺隐蔽的踩坑：ImmortalWRT 的 DNS 劫持。 旁路由本身怎么搭的，在上一篇里：用 Docker + macvlan 跑 mihomo 旁路由。 目标 家里已有一个 mihomo 容器当旁路由（TUN 模式），主网设备想走代理就把网关/DNS 指过去。但逐台改设备很烦，家人设备也不适合动手脚。理想状态是： 开一个专用 WiFi，连上就全走 mihomo，断开连回主网就直连。客户端什么都不用设。 拓扑长这样： ┌──────────────────────────────┐ │ OpenWrt (ImmortalWRT) │ WiFi 主网 ── │ br-lan 10.0.0.1/24 │ ── WAN WiFi 代理 ── │ lan_hkt 192.168.88.1/24 │ └──────────────┬───────────────┘ │ 10.0.0.0/24 ┌─────────┴─────────┐ │ N95 小主机 │ │ mihomo (macvlan) │ │ 10.0.0.6 TUN │ └───────────────────┘ mihomo 跑在 N95 上的 Docker 里，macvlan 拿到 10.0.0.6，是 10 段的地址。新 WiFi 绑的是 192.168.88.0/24。 ...

家里用一台 N95 迷你主机当 homelab host，Docker 里跑 mihomo，用 macvlan 给它分一个独立的局域网 IP（10.0.0.6），让它当局域网的旁路由——设备把网关指过去，流量就经过 mihomo 分流代理，不用动主路由的整体路由结构。 容器起来只是第一步，实际会撞上两件事：宿主机和自己衍生出的 macvlan 容器默认互相不通，以及局域网设备到底怎么切到这个网关。这篇把两个都记下来。 为什么用 macvlan docker-compose 配置： services: mihomo: image: metacubex/mihomo:latest container_name: mihomo cap_add: - NET_ADMIN devices: - /dev/net/tun:/dev/net/tun volumes: - ./data:/root/.config/mihomo networks: macvlan_net: ipv4_address: 10.0.0.6 # 需要 IPv6 就把下面带 # 的行全解开（含 sysctls 里那两行） # driver_opts: # com.docker.network.endpoint.sysctls: "net.ipv6.conf.IFNAME.disable_ipv6=0,net.ipv6.conf.IFNAME.accept_ra=2" sysctls: net.ipv4.ip_forward: 1 # net.ipv6.conf.all.disable_ipv6: 0 # net.ipv6.conf.all.forwarding: 1 networks: macvlan_net: driver: macvlan driver_opts: parent: enp1s0 ipam: config: - subnet: 10.0.0.0/24 gateway: 10.0.0.1 用 macvlan 而不是普通 bridge，是因为要给容器一个和局域网其他设备平级的真实 IP，这样它才能被其他设备当网关直接访问、转发流量。bridge 模式下容器藏在宿主机的 NAT 后面，别的设备根本没法把它当网关。 ...