6ab7886865
* perf: optimize request limiting Replace per-request full-map scan under a global mutex with a per-IP sliding window and throttled reclamation; publish config as an immutable atomic snapshot to remove reload/read races. * fix: sample limiter timestamp under lock and use per-request config snapshot - rateLimiter.allow now samples time.Now() while holding the mutex, so entries[ip] stays time-ascending under concurrency; allowAt/allowLocked share the same locked logic for deterministic tests. - handler passes its single config snapshot into proxy and render404 so one request never mixes config versions. - rewrite sweep test to hit sweepLocked directly; restore config/log/gin global state in tests; add real-clock concurrency ordering test. * test: make limiter benchmarks measure their stated operations - BenchmarkLimiterSweep 把「新建限流器 + 填充 5000 个 IP」的初始化成本计入了 被测区间，测得的 ~10.7ms/op 不能解释为单次 sweep 成本。改用 StopTimer/StartTimer 把初始化排除在计时之外（现 ~1.6ms/op），并新增 BenchmarkLimiterSweepWithFill 明确保留「填充+回收」的端到端口径（~16ms/op，含初始化）。 - 并行基准中每个 worker 都从 i := 0 开始，多 IP 场景实际退化为争抢同一个 IP。 改为按 worker 分配互不相同的起始偏移（乘一个与 IP 数互质的步长），使访问分布 真正覆盖多个 IP；偏移只在 worker 启动时计算一次，不增加每次请求的测试开销。 - 统一新旧对比的状态：两套基准都预填 limit+1 条记录，使双方都处于「已满→拒绝」 的稳态拒绝路径，且每-IP 记录条数一致（101）。原基准旧实现预填 limit 条，第 1 次 调用会先走放行路径（把记录推到 limit+1，增长有界）；原基准新实现预填 limit 条 即已拒绝（记录数 limit）。两边的路径与记录数并不严格同态，故此前的新旧对比 不能作为「同状态对比」沿用；统一后实际数字变化不大，报告里会写明。 * test: fix limiter benchmark priming state and comparison basis (#3) * test: fix limiter benchmark priming state and comparison basis 上一提交（8d6781e）的基准注释与实际行为不符：新实现经公开入口 （allow/allowAt）预填 limit+1 次时，第 limit+1 次调用**已被拒绝、不会追加**， 因此实际只保留 limit 条记录（实测 100），而旧实现侧直接写入 limit+1 条 （实测 101）。原注释却写成两边同为 limit+1、声称「记录数一致（101）」， 属错误陈述。 修正方式（不做伪统一，改为如实描述并各自准备稳态）： - 不再声称两边记录数相同。两个实现的拒绝条件不同（旧 len > limit， 新 len >= limit），可长期停留的饱和记录数天然相差 1（101 vs 100）， 这正是本 PR 修正的边界偏差，不可也不应被「统一」掉： 新实现无法经公开入口达到 limit+1 条（运行期不可达状态），旧实现若只预填 limit 条则第 1 次调用会先放行追加，使计时区间混入路径不同的样本。 - 改为让每侧各自准备在自己的饱和拒绝态，使计时区间内每次调用都是同一条 「已饱和 → 拒绝」路径；各自的记录条数由 prime 函数返回并被断言。 - 新增 TestBenchmarkPrimeStates：断言新实现饱和态 = limit 条、旧实现 = limit+1 条， 且饱和后调用被拒绝、记录数不再增长，防止注释再次与代码脱节。 - 修正 NewRealClock 系列：原实现未预置，计时区间混入前 limit 次放行调用； 现同样预置到饱和态（真实时钟），并说明其时钟口径不可与注入固定时间的 New/Old 两组混比。 - 记录一个踩坑：b.ResetTimer() 只归零累计耗时、**不会启动**计时器， b.StopTimer() 之后必须显式 b.StartTimer()，否则计时区间恒为 0、 框架会把 b.N 放大到上限（实测卡在 1e9）。已在代码内注明。 其余（sweep 初始化移出计时区间 + SweepWithFill 端到端口径、并行基准 worker 起始偏移分散）沿用上一提交，未改动实现代码 main.go 与其它测试。 * test: fill 10 records per IP in sweep fixture and state timing scope fixSweepLimiter() 的注释与 PR 描述声称「每个 IP 10 条记录」，但代码里每个 IP 只调用一次 l.allowAt(ip, 10, base)，实际只写入 1 条记录，导致回收基准测的是 「5000 个 IP × 1 条」而非声称的「5000 个 IP × 10 条」，与 ns/op 的可解释性 一并失真。 修正： - fixSweepLimiter() 改为经限流器正常入口（allowAt）对每个 IP 调用 sweepLimit (10) 次，使每个 IP 恰好写入 10 条记录；并在填充后自检每个 IP 的记录数， 防止注释再次与代码脱节。 - 新增常量 sweepLimit / sweepRecordsPerIP / sweepIPCount，消除散落的魔数。 - 明确两者的计时范围：BenchmarkLimiterSweep **排除**填充成本（StopTimer 期间 填充，仅计 sweepLocked 与其触发它的那一次 allow），BenchmarkLimiterSweepWithFill **有意计入**填充成本，故其结果不得当作纯回收耗时。 - 新增 TestSweepFixtureRecordsAllExpired：断言夹具每个 IP 恰好 10 条记录、且这 10 条在触发回收时全部早于 cutoff（全部过期），并且一次 sweep 后仅剩新 IP。 工作量随之从 5,000 条变为 50,000 条记录，Sweep 的 ns/op 上升属预期（测的东西 变多了），不是性能回归。 仅改 bench_test.go；未改 main.go、其它测试、go.mod/go.sum、CI、Dockerfile。 * test: fix sweep benchmark timing scope note and per-iteration trigger time GPT 复核剩余两点，均已修正（仅 bench_test.go）： 1) fixSweepLimiter 的注释说「填充工作不计入任何计时区间：调用方需在 StopTimer 状态下调用它」，与 BenchmarkLimiterSweepWithFill 有意把填充计入计时相矛盾。 改为如实描述：填充成本是否计入**由调用方决定**，并分别点名两个基准的做法。 2) BenchmarkLimiterSweep / SweepWithFill 把 base := time.Now() 放在循环外，且固定 使用 base.Add(2*time.Minute)。这是真实隐患：newRateLimiter 会把 lastSweep 设为 当时的真实 time.Now()，而 sweep 的触发条件是 now.Sub(l.lastSweep) >= l.sweepEvery （sweepEvery 已置 0，即要求触发时刻**不早于** lastSweep）。一旦基准循环的墙钟时间 超过 2 分钟，循环外的 next 就会早于新一轮限流器的 lastSweep，差值变负 → 回收 **静默不触发**，基准实际退化为在测一条空的拒绝路径（且不报错）。 改为每轮在循环内取 base 并相对本轮填充时刻计算 next，使触发条件恒成立。 已核对：此前的数据并非无效（单次基准循环墙钟约 17~25s，未越过 2 分钟）， 但代码是潜在错误的，现已消除。 3) 新增 TestSweepTriggersWithStaleBase 把该陷阱固定下来：用远早于现在的 stale base 构造夹具、以 staleNext 触发时，断言回收**没有**发生（保留 64+1 个 IP）；改用相对 当前时刻的触发时刻后，断言回收完成（仅剩 1 个 IP）。 未改 main.go、其它测试、go.mod/go.sum、CI、Dockerfile。 --------- Co-authored-by: Geekertao-bot <254965144+Geekertao-bot@users.noreply.github.com> --------- Co-authored-by: Geekertao-bot <254965144+Geekertao-bot@users.noreply.github.com> Co-authored-by: Geekertao-bot(openclaw) <Geekertao@qq.com>
ghproxy
这是 CF-Workers-Github-Proxy 的 Go 语言版本。改自gh-proxy
支持内容
• GitHub API (api.github.com)
• Raw 文件 (raw.githubusercontent.com)
• Gist 文件 (gist.githubusercontent.com)
• Releases 文件 (github.com/用户名/仓库名/releases|archive/)
• Git 克隆支持 (git clone)
Docker 部署
- 新建配置文件
config.json，内容如下：
{
"analyticsURL": "https://analytics.geekertao.top",
"supportImageURL": "https://geekertao.top/static/img/zsm.jpg",
"whiteList": [
],
"blackList": [
"example1",
"example2"
]
}
配置文件中的
analyticsURL是顶部导航栏"数据分析"按钮的链接地址，supportImageURL是404错误页面中支持二维码的图片地址，whiteList和blackList分别是白名单和黑名单，如果设置白名单。则只有白名单中的域名会被代理，黑名单可用于过滤部分不安全仓库。
- docker-compose.yml
services:
ghproxy:
image: Geekertao/ghproxy:latest # Docker Hub 镜像源
# image：ghcr.io/Geekertao/ghproxy:latest # GitHub 镜像源
container_name: ghproxy
restart: unless-stopped
volumes:
- ./config.json:/app/config.json # 配置文件挂载路径，根据实际情况修改
ports:
- "45001:45000" # 端口映射，根据实际情况修改
- 启动容器
docker-compose up -d
数据分析
本项目的数据分析功能由 cloudflare-monitor 提供，这是一个功能强大的 Cloudflare 流量分析仪表盘。
功能特性
- 多账户支持：支持多个 Cloudflare 账户的流量监控
- 多 Zone 监控：同时监控多个 Zone 的流量数据
- 实时数据展示：实时更新的数据图表
- 历史数据分析：支持 1 天、3 天、7 天、30 天的历史数据查看
- 智能数据精度：
- 1 天和 3 天数据：小时级精度
- 7 天和 30 天数据：天级精度
- 地理位置统计：显示前 5 个国家/地区的访问量
- 缓存分析：详细的请求和带宽缓存统计
- 响应式设计：完美适配桌面端和移动端
技术栈
- 前端：React + Recharts
- 后端：Node.js + Express
- 部署：Docker + Nginx
在线演示
https://analytics.geekertao.top
自定义配置
如需使用自己的数据分析页面，请在
config.json中修改analyticsURL配置项。部署说明
详细的部署教程请参考：cloudflare-monitor 仓库 或 博客文章教程（含视频部署教程）。
如有问题或改进建议，欢迎提交 issue 或 PR！