应先用net.SplitHostPort提取RemoteAddr中的IP，再结合X-Real-IP头及可信代理校验，最后用net.ParseIP().IsPrivate()或net.IPNet.Contains判断是否属于配置的内网CIDR段（如127.0.0.1/32、10.0.0.0/8等），不可仅依赖127.0.0.1。
怎么判断请求来自内网 IP
Buffalo 没有内置的「内网 IP 判断」中间件，得自己写逻辑。核心是解析 c.Request().RemoteAddr，但注意它可能带端口（如 192.168.1.100:54321），得先用 net.SplitHostPort 提取 IP 部分，再用 net.ParseIP + IsPrivate 判断。
常见漏掉的点：Nginx 或其他反向代理后，RemoteAddr 是代理的地址（比如 127.0.0.1），真实客户端 IP 在 X-Forwarded-For 头里。如果用了代理，必须配置 Buffalo 的 app.Use(forceSSL) 类似逻辑前先读头，且要校验 X-Real-IP 或可信段的 X-Forwarded-For —— 否则容易被伪造。
如何给特定路由加内网白名单中间件
直接在注册路由时链式挂载自定义中间件，比全局中间件更精准、不干扰其他接口：
app.GET("/health/mem", requireInternalIP, MemStatsHandler)- 中间件函数签名必须是
func(c buffalo.Context) error - 拒绝时用
c.Error(403, errors.New("forbidden"))，别用c.Render，避免暴露模板路径或状态细节
示例中间件片段：
func requireInternalIP(next buffalo.Handler) buffalo.Handler {
return func(c buffalo.Context) error {
ip, _, _ := net.SplitHostPort(c.Request().RemoteAddr)
if ip == "" {
ip = c.Request().RemoteAddr
}
realIP := c.Request().Header.Get("X-Real-IP")
if realIP != "" {
ip = realIP
}
parsed := net.ParseIP(ip)
if parsed == nil || !parsed.IsPrivate() {
return c.Error(403, errors.New("forbidden"))
}
return next(c)
}
}
为什么不能只依赖 localhost 或 127.0.0.1
生产环境跑在 Docker 或 Kubernetes 里时，服务间调用常走容器网络（如 172.17.0.0/16、10.0.0.0/8），甚至云厂商 VPC 内网（如阿里云 192.168.0.0/16）。硬编码只放行 127.0.0.1 会导致健康检查失败、监控拉取不到指标。
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
更稳妥的做法是把允许的 CIDR 段做成配置项，例如从环境变量读：INTERNAL_CIDRS=127.0.0.1/32,192.168.0.0/16,10.0.0.0/8，然后用 net.IPNet.Contains 做匹配。
Token 校验和 IP 白名单要不要同时用
建议「或」关系，不是「且」。内网服务调用走 IP 白名单更轻量；人工排查或临时调试走 Token（比如 ?token=xxx 或 Authorization: Bearer xxx）更灵活。两者都强制会提高运维成本，且 Token 泄露风险反而可能高于可控内网环境。
Token 验证逻辑务必做时效性校验（如签发时间不超过 5 分钟）、单次使用（可结合 Redis 记录已用 token），避免长期有效的静态 token 被日志或代理缓存泄露。
真正容易被忽略的是：当应用部署在多可用区或跨 VPC 时，不同区域的「内网」IP 段可能不重叠，白名单配置必须随部署环境动态注入，不能写死在代码里。
