修复突然无效的 Docker 透明代理
前言昨天早上起来,本想着使用 codex 给我分析一下 nginx 最新的 CVE 的原理,结果发现,我的中转站一直在超时,于是我检查了一下反代号,发现额度更新刷不出来了,心想,又一次,代理掉了,一般来说只是因为梯子不稳而已,并不少见。 ...
前言昨天早上起来,本想着使用 codex 给我分析一下 nginx 最新的 CVE 的原理,结果发现,我的中转站一直在超时,于是我检查了一下反代号,发现额度更新刷不出来了,心想,又一次,代理掉了,一般来说只是因为梯子不稳而已,并不少见。 ...
前言最近一直在搞各种大模型 API 中转服务,为了能用上低价甚至免费的 API,我真是煞费苦心,尝试了各种方案: 自搭建 GLM-5.1-w8a8 模型,使用 vllm + litellm 提供 API 接入服务购买便宜的 Deepseek v4 pro 的 API在各种二道贩子、小众平台上购买 GPT 号、搭建 GPT 号池并最终反代出 Codex API参与学校的 token plan,拿到免费的 Deepseek v4 pro 和 qwen3.6 的 API接入 Nvidia 自部署并且可以免费使用的各种模型的 API从熟悉的同学那里求来用不完或者免费的 API 额度 ...
前言通常,代理通常有两种方式,一种是开放端口,让需要代理的应用主动通过暴露的端口被代理访问远程服务;一种是使用 tun mode,即虚拟网卡模式,所有流量都会被虚拟网卡设备拦截从而被动代理访问远程服务。 对我来说,我并不希望在我的服务器上采取被动方式,因为它会对服务器上的所有应用产生影响,而且一旦代理软件崩溃退出,我将无法访问互联网,而且会影响比如 ping 等工具的执行(拦截 ICMP 数据包),这是极其不好的,因此平时在我的服务器上,我更倾向于使用主动方式,只有应用需要被代理才会主动去访问代理端口。 ...
前言不久之前,我接手了一套服务器集群,这个集群由一个登录节点和多个计算节点组成,其中登录节点可以通过外网访问,而计算节点只能通过登录节点跳板访问。 拿到手,我最先做的便是探查一下这个集群的网络架构,而在我排查过程中,我发现登录节点 80 端口上开了一个 HTTP 访问,是用于计算节点资源管理的后台管理平台,不足为奇。 ...