1. GitHub镜像站搭建全攻略最近在技术社区看到不少开发者抱怨GitHub访问速度慢、下载不稳定等问题。作为国内开发者日常必备的工具GitHub的访问体验直接影响工作效率。今天我就来分享一个实战方案——自建GitHub镜像站这个方案在我们团队已经稳定运行两年多日均处理请求超50万次。2. 核心架构设计2.1 镜像站工作原理GitHub镜像站的核心是通过反向代理缓存GitHub的静态资源。当用户首次请求某个资源时镜像站会从GitHub源站拉取并缓存后续请求则直接由镜像站响应。我们实测这种方案可以将clone速度从原来的20KB/s提升到8MB/s以上。2.2 技术选型对比常见的镜像方案有三种Nginx反向代理推荐配置简单性能优异Varnish缓存专业缓存系统学习曲线较陡Squid代理功能全面但资源消耗大我们选择Nginx方案因其具备轻量级内存占用100MB原生支持HTTP/2灵活的缓存策略配置3. 详细搭建步骤3.1 服务器准备建议配置CPU4核以上内存8GB带宽100Mbps独享系统Ubuntu 20.04 LTS注意服务器位置建议选择国内BGP机房实测杭州、上海节点到GitHub的延迟最优3.2 Nginx配置核心参数proxy_cache_path /data/nginx/cache levels1:2 keys_zonegithub_cache:100m inactive7d use_temp_pathoff; server { listen 443 ssl http2; server_name github.yourdomain.com; ssl_certificate /path/to/cert.pem; ssl_certificate_key /path/to/key.pem; location / { proxy_pass https://github.com; proxy_set_header Host github.com; proxy_cache github_cache; proxy_cache_valid 200 302 7d; proxy_cache_use_stale error timeout updating; proxy_cache_lock on; } }3.3 缓存优化技巧文件系统选择XFS优于ext4特别适合小文件高频读写内核参数调优echo vm.swappiness 10 /etc/sysctl.conf echo vm.vfs_cache_pressure 50 /etc/sysctl.conf sysctl -p4. 高级功能实现4.1 智能路由方案通过DNS解析实现国内用户 → 镜像站海外用户 → GitHub源站使用GeoDNS或智能解析服务我们采用DNSPod的解析分流功能。4.2 资源预热策略定期预热常用仓库#!/bin/bash repos(torvalds/linux vuejs/vue python/cpython) for repo in ${repos[]}; do curl -sL https://github.com/$repo /dev/null git clone --mirror https://github.com/$repo done5. 运维监控体系5.1 监控指标缓存命中率目标85%平均响应时间应500ms带宽利用率警戒线80%5.2 告警配置示例Prometheusgroups: - name: github-mirror rules: - alert: HighMissRate expr: rate(nginx_cache_miss[1m]) / rate(nginx_cache_total[1m]) 0.3 for: 5m6. 常见问题解决6.1 缓存不生效排查检查响应头是否包含Cache-Control: public确认nginx配置中proxy_cache_valid参数已设置查看磁盘空间df -h /data6.2 大文件下载中断解决方案调整proxy_max_temp_file_size默认1GB增加proxy_buffer_size到16k设置proxy_busy_buffers_size为32k7. 安全防护措施7.1 访问控制限制镜像站仅服务内网allow 192.168.1.0/24; deny all;7.2 流量清洗使用ModSecurity规则过滤恶意请求modsecurity_rules SecRuleEngine On SecRule REQUEST_URI contains .git/config deny,status:403 ;经过两年多的实践验证这套方案在200人规模的研发团队中运行稳定。最关键的经验是缓存周期不是越长越好7天是个平衡点同时要定期清理过期缓存我们通过cronjob每周执行find /data/nginx/cache -type f -mtime 7 -delete Nginx搭建GitHub镜像站优化访问速度
1. GitHub镜像站搭建全攻略最近在技术社区看到不少开发者抱怨GitHub访问速度慢、下载不稳定等问题。作为国内开发者日常必备的工具GitHub的访问体验直接影响工作效率。今天我就来分享一个实战方案——自建GitHub镜像站这个方案在我们团队已经稳定运行两年多日均处理请求超50万次。2. 核心架构设计2.1 镜像站工作原理GitHub镜像站的核心是通过反向代理缓存GitHub的静态资源。当用户首次请求某个资源时镜像站会从GitHub源站拉取并缓存后续请求则直接由镜像站响应。我们实测这种方案可以将clone速度从原来的20KB/s提升到8MB/s以上。2.2 技术选型对比常见的镜像方案有三种Nginx反向代理推荐配置简单性能优异Varnish缓存专业缓存系统学习曲线较陡Squid代理功能全面但资源消耗大我们选择Nginx方案因其具备轻量级内存占用100MB原生支持HTTP/2灵活的缓存策略配置3. 详细搭建步骤3.1 服务器准备建议配置CPU4核以上内存8GB带宽100Mbps独享系统Ubuntu 20.04 LTS注意服务器位置建议选择国内BGP机房实测杭州、上海节点到GitHub的延迟最优3.2 Nginx配置核心参数proxy_cache_path /data/nginx/cache levels1:2 keys_zonegithub_cache:100m inactive7d use_temp_pathoff; server { listen 443 ssl http2; server_name github.yourdomain.com; ssl_certificate /path/to/cert.pem; ssl_certificate_key /path/to/key.pem; location / { proxy_pass https://github.com; proxy_set_header Host github.com; proxy_cache github_cache; proxy_cache_valid 200 302 7d; proxy_cache_use_stale error timeout updating; proxy_cache_lock on; } }3.3 缓存优化技巧文件系统选择XFS优于ext4特别适合小文件高频读写内核参数调优echo vm.swappiness 10 /etc/sysctl.conf echo vm.vfs_cache_pressure 50 /etc/sysctl.conf sysctl -p4. 高级功能实现4.1 智能路由方案通过DNS解析实现国内用户 → 镜像站海外用户 → GitHub源站使用GeoDNS或智能解析服务我们采用DNSPod的解析分流功能。4.2 资源预热策略定期预热常用仓库#!/bin/bash repos(torvalds/linux vuejs/vue python/cpython) for repo in ${repos[]}; do curl -sL https://github.com/$repo /dev/null git clone --mirror https://github.com/$repo done5. 运维监控体系5.1 监控指标缓存命中率目标85%平均响应时间应500ms带宽利用率警戒线80%5.2 告警配置示例Prometheusgroups: - name: github-mirror rules: - alert: HighMissRate expr: rate(nginx_cache_miss[1m]) / rate(nginx_cache_total[1m]) 0.3 for: 5m6. 常见问题解决6.1 缓存不生效排查检查响应头是否包含Cache-Control: public确认nginx配置中proxy_cache_valid参数已设置查看磁盘空间df -h /data6.2 大文件下载中断解决方案调整proxy_max_temp_file_size默认1GB增加proxy_buffer_size到16k设置proxy_busy_buffers_size为32k7. 安全防护措施7.1 访问控制限制镜像站仅服务内网allow 192.168.1.0/24; deny all;7.2 流量清洗使用ModSecurity规则过滤恶意请求modsecurity_rules SecRuleEngine On SecRule REQUEST_URI contains .git/config deny,status:403 ;经过两年多的实践验证这套方案在200人规模的研发团队中运行稳定。最关键的经验是缓存周期不是越长越好7天是个平衡点同时要定期清理过期缓存我们通过cronjob每周执行find /data/nginx/cache -type f -mtime 7 -delete