运维踩坑:nginx 缓存上游容器旧 IP,请求转发到了错误的服务
容器重建后 nginx 仍连旧 IP,把请求打到了 Docker 重新分配的别的服务上。根因是 proxy_pass 写主机名只在启动时解析一次并永久缓存,用 resolver + 变量版 proxy_pass 按 TTL 动态解析修复。
容器重建后 nginx 仍连旧 IP,把请求打到了 Docker 重新分配的别的服务上。根因是 proxy_pass 写主机名只在启动时解析一次并永久缓存,用 resolver + 变量版 proxy_pass 按 TTL 动态解析修复。
自从 Karpathy 提出 llm-wiki 这套理念,我就一直想自己动手搭一个 AI 知识库——用它记录笔记、学习知识,也试着让它指引生活。
几经拖延,最后先让 AI 帮我把 llm-wiki 的生态通盘调研了一遍。结果出乎意料地详实:llm-wiki 为什么出现、解决了什么问题,理念和社区如何发展,有哪些开源实现,又该怎么亲手创建一个——都讲清楚了。
整理成文,分享至此,供君参考。
本文涉及版本、星标数、项目状态等信息,截至 2026-07 月的公开仓库/文档,后续可能变化,请以官方最新信息为准。
传统 RAG 像一个“临时资料员”:
1 | 你问问题 → 它去仓库里翻几箱资料 → 抽出几页 → 临时拼一个答案 |
llm-wiki 更像一个“长期图书管理员 + 研究助理”:
1 | 新资料进来 → 它读懂、归档、做索引、写摘要、加交叉引用、标注冲突 |
一句话:
RAG 每次临时找资料;llm-wiki 平时就把资料整理成会复利的知识资产。
VibeCoding 大半年,最大的感受是:慢。一个需求跑大半天,高峰期 API 限速更是雪上加霜。你想走开干点别的,又怕 AI 卡在权限弹窗上等你审批——走也不是,守也不是。
实践久了之后会发现: VibeCoding 需要的不是持续盯盘,而是一种间歇性、片段化的持续注意力。
AI 自己跑着就行,你只在关键节点出现——审批权限、纠正方向、拍板决策。你不是监控器,你是把关人。
Happy Coder 恰好解决了两个问题:
这篇文章分享一下我从零开始用 Happy 的全过程,覆盖日常使用、后台常驻、开机自启、以及自建服务器。