md5.pw - 用户贡献 [zh]

搬瓦工Ultra计划15大机房深度横评：从香港CN2 GIA到美西CMIN2

2026-05-08T04:43:21Z

AlexLynn：

<blockquote>
历时72小时，终于集齐了'''搬瓦工Ultra计划全系15个顶级数据中心'''的一手实测数据！ 
 
香港CN2 GIA、日本软银、日本CN2 GIA、新加坡CN2 GIA、美西DC6/DC9……你想得到的旗舰机房，全在这了。
</blockquote>

----

== 📌 给所有搬瓦工用户的“一句话总结表” ==

我知道你们时间宝贵，先上结论，再看细节。

{| class="wikitable"
|+ 机房对比表
! 机房代号 !! 核心线路 !! 电信回程 !! 联通回程 !! 移动回程 !! 一句话点评
|-
| '''HKHK_8(香港CN2 GIA)''' || CTGNet → CN2 GIA || CN2 GIA直连 || CN2 GIA转4837 || CN2 GIA转CMI || '''中国沿海延迟之王'''，广东电信仅9.5ms
|-
| '''JPOS_1(大阪软银)''' || Softbank → 163/4837/CMI || 163直连 || 4837直连 || CMI直连 || 联通用户首选，电信用户慎入
|-
| '''JPOS_6(大阪CN2 GIA)''' || CTGNet → CN2 GIA || CN2 GIA三网直连 || CN2 GIA || CN2 GIA || '''三网无差别体验'''，日服游戏神器
|-
| '''SG_1(新加坡CN2 GIA)''' || xTom → CN2 GIA/9929 || CN2 GIA || 9929 || CN2 GIA || 东南亚业务首选，联通9929起飞
|-
| '''USCA_6(洛杉矶DC6)''' || China Telecom → CN2 GIA/CMIN2 || CN2 GIA || CN2 GIA || CMIN2 || '''美西全能王'''，三网都有专属优化
|-
| '''USCA_9(洛杉矶DC9)''' || IT7 → CN2 GIA/CMIN2 || CN2 GIA || CN2 GIA || CMIN2 || AMD Genoa + NVMe，性能怪兽
|-
| '''USCA_8(洛杉矶ZNET)''' || Arelion/HE → 163/4837/CMI || 163普通线路 || 4837 || CMI || 基础款，预算有限可选
|-
| '''USCA_2(洛杉矶AO)''' || Arelion/HE → 163/4837/CMI || 163普通线路 || 4837 || CMI || 同DC8，性价比之选
|-
| '''USCA_SJC5(圣何塞)''' || China Telecom → CN2 GIA || CN2 GIA || CN2 GIA || CN2 GIA || 美西CN2 GIA，稳定但不如DC6
|-
| '''USCA_FMT(弗里蒙特)''' || HE → 163/4837/CMI || 163普通线路 || 4837 || CMI || 美西普通线路，适合非中国业务
|-
| '''USNJ(新泽西)''' || HE/Arelion → 163/4837/CMI || 163普通线路 || 4837 || CMI || 美东业务专用，延迟较高
|-
| '''USNY_6(纽约CoreSite)''' || HE → 163/4837/CMI || 163普通线路 || 4837 || CMI || 美东基础款
|-
| '''USNY_8(纽约CN2 GIA)''' || China Telecom → CN2 GIA/CMIN2 || CN2 GIA || CN2 GIA || CMIN2 || '''美东CN2 GIA'''，东部用户福音
|-
| '''EUNL_2(阿姆斯特丹)''' || Level3/Cogent → 163/4837/CMI || 163绕美西 || 4837 || TATA→CMI || 欧洲业务专用，对华延迟高
|-
| '''JPTYO_8(东京CN2 GIA)''' || IT7 → CN2 GIA || CN2 GIA || CN2 GIA || CN2 GIA || 日本CN2 GIA，亚太区域优选
|}

== ⚠️ 瓦工IPv6特性声明 ==

在开始前，我必须用红字强调一个'''搬瓦工IPv6特性'''：

<blockquote>
'''KiwiVM后台迁移机房时，IPv4会正常更换为新机房的IP，但IPv6子网是绑定在“初次开通时的机房”上的！''' 
 
这意味着——当你从A机房迁移到B机房后，'''IPv6流量会被强行拉回A机房进行透明转发'''，导致： 
 
- 延迟暴增(实测从香港CN2 GIA迁出后，IPv6延迟飙到200ms+) 
- 严重绕路(IPv6可能绕新加坡再回来) 
- 好处是换机房测评无需重新输入IP，懒人友好。 
 
'''所以我这篇评测的所有路由分析、测速数据，全部基于IPv4。IPv6就当它不存在，请忽略！'''
</blockquote>

好了，下面进入正题。

== 🚀 一、旗舰之王：香港CN2 GIA [HKHK_8]——传说中的“10ms神话” ==

=== 📍 硬件底子 ===

- '''CPU'''：AMD EPYC-Genoa(25代)，2核2线程
- '''内存'''：2GB DDR4
- '''硬盘'''：39GB NVMe(实测SEQ1M Q8读取7599MB/s，写入6132MB/s)
- '''Sysbench'''：单线程3628，多线程7079

香港CN2 GIA的硬件配置直接拉满，AMD Genoa+NVMe的组合，跑PHP、Node.js、数据库都绰绰有余。

=== 🌐 三网回程路由深度解析 ===

'''电信回程(广州节点)：'''

<pre>
1-2 4.34ms 172.22.*.* 内网
4-5 1.55ms 69.194.*.* 香港 CTGNet
8 13.90ms 59.43.*.* 广州 CN2 GIA骨干
16 9.50ms 183.47.*.* 广州电信
</pre>

<blockquote>
广州电信实测延迟仅'''9.5ms'''！这就是CN2 GIA的恐怖之处——物理距离几乎被压缩到极限。
</blockquote>

'''联通回程(北京节点)：'''

<pre>
1-2 24.02ms 172.22.*.* 内网
4-5 2.02ms 69.194.*.* 香港 CTGNet
8 11.54ms 59.43.*.* 广州 CN2 GIA
9 9.27ms 202.97.*.* 广州电信骨干
19 9.54ms 157.148.*.* 广州联通
</pre>

联通虽然最后会切到4837，但前段CN2 GIA已经拉到广州，整体延迟依然控制在10ms级别。

'''移动回程(北京节点)：'''

<pre>
1-2 27.62ms 172.22.*.* 内网
4-5 1.68ms 69.194.*.* 香港 CTGNet
8 8.99ms 59.43.*.* 广州 CN2 GIA
13 60.08ms 221.183.*.* 北京移动CMNET
</pre>

移动比起电联略高，但60ms走北京也属于优秀水平。

=== 💼 商业场景1：跨境电商独立站(面向东南亚/澳新市场) ===

'''为什么选香港CN2 GIA？'''

假设你在深圳运营一个面向香港、新加坡、澳洲消费者的独立站(Shopify/WooCommerce)：

- '''国内管理后台'''：深圳→香港，电信延迟仅10ms，刷新订单、编辑商品丝般顺滑
- '''香港本地用户'''：<5ms延迟，打开速度堪比本地服务器
- '''新加坡用户'''：经香港CN2 GIA→新加坡，延迟约35ms，比直连美西快3倍

'''实测数据支撑'''：本地回环延迟0ms，国际互联到新加坡30ms、到东京49ms，亚太全覆盖。

'''最佳实践配置：'''

- 前端：Nginx + FastCGI Cache
- 后端：PHP 8.2 + Redis
- 数据库：MariaDB 10.11
- CDN：Cloudflare(关闭缓存，仅做DDoS防护)

== 🇯🇵 二、日本双雄：大阪CN2 GIA [JPOS_6] vs 大阪软银 [JPOS_1] ==

=== 对比结论先说：'''电信用户无脑选JPOS_6，联通移动用户可以上JPOS_1省点钱''' ===

----

=== 【JPOS_6】大阪CN2 GIA——三网通吃的“日服游戏神器” ===

'''硬件亮点：'''

- CPU：AMD EPYC-Genoa(单核4309分，多核8380分)
- NVMe读写：SEQ1M Q8读取9978MB/s，写入7907MB/s
- 这性能跑PalWorld、幻兽帕鲁服务器绰绰有余

'''电信回程(上海节点)：'''

<pre>
1 30.45ms 172.22.*.* 内网
2 0.68ms 121.59.*.* 东京 CTGNet
3-4 7.12ms 203.22.*.* 香港
7-9 76.77ms 59.43.*.* 上海 CN2 GIA骨干
16 78.75ms 101.226.*.* 上海电信
</pre>

路径：东京CTGNet → 香港 → 上海CN2 GIA，全程CN2 GIA保障，无任何163介入。

'''联通回程(上海节点)：'''

<pre>
1 22.85ms 172.22.*.* 内网
2 0.60ms 121.59.*.* 东京 CTGNet
4 50.29ms 203.22.*.* 香港
7-9 78.06ms 59.43.*.* 上海 CN2 GIA
19 57.88ms 58.246.*.* 上海联通
</pre>

联通同样全程CN2 GIA到上海，再切联通骨干，延迟80ms以内。

'''移动回程(上海节点)：'''

<pre>
1 18.06ms 172.22.*.* 内网
2 0.87ms 121.59.*.* 东京 CTGNet
4 53.78ms 203.22.*.* 香港
8-9 80.17ms 59.43.*.* 上海 CN2 GIA
12-14 98.65ms 221.183.*.* 上海移动
</pre>

移动全程CN2 GIA，东京→香港→上海，100ms以内。

=== 🎮 商业场景2：TikTok直播矩阵/游戏加速 ===

'''场景描述'''：你在国内运营TikTok直播带货，需要将直播流推送到日本、东南亚的TikTok边缘节点；或者你是游戏工作室，需要稳定的日服/亚服加速。

'''为什么JPOS_6是唯一解？'''

1. '''CN2 GIA三网直连'''：电信、联通、移动全部走CN2 GIA回程，不存在任何“电信友好、移动绕路”的偏科问题
2. '''到东京本地<1ms'''：实测国际互联到东京延迟仅9ms，推流到TikTok东京节点无压力
3. '''IP原生解锁'''：TikTok、Disney+、Netflix全部原生解锁(虽然TikTok检测为失败，但那是风控策略，换UA可解)

'''实测国际互联(东京节点)：'''

<pre>
东京 9ms 2894 Mbps发送 2262 Mbps接收
</pre>

这带宽推4K@60fps H.265毫无压力。

'''成本对比'''：租用阿里云日本CN2 GIA(2核2G，约$50/月) vs 搬瓦工Ultra(约$30/月)，省下40%预算。

----

=== 【JPOS_1】大阪软银——联通移动的“性价比之选” ===

'''回程路由(上海联通节点)：'''

<pre>
1 24.24ms 172.22.*.* 内网
2 3.59ms 142.0.*.* 温哥华IT7
8 51.64ms 221.111.*.* 上海软银
9 55.53ms 202.97.*.* 上海电信163
</pre>

路径：温哥华 → 上海软银 → 切电信163。联通绕路了？不，仔细看：3.59ms 应该是定位不准

'''北京联通回程实测'''：

<pre>
8-10 57.41ms 221.111.*.* 软银
11 85.21ms 202.96.*.* 北京联通
</pre>

软银直连联通4837，延迟85ms，性价比极高。

'''电信用户劝退'''：白龙晚虫，晚高峰再试试。

'''一句话总结'''：联通移动用户闭眼入，电信用户绕道JPOS_6。

== 🇸🇬 三、新加坡CN2 GIA [SG_1]——东南亚市场的“桥头堡” ==

=== 特别说明：这是Early Access机房，容量极其有限，手慢无！ ===

'''硬件配置'''：

- CPU：AMD EPYC(2核2线程)
- NVMe读写：SEQ1M Q8读取9096MB/s，写入5550MB/s

'''回程路由亮点(广州电信节点)：'''

<pre>
1 5.44ms 45.135.*.* 大阪xTom
5 1.28ms 69.194.*.* 新加坡CTGNet
6 36.53ms 69.194.*.* 香港CTGNet
9-10 72.67ms 59.43.*.* 北京CN2 GIA
</pre>

路径：大阪xTom → 新加坡CTGNet → 香港CTGNet → 北京CN2 GIA，全程CN2 GIA保障。

'''联通用户专属福利——9929回程(北京联通节点)：'''

<pre>
8-9 34.68ms 202.77.*.* 香港CUG
10-11 42.65ms 218.105.*.* 广州9929
12 78.99ms 218.105.*.* 北京9929
</pre>

联通9929直连，延迟80ms以内，比走4837稳定得多。

=== 💼 商业场景3：东南亚SaaS服务/游戏加速器 ===

'''目标用户'''：在新加坡、马来西亚、印尼运营SaaS平台(如CRM、ERP)，同时需要国内团队访问后台。

'''为什么新加坡CN2 GIA是最优解？'''

1. '''到新加坡本地<1ms'''：国际互联测试显示，新加坡本地延迟仅1ms，带宽7080 Mbps
2. '''三网CN2 GIA/9929'''：电信移动走CN2 GIA，联通走9929，不存在“偏科”
3. '''IP质量好'''：IP2Location风险评分仅3分(低风险)，AbuseIPDB 0分，发邮件不进垃圾箱

'''实测国际互联(新加坡节点)：'''

<pre>
新加坡 1ms 7080 Mbps发送 5324 Mbps接收
香港 37ms 719 Mbps发送 1059 Mbps接收
</pre>

'''适合的业务类型：'''

- 跨境电商ERP后台(国内运营+东南亚客户)
- 东南亚游戏加速器节点(到印尼/菲律宾<50ms)
- 金融交易系统(低延迟、高稳定性要求)

== 🇺🇸 四、美西三剑客：DC6 CN2 GIA [USCA_6] vs DC9 AMD [USCA_9] vs DC8 ZNET [USCA_8] ==

=== 【USCA_6】洛杉矶DC6——三网融合的“全能战士” ===

'''线路配置'''：电信CN2 GIA + 联通CN2 GIA + 移动CMIN2

'''回程路由实测(北京电信节点)：'''

<pre>
1 1.61ms 172.22.*.* 内网
3 0.77ms 218.30.*.* 洛杉矶电信POP
4-7 127.70ms 59.43.*.* 上海CN2 GIA
10-12 145.95ms 219.141.*.* 北京电信
</pre>

路径：洛杉矶电信POP → 上海CN2 GIA → 北京，全程不走163，稳定150ms以内。

'''移动CMIN2回程(北京移动节点)：'''

<pre>
3 0.93ms 45.78.*.* 洛杉矶IT7
6 126.64ms 223.120.*.* 上海CMIN2
7-9 126.80ms 221.183.*.* 上海移动
10 153.08ms 221.183.*.* 北京移动
</pre>

移动专属CMIN2线路，上海入境，延迟130ms左右。

'''国际互联速度'''：洛杉矶本地0ms，上行6512 Mbps，下行7999 Mbps，跑PT、做图床都爽翻。

=== 【USCA_9】洛杉矶DC9——AMD Genoa + NVMe的性能怪兽 ===

'''和DC6的区别：'''

- 同样的三网优化线路(电信CN2 GIA+联通CN2 GIA+移动CMIN2)
- CPU升级为AMD EPYC-Genoa(单核3515分)
- NVMe读写更快(SEQ1M Q8读取7615MB/s)

'''适合场景'''：对CPU性能有要求的业务，如：

- Java应用(Tomcat、Spring Boot)
- 视频转码(FFmpeg)
- 数据库密集型的Node.js应用

=== 【USCA_8】洛杉矶ZNET——入门级性价比之选 ===

'''线路'''：电信Arelion→163，联通IT7→4837，移动IT7→CMI

'''回程路由实测(上海电信节点)：'''

<pre>
3 0.90ms 45.78.*.* 洛杉矶IT7
4-5 0.85ms 62.115.*.* 洛杉矶Arelion
7 151.11ms 202.97.*.* 上海电信163
</pre>

没有CN2 GIA加持，延迟偏高(150ms+)，但带宽够用(测速500Mbps+)。

'''适合人群'''：

- 预算敏感型用户
- 业务不面向中国(如面向欧美用户)
- 作为备用节点或跳板机

== 🇪🇺 五、欧洲独苗：阿姆斯特丹 [EUNL_2]——欧美业务专用 ==

'''硬件'''：AMD EPYC-Genoa，NVMe读写读取5853MB/s

'''回程路由(北京电信节点)：'''

<pre>
3 0.42ms 142.0.*.* 阿姆斯特丹
7-8 1.44ms 212.133.*.* 伦敦Lumen
9-11 261.95ms 202.97.*.* 北京电信163
</pre>

路径：阿姆斯特丹 → 伦敦 → 美西 → 北京，全球绕路，对华延迟260ms+。

'''但到欧洲本地很快'''：本地延迟1ms，到伦敦7ms，到法兰克福9ms。

'''适合场景'''：

- 面向欧洲客户的网站(德国、法国、英国)
- 欧洲游戏服务器
- 外贸企业邮箱服务器

== 🗽 六、美东攻略：纽约CN2 GIA [USNY_8]——东部用户福音 ==

'''线路'''：三网CN2 GIA/CMIN2

'''回程路由实测(上海电信节点)：'''

<pre>
1-2 15.48ms 10.22.*.* 内网
4 59.52ms 218.30.*.* 洛杉矶电信POP
7-8 187.32ms 59.43.*.* 上海CN2 GIA
</pre>

路径：纽约 → 洛杉矶POP → 上海CN2 GIA，延迟190ms左右。

'''适合人群'''：

- 你在美国东部(纽约、波士顿、华盛顿)有业务
- 同时需要中国用户快速访问
- 对比洛杉矶DC6多绕半个美国，但依然有CN2 GIA保障

== 📊 终极选购指南：一张表治好你的选择困难症 ==

=== 按运营商推荐 ===

{| class="wikitable"
! 你的宽带 !! 首选机房 !! 次选机房 !! 避坑机房
|-
| '''电信''' || 香港CN2 GIA、大阪CN2 GIA、洛杉矶DC6/DC9 || 新加坡CN2 GIA、东京CN2 GIA || 大阪软银、所有HE线路机房
|-
| '''联通''' || 大阪CN2 GIA、新加坡CN2 GIA(9929)、洛杉矶DC6/DC9 || 大阪软银、香港CN2 GIA || 无(联通适应性最强)
|-
| '''移动''' || 洛杉矶DC6/DC9(CMIN2)、大阪CN2 GIA || 香港CN2 GIA、新加坡CN2 GIA || 普通163线路机房
|}

=== 按业务场景推荐 ===

{| class="wikitable"
! 业务场景 !! 推荐机房 !! 核心理由
|-
| '''跨境电商(东南亚市场)''' || 新加坡CN2 GIA || 本地<1ms，三网优化
|-
| '''TikTok直播/游戏加速(日韩)''' || 大阪CN2 GIA || 三网CN2 GIA，到东京9ms
|-
| '''面向欧美客户的SaaS''' || 洛杉矶DC6/DC9 || 三网优化，性能均衡
|-
| '''国内运营后台+全球客户''' || 香港CN2 GIA || 国内延迟最低，国际互联优秀
|-
| '''邮件营销/外贸CRM''' || 洛杉矶DC8/DC2 || IP干净，25端口可用
|-
| '''预算有限的新手入门''' || 洛杉矶ZNET系列 || 性价比高，够用
|-
| '''需要高性能CPU的业务''' || 洛杉矶DC9、香港CN2 GIA || AMD Genoa，单核3500+
|}

== 💰 写在最后：为什么你现在就该下手？ ==

1. '''15机房无限迁徙'''：买一台等于买15台，随时根据业务调整线路

2. '''官方推广活动期间'''：你用我链接买，我拿佣金，提前通知我，前三年返全额

=== 我的承诺： ===

- 所有数据来自真实服务器实测(附NodeQuality报告链接)

- 所有结论基于路由追踪和延迟测试，绝不云评测

- 如果买完发现不适合，搬瓦工30天内可退款(别滥用)

👉 [https://bwh81.net/aff.php?aff=70333&pid=95 '''立即抢购搬瓦工Ultra计划，解锁15大顶级机房-含AFF''']

<blockquote>
本文已同步发布至：MD5 Wiki | NodeSeek论坛 
 
实测数据报告链接： 
 
- 香港CN2 GIA：[https://nodequality.com/r/B2GOSzBILYWKfZIKEkuNIeKRuRyurvRJ NodeQuality] 
- 大阪CN2 GIA：[https://nodequality.com/r/GSTSMdtURJHy2vNozGvliHA7gInl4ESx NodeQuality] 
- 新加坡CN2 GIA：[https://nodequality.com/r/Bc0CVOX3NPdZk7AaPtP3kCYDhpA38Hzg NodeQuality] 
- 洛杉矶DC6：[https://nodequality.com/r/wKzR9L4ALIQSBt0N4rPHSBEIel9MHSC9 NodeQuality] 
 
'''转载需授权，数据造假欢迎来喷。'''
</blockquote>

[[Category:Test category]]

搬瓦工Ultra计划15大机房深度横评：从香港CN2 GIA到美西CMIN2

2026-05-08T04:42:44Z

AlexLynn：edit format

搬瓦工Ultra计划15大机房深度横评：从香港CN2 GIA到美西CMIN2

2026-05-08T04:41:38Z

AlexLynn：edit format

搬瓦工Ultra计划15大机房深度横评：从香港CN2 GIA到美西CMIN2

2026-05-08T04:40:02Z

AlexLynn：创建页面，内容为“<blockquote> 历时72小时，终于集齐了'''搬瓦工Ultra计划全系15个顶级数据中心'''的一手实测数据！ 香港CN2 GIA、日本软银、日本CN2 GIA、新加坡CN2 GIA、美西DC6/DC9……你想得到的旗舰机房，全在这了。 </blockquote> ---- == 📌 给所有搬瓦工用户的“一句话总结表” == 我知道你们时间宝贵，先上结论，再看细节。 {| class="wikitable" |+ 机房对比表 ! 机房…”

<blockquote>
历时72小时，终于集齐了'''搬瓦工Ultra计划全系15个顶级数据中心'''的一手实测数据！ 
 
香港CN2 GIA、日本软银、日本CN2 GIA、新加坡CN2 GIA、美西DC6/DC9……你想得到的旗舰机房，全在这了。
</blockquote>

----

== 📌 给所有搬瓦工用户的“一句话总结表” ==

我知道你们时间宝贵，先上结论，再看细节。

{| class="wikitable"
|+ 机房对比表
! 机房代号 !! 核心线路 !! 电信回程 !! 联通回程 !! 移动回程 !! 一句话点评
|-
| '''HKHK_8(香港CN2 GIA)''' || CTGNet → CN2 GIA || CN2 GIA直连 || CN2 GIA转4837 || CN2 GIA转CMI || '''中国沿海延迟之王'''，广东电信仅9.5ms
|-
| '''JPOS_1(大阪软银)''' || Softbank → 163/4837/CMI || 163直连 || 4837直连 || CMI直连 || 联通用户首选，电信用户慎入
|-
| '''JPOS_6(大阪CN2 GIA)''' || CTGNet → CN2 GIA || CN2 GIA三网直连 || CN2 GIA || CN2 GIA || '''三网无差别体验'''，日服游戏神器
|-
| '''SG_1(新加坡CN2 GIA)''' || xTom → CN2 GIA/9929 || CN2 GIA || 9929 || CN2 GIA || 东南亚业务首选，联通9929起飞
|-
| '''USCA_6(洛杉矶DC6)''' || China Telecom → CN2 GIA/CMIN2 || CN2 GIA || CN2 GIA || CMIN2 || '''美西全能王'''，三网都有专属优化
|-
| '''USCA_9(洛杉矶DC9)''' || IT7 → CN2 GIA/CMIN2 || CN2 GIA || CN2 GIA || CMIN2 || AMD Genoa + NVMe，性能怪兽
|-
| '''USCA_8(洛杉矶ZNET)''' || Arelion/HE → 163/4837/CMI || 163普通线路 || 4837 || CMI || 基础款，预算有限可选
|-
| '''USCA_2(洛杉矶AO)''' || Arelion/HE → 163/4837/CMI || 163普通线路 || 4837 || CMI || 同DC8，性价比之选
|-
| '''USCA_SJC5(圣何塞)''' || China Telecom → CN2 GIA || CN2 GIA || CN2 GIA || CN2 GIA || 美西CN2 GIA，稳定但不如DC6
|-
| '''USCA_FMT(弗里蒙特)''' || HE → 163/4837/CMI || 163普通线路 || 4837 || CMI || 美西普通线路，适合非中国业务
|-
| '''USNJ(新泽西)''' || HE/Arelion → 163/4837/CMI || 163普通线路 || 4837 || CMI || 美东业务专用，延迟较高
|-
| '''USNY_6(纽约CoreSite)''' || HE → 163/4837/CMI || 163普通线路 || 4837 || CMI || 美东基础款
|-
| '''USNY_8(纽约CN2 GIA)''' || China Telecom → CN2 GIA/CMIN2 || CN2 GIA || CN2 GIA || CMIN2 || '''美东CN2 GIA'''，东部用户福音
|-
| '''EUNL_2(阿姆斯特丹)''' || Level3/Cogent → 163/4837/CMI || 163绕美西 || 4837 || TATA→CMI || 欧洲业务专用，对华延迟高
|-
| '''JPTYO_8(东京CN2 GIA)''' || IT7 → CN2 GIA || CN2 GIA || CN2 GIA || CN2 GIA || 日本CN2 GIA，亚太区域优选
|}

== ⚠️ 瓦工IPv6特性声明 ==

在开始前，我必须用红字强调一个'''搬瓦工IPv6特性'''：

<blockquote>
'''KiwiVM后台迁移机房时，IPv4会正常更换为新机房的IP，但IPv6子网是绑定在“初次开通时的机房”上的！''' 
 
这意味着——当你从A机房迁移到B机房后，'''IPv6流量会被强行拉回A机房进行透明转发'''，导致： 
 
- 延迟暴增(实测从香港CN2 GIA迁出后，IPv6延迟飙到200ms+) 
- 严重绕路(IPv6可能绕新加坡再回来) 
- 好处是换机房测评无需重新输入IP，懒人友好。 
 
'''所以我这篇评测的所有路由分析、测速数据，全部基于IPv4。IPv6就当它不存在，请忽略！'''
</blockquote>

好了，下面进入正题。

== 🚀 一、旗舰之王：香港CN2 GIA [HKHK_8]——传说中的“10ms神话” ==

=== 📍 硬件底子 ===

- '''CPU'''：AMD EPYC-Genoa(25代)，2核2线程
- '''内存'''：2GB DDR4
- '''硬盘'''：39GB NVMe(实测SEQ1M Q8读取7599MB/s，写入6132MB/s)
- '''Sysbench'''：单线程3628，多线程7079

香港CN2 GIA的硬件配置直接拉满，AMD Genoa+NVMe的组合，跑PHP、Node.js、数据库都绰绰有余。

=== 🌐 三网回程路由深度解析 ===

'''电信回程(广州节点)：'''

<pre>
1-2 4.34ms 172.22.*.* 内网
4-5 1.55ms 69.194.*.* 香港 CTGNet
8 13.90ms 59.43.*.* 广州 CN2 GIA骨干
16 9.50ms 183.47.*.* 广州电信
</pre>

<blockquote>
广州电信实测延迟仅'''9.5ms'''！这就是CN2 GIA的恐怖之处——物理距离几乎被压缩到极限。
</blockquote>

'''联通回程(北京节点)：'''

<pre>
1-2 24.02ms 172.22.*.* 内网
4-5 2.02ms 69.194.*.* 香港 CTGNet
8 11.54ms 59.43.*.* 广州 CN2 GIA
9 9.27ms 202.97.*.* 广州电信骨干
19 9.54ms 157.148.*.* 广州联通
</pre>

联通虽然最后会切到4837，但前段CN2 GIA已经拉到广州，整体延迟依然控制在10ms级别。

'''移动回程(北京节点)：'''

<pre>
1-2 27.62ms 172.22.*.* 内网
4-5 1.68ms 69.194.*.* 香港 CTGNet
8 8.99ms 59.43.*.* 广州 CN2 GIA
13 60.08ms 221.183.*.* 北京移动CMNET
</pre>

移动比起电联略高，但60ms走北京也属于优秀水平。

=== 💼 商业场景1：跨境电商独立站(面向东南亚/澳新市场) ===

'''为什么选香港CN2 GIA？'''

假设你在深圳运营一个面向香港、新加坡、澳洲消费者的独立站(Shopify/WooCommerce)：

- '''国内管理后台'''：深圳→香港，电信延迟仅10ms，刷新订单、编辑商品丝般顺滑
- '''香港本地用户'''：<5ms延迟，打开速度堪比本地服务器
- '''新加坡用户'''：经香港CN2 GIA→新加坡，延迟约35ms，比直连美西快3倍

'''实测数据支撑'''：本地回环延迟0ms，国际互联到新加坡30ms、到东京49ms，亚太全覆盖。

'''最佳实践配置：'''

- 前端：Nginx + FastCGI Cache
- 后端：PHP 8.2 + Redis
- 数据库：MariaDB 10.11
- CDN：Cloudflare(关闭缓存，仅做DDoS防护)

== 🇯🇵 二、日本双雄：大阪CN2 GIA [JPOS_6] vs 大阪软银 [JPOS_1] ==

=== 对比结论先说：'''电信用户无脑选JPOS_6，联通移动用户可以上JPOS_1省点钱''' ===

----

=== 【JPOS_6】大阪CN2 GIA——三网通吃的“日服游戏神器” ===

'''硬件亮点：'''

- CPU：AMD EPYC-Genoa(单核4309分，多核8380分)
- NVMe读写：SEQ1M Q8读取9978MB/s，写入7907MB/s
- 这性能跑PalWorld、幻兽帕鲁服务器绰绰有余

'''电信回程(上海节点)：'''

<pre>
1 30.45ms 172.22.*.* 内网
2 0.68ms 121.59.*.* 东京 CTGNet
3-4 7.12ms 203.22.*.* 香港
7-9 76.77ms 59.43.*.* 上海 CN2 GIA骨干
16 78.75ms 101.226.*.* 上海电信
</pre>

路径：东京CTGNet → 香港 → 上海CN2 GIA，全程CN2 GIA保障，无任何163介入。

'''联通回程(上海节点)：'''

<pre>
1 22.85ms 172.22.*.* 内网
2 0.60ms 121.59.*.* 东京 CTGNet
4 50.29ms 203.22.*.* 香港
7-9 78.06ms 59.43.*.* 上海 CN2 GIA
19 57.88ms 58.246.*.* 上海联通
</pre>

联通同样全程CN2 GIA到上海，再切联通骨干，延迟80ms以内。

'''移动回程(上海节点)：'''

<pre>
1 18.06ms 172.22.*.* 内网
2 0.87ms 121.59.*.* 东京 CTGNet
4 53.78ms 203.22.*.* 香港
8-9 80.17ms 59.43.*.* 上海 CN2 GIA
12-14 98.65ms 221.183.*.* 上海移动
</pre>

移动全程CN2 GIA，东京→香港→上海，100ms以内。

=== 🎮 商业场景2：TikTok直播矩阵/游戏加速 ===

'''场景描述'''：你在国内运营TikTok直播带货，需要将直播流推送到日本、东南亚的TikTok边缘节点；或者你是游戏工作室，需要稳定的日服/亚服加速。

'''为什么JPOS_6是唯一解？'''

1. '''CN2 GIA三网直连'''：电信、联通、移动全部走CN2 GIA回程，不存在任何“电信友好、移动绕路”的偏科问题
2. '''到东京本地<1ms'''：实测国际互联到东京延迟仅9ms，推流到TikTok东京节点无压力
3. '''IP原生解锁'''：TikTok、Disney+、Netflix全部原生解锁(虽然TikTok检测为失败，但那是风控策略，换UA可解)

'''实测国际互联(东京节点)：'''

<pre>
东京 9ms 2894 Mbps发送 2262 Mbps接收
</pre>

这带宽推4K@60fps H.265毫无压力。

'''成本对比'''：租用阿里云日本CN2 GIA(2核2G，约$50/月) vs 搬瓦工Ultra(约$30/月)，省下40%预算。

----

=== 【JPOS_1】大阪软银——联通移动的“性价比之选” ===

'''回程路由(上海联通节点)：'''

<pre>
1 24.24ms 172.22.*.* 内网
2 3.59ms 142.0.*.* 温哥华IT7
8 51.64ms 221.111.*.* 上海软银
9 55.53ms 202.97.*.* 上海电信163
</pre>

路径：温哥华 → 上海软银 → 切电信163。联通绕路了？不，仔细看：3.59ms 应该是定位不准

'''北京联通回程实测'''：

<pre>
8-10 57.41ms 221.111.*.* 软银
11 85.21ms 202.96.*.* 北京联通
</pre>

软银直连联通4837，延迟85ms，性价比极高。

'''电信用户劝退'''：白龙晚虫，晚高峰再试试。

'''一句话总结'''：联通移动用户闭眼入，电信用户绕道JPOS_6。

== 🇸🇬 三、新加坡CN2 GIA [SG_1]——东南亚市场的“桥头堡” ==

=== 特别说明：这是Early Access机房，容量极其有限，手慢无！ ===

'''硬件配置'''：

- CPU：AMD EPYC(2核2线程)
- NVMe读写：SEQ1M Q8读取9096MB/s，写入5550MB/s

'''回程路由亮点(广州电信节点)：'''

<pre>
1 5.44ms 45.135.*.* 大阪xTom
5 1.28ms 69.194.*.* 新加坡CTGNet
6 36.53ms 69.194.*.* 香港CTGNet
9-10 72.67ms 59.43.*.* 北京CN2 GIA
</pre>

路径：大阪xTom → 新加坡CTGNet → 香港CTGNet → 北京CN2 GIA，全程CN2 GIA保障。

'''联通用户专属福利——9929回程(北京联通节点)：'''

<pre>
8-9 34.68ms 202.77.*.* 香港CUG
10-11 42.65ms 218.105.*.* 广州9929
12 78.99ms 218.105.*.* 北京9929
</pre>

联通9929直连，延迟80ms以内，比走4837稳定得多。

=== 💼 商业场景3：东南亚SaaS服务/游戏加速器 ===

'''目标用户'''：在新加坡、马来西亚、印尼运营SaaS平台(如CRM、ERP)，同时需要国内团队访问后台。

'''为什么新加坡CN2 GIA是最优解？'''

1. '''到新加坡本地<1ms'''：国际互联测试显示，新加坡本地延迟仅1ms，带宽7080 Mbps
2. '''三网CN2 GIA/9929'''：电信移动走CN2 GIA，联通走9929，不存在“偏科”
3. '''IP质量好'''：IP2Location风险评分仅3分(低风险)，AbuseIPDB 0分，发邮件不进垃圾箱

'''实测国际互联(新加坡节点)：'''

<pre>
新加坡 1ms 7080 Mbps发送 5324 Mbps接收
香港 37ms 719 Mbps发送 1059 Mbps接收
</pre>

'''适合的业务类型：'''

- 跨境电商ERP后台(国内运营+东南亚客户)
- 东南亚游戏加速器节点(到印尼/菲律宾<50ms)
- 金融交易系统(低延迟、高稳定性要求)

== 🇺🇸 四、美西三剑客：DC6 CN2 GIA [USCA_6] vs DC9 AMD [USCA_9] vs DC8 ZNET [USCA_8] ==

=== 【USCA_6】洛杉矶DC6——三网融合的“全能战士” ===

'''线路配置'''：电信CN2 GIA + 联通CN2 GIA + 移动CMIN2

'''回程路由实测(北京电信节点)：'''

<pre>
1 1.61ms 172.22.*.* 内网
3 0.77ms 218.30.*.* 洛杉矶电信POP
4-7 127.70ms 59.43.*.* 上海CN2 GIA
10-12 145.95ms 219.141.*.* 北京电信
</pre>

路径：洛杉矶电信POP → 上海CN2 GIA → 北京，全程不走163，稳定150ms以内。

'''移动CMIN2回程(北京移动节点)：'''

<pre>
3 0.93ms 45.78.*.* 洛杉矶IT7
6 126.64ms 223.120.*.* 上海CMIN2
7-9 126.80ms 221.183.*.* 上海移动
10 153.08ms 221.183.*.* 北京移动
</pre>

移动专属CMIN2线路，上海入境，延迟130ms左右。

'''国际互联速度'''：洛杉矶本地0ms，上行6512 Mbps，下行7999 Mbps，跑PT、做图床都爽翻。

=== 【USCA_9】洛杉矶DC9——AMD Genoa + NVMe的性能怪兽 ===

'''和DC6的区别：'''

- 同样的三网优化线路(电信CN2 GIA+联通CN2 GIA+移动CMIN2)
- CPU升级为AMD EPYC-Genoa(单核3515分)
- NVMe读写更快(SEQ1M Q8读取7615MB/s)

'''适合场景'''：对CPU性能有要求的业务，如：

- Java应用(Tomcat、Spring Boot)
- 视频转码(FFmpeg)
- 数据库密集型的Node.js应用

=== 【USCA_8】洛杉矶ZNET——入门级性价比之选 ===

'''线路'''：电信Arelion→163，联通IT7→4837，移动IT7→CMI

'''回程路由实测(上海电信节点)：'''

<pre>
3 0.90ms 45.78.*.* 洛杉矶IT7
4-5 0.85ms 62.115.*.* 洛杉矶Arelion
7 151.11ms 202.97.*.* 上海电信163
</pre>

没有CN2 GIA加持，延迟偏高(150ms+)，但带宽够用(测速500Mbps+)。

'''适合人群'''：

- 预算敏感型用户
- 业务不面向中国(如面向欧美用户)
- 作为备用节点或跳板机

== 🇪🇺 五、欧洲独苗：阿姆斯特丹 [EUNL_2]——欧美业务专用 ==

'''硬件'''：AMD EPYC-Genoa，NVMe读写读取5853MB/s

'''回程路由(北京电信节点)：'''

<pre>
3 0.42ms 142.0.*.* 阿姆斯特丹
7-8 1.44ms 212.133.*.* 伦敦Lumen
9-11 261.95ms 202.97.*.* 北京电信163
</pre>

路径：阿姆斯特丹 → 伦敦 → 美西 → 北京，全球绕路，对华延迟260ms+。

'''但到欧洲本地很快'''：本地延迟1ms，到伦敦7ms，到法兰克福9ms。

'''适合场景'''：

- 面向欧洲客户的网站(德国、法国、英国)
- 欧洲游戏服务器
- 外贸企业邮箱服务器

== 🗽 六、美东攻略：纽约CN2 GIA [USNY_8]——东部用户福音 ==

'''线路'''：三网CN2 GIA/CMIN2

'''回程路由实测(上海电信节点)：'''

<pre>
1-2 15.48ms 10.22.*.* 内网
4 59.52ms 218.30.*.* 洛杉矶电信POP
7-8 187.32ms 59.43.*.* 上海CN2 GIA
</pre>

路径：纽约 → 洛杉矶POP → 上海CN2 GIA，延迟190ms左右。

'''适合人群'''：

- 你在美国东部(纽约、波士顿、华盛顿)有业务
- 同时需要中国用户快速访问
- 对比洛杉矶DC6多绕半个美国，但依然有CN2 GIA保障

== 📊 终极选购指南：一张表治好你的选择困难症 ==

=== 按运营商推荐 ===

{| class="wikitable"
! 你的宽带 !! 首选机房 !! 次选机房 !! 避坑机房
|-
| '''电信''' || 香港CN2 GIA、大阪CN2 GIA、洛杉矶DC6/DC9 || 新加坡CN2 GIA、东京CN2 GIA || 大阪软银、所有HE线路机房
|-
| '''联通''' || 大阪CN2 GIA、新加坡CN2 GIA(9929)、洛杉矶DC6/DC9 || 大阪软银、香港CN2 GIA || 无(联通适应性最强)
|-
| '''移动''' || 洛杉矶DC6/DC9(CMIN2)、大阪CN2 GIA || 香港CN2 GIA、新加坡CN2 GIA || 普通163线路机房
|}

=== 按业务场景推荐 ===

{| class="wikitable"
! 业务场景 !! 推荐机房 !! 核心理由
|-
| '''跨境电商(东南亚市场)''' || 新加坡CN2 GIA || 本地<1ms，三网优化
|-
| '''TikTok直播/游戏加速(日韩)''' || 大阪CN2 GIA || 三网CN2 GIA，到东京9ms
|-
| '''面向欧美客户的SaaS''' || 洛杉矶DC6/DC9 || 三网优化，性能均衡
|-
| '''国内运营后台+全球客户''' || 香港CN2 GIA || 国内延迟最低，国际互联优秀
|-
| '''邮件营销/外贸CRM''' || 洛杉矶DC8/DC2 || IP干净，25端口可用
|-
| '''预算有限的新手入门''' || 洛杉矶ZNET系列 || 性价比高，够用
|-
| '''需要高性能CPU的业务''' || 洛杉矶DC9、香港CN2 GIA || AMD Genoa，单核3500+
|}

== 💰 写在最后：为什么你现在就该下手？ ==

1. '''15机房无限迁徙'''：买一台等于买15台，随时根据业务调整线路
2. '''官方推广活动期间'''：你用我链接买，我拿佣金，提前通知我，前三年返全额

=== 我的承诺： ===

- 所有数据来自真实服务器实测(附NodeQuality报告链接)
- 所有结论基于路由追踪和延迟测试，绝不云评测
- 如果买完发现不适合，搬瓦工30天内可退款(别滥用)

👉 [https://bwh81.net/aff.php?aff=70333&pid=95 '''立即抢购搬瓦工Ultra计划，解锁15大顶级机房-含AFF''']

<blockquote>
本文已同步发布至：MD5 Wiki | NodeSeek论坛 
 
实测数据报告链接： 
 
- 香港CN2 GIA：[https://nodequality.com/r/B2GOSzBILYWKfZIKEkuNIeKRuRyurvRJ NodeQuality] 
- 大阪CN2 GIA：[https://nodequality.com/r/GSTSMdtURJHy2vNozGvliHA7gInl4ESx NodeQuality] 
- 新加坡CN2 GIA：[https://nodequality.com/r/Bc0CVOX3NPdZk7AaPtP3kCYDhpA38Hzg NodeQuality] 
- 洛杉矶DC6：[https://nodequality.com/r/wKzR9L4ALIQSBt0N4rPHSBEIel9MHSC9 NodeQuality] 
 
'''转载需授权，数据造假欢迎来喷。'''
</blockquote>

[[Category:Test category]]

BWH CN2 GIA 与 Komari：轻量级 Go 语言探针呈现三网顶级网络艺术

2026-03-01T06:10:54Z

AlexLynn：

= 搬瓦工 CN2 GIA 与 Komari：轻量级 Go 语言探针呈现三网顶级网络艺术 =
= BandwagonHost CN2 GIA & Komari: A Lightweight Go Probe Presenting the Art of Top-Tier Networking =

搬瓦工（BandwagonHost）的 CN2 GIA 线路堪称 VPS 界的网络天花板。其三网顶级直连架构不仅带来了令人惊叹的极致超低延迟，更是在晚高峰也能保持全天候 '''0 丢包''' 的神话。这种丝滑、纯粹的网络体验，如果不配上一个优秀的现代监控探针将其彻底可视化，简直是暴殄天物！
BandwagonHost's CN2 GIA routing is arguably the network ceiling of the VPS world. Its top-tier direct connection across all three major networks brings not only amazingly stable and low latency but also maintains a mythical '''0 packet loss''' even during peak hours. Such a silky-smooth and pure network experience would be an absolute waste if not thoroughly visualized with an excellent modern monitoring dashboard!

为了不辜负瓦工如此顶级的线路，我们需要一款同样极致的探针。今天的主角 '''Komari''' 正是为此而生。
To live up to such top-tier routing from BandwagonHost, we need an equally ultimate probe. Today's protagonist, '''Komari''', was born for this exact purpose.

== 为什么选择 Komari？ / Why Choose Komari? ==

[[File:Komari.png|thumb]]

市面上的服务器监控面板琳琅满目，但 Komari 凭借其独特的架构脱颖而出：
The market is full of server monitoring panels, but Komari stands out with its unique architecture:

* '''基于 Go 语言构建 / Built with Go'''：Komari 的主控端和 Agent 均采用 Golang 编写。天生的高并发优势和出色的内存管理，使得它能以极低的系统资源占用，轻松处理并发连接。 Komari's controller and agent are both written in Golang. Its inherent high-concurrency advantages and excellent memory management allow it to easily handle concurrent connections with extremely low system resource consumption.
* '''优雅的 Controller + Agent 架构 / Elegant Controller + Agent Architecture'''：主控面板（Controller）负责节点管理与数据展示，轻量 Agent 负责采集系统指标，并通过 WebSocket 持久连接上报数据。这种设计避免了传统轮询式监控产生的大量请求开销，在低带宽 VPS 环境下依然能够保持高实时性与极低资源占用。 The controller dashboard is responsible for node management and data presentation, while the lightweight Agent collects system metrics and reports data via persistent WebSocket connections. This design avoids the massive request overhead generated by traditional polling-based monitoring, maintaining high real-time performance and extremely low resource usage even in low-bandwidth VPS environments.
* '''极致轻量与极简主义 / Extreme Lightweight & Minimalism'''：监控工具本身不应成为服务器的负担。Komari 没有臃肿的依赖库，对于极其珍贵的瓦工服务器资源来说，运行它几乎是“零感知”的。 Monitoring tools themselves shouldn't be a burden on the server. Komari has no bloated dependency libraries; for the extremely precious BandwagonHost server resources, running it is almost "zero-perception".

本文将通过严谨的逻辑，一步一步完成 Komari 的基础部署、高级安全反代，以及多节点 Agent 的接入。
This article will walk through the basic deployment of Komari, advanced secure reverse proxy configuration, and multi-node Agent integration, step-by-step with rigorous logic.

== 第一步：基础安装 - 部署 Komari 主控 / Step 1: Basic Installation - Deploying Komari Controller ==

无论你是在白天使用 Windows 办公，还是使用 macOS 的终端，请先通过 SSH 接入你的搬瓦工服务器。为了保证环境的隔离性和未来排错的便利性，我们采用 Docker Compose 进行部署。
Whether you are working on Windows during the day or using the macOS terminal, please SSH into your BandwagonHost server first. To ensure environmental isolation and ease of future troubleshooting, we will deploy using Docker Compose.

=== 1. 创建项目目录结构 / Create Project Directory Structure ===
<syntaxhighlight lang="bash">
mkdir -p /opt/komari && cd /opt/komari
</syntaxhighlight>

=== 2. 编写 Docker Compose 配置文件 / Write the Docker Compose Configuration ===
创建并编辑 Docker Compose 配置文件：
Create and edit the Docker Compose configuration file:
<syntaxhighlight lang="bash">
nano docker-compose.yml
</syntaxhighlight>

写入以下内容（注意端口映射的安全加固与版本控制）：
Write the following content (note the security hardening of port mapping and version control):
<syntaxhighlight lang="yaml">
version: '3.8'
services:
komari:
# 生产环境建议将 latest 替换为具体的 release 版本号以保证系统稳定性
# For production, it's recommended to replace 'latest' with a specific release version to ensure system stability
image: ghcr.io/komari-monitor/komari:latest
container_name: komari
restart: unless-stopped
ports:
- "127.0.0.1:25774:25774"
volumes:
- ./data:/app/data
</syntaxhighlight>

; 🔍 Debug 与安全分析逻辑 / Debugging & Security Analysis Logic
: '''为什么映射 `/app/data`？ / Why map `/app/data`?''' 探针的面板设置、节点信息都物理存储在这个目录。如果不做映射，一旦容器重启或销毁，所有配置数据将全部丢失。 (The panel settings and node information are physically stored in this directory. If not mapped, all configuration data will be completely lost once the container restarts or is destroyed.)
: '''安全加固 `127.0.0.1`： / Security Hardening `127.0.0.1`:''' 绑定本地环回地址 `127.0.0.1`，杜绝被批量扫描及 0day 漏洞攻击的潜在威胁。 (Binding to the local loopback address `127.0.0.1` eliminates the potential threat of being bulk-scanned and attacked by 0-day vulnerabilities.)

=== 3. 启动服务 / Start the Service ===
<syntaxhighlight lang="bash">
docker compose up -d
</syntaxhighlight>
启动后，执行 `docker logs komari` 查看系统自动生成的初始管理员账号和密码。
After starting, execute `docker logs komari` to view the initial admin account and password automatically generated by the system.

== 第二步：进阶配置 - Caddy 详尽反代与 HTTPS / Step 2: Advanced Configuration - Detailed Caddy Reverse Proxy & HTTPS ==

在前端，我们将使用 Caddy 申请免费证书并进行反向代理，将安全的 HTTPS 流量转发给内网的 Komari。
On the frontend, we will use Caddy to request a free certificate and set up a reverse proxy to forward secure HTTPS traffic to the internal Komari service.

=== 1. 编辑 Caddyfile / Edit the Caddyfile ===
打开你的 Caddy 配置文件（通常位于 `/etc/caddy/Caddyfile`）：
Open your Caddy config file (usually located at `/etc/caddy/Caddyfile`):
<syntaxhighlight lang="bash">
nano /etc/caddy/Caddyfile
</syntaxhighlight>

写入以下配置（请将 `status.yourdomain.com` 替换为你的真实域名）：
Write the following configuration (please replace `status.yourdomain.com` with your real domain name):
<syntaxhighlight lang="text">
status.yourdomain.com {
# 启用现代 TLS 协议 / Enable modern TLS protocols
tls {
protocols tls1.2 tls1.3
}

# 反向代理至本地环回地址的 Komari 端口 / Reverse proxy to the Komari port on the local loopback address
reverse_proxy localhost:25774 {
# 传递真实访客 IP 和协议 / Pass real visitor IP and protocol
header_up Host {host}
header_up X-Real-IP {remote}
header_up X-Forwarded-For {remote}
header_up X-Forwarded-Proto {scheme}
}

# 启用压缩机制以加快探针面板加载速度 / Enable compression to speed up dashboard loading
encode gzip zstd

# 现代且严谨的安全响应头设置 / Modern and rigorous security response headers setup
header {
# 注意：此处未加 preload，只有在你准备将域名提交到浏览器 HSTS preload list 时才建议加入 preload 参数
# Note: 'preload' is omitted here; it is only recommended if you plan to submit the domain to the browser HSTS preload list
Strict-Transport-Security "max-age=31536000; includeSubDomains"
X-Content-Type-Options "nosniff"
X-Frame-Options "SAMEORIGIN"
Referrer-Policy "strict-origin-when-cross-origin"
}

# 详尽的访问日志记录，为未来排错提供明确的数据分析支持 / Detailed access logging to provide clear data support for future debugging
log {
output file /var/log/caddy/komari_access.log {
roll_size 100mb
roll_keep 5
}
format json
}
}
</syntaxhighlight>

; 🔍 Debug 与排错逻辑 / Debugging & Troubleshooting Logic
: '''WebSocket 断连与 Cloudflare 避坑： / WebSocket Disconnection & Cloudflare Pitfalls:''' Komari 极其依赖 WebSocket 进行实时数据推送（Caddy v2 默认原生支持 WebSocket 转发）。如果你发现面板卡死不刷新，请首先检查链路。如果你在前端套用了 Cloudflare，请务必检查：1. 网络设置中的 "WebSockets" 选项是否开启；2. SSL/TLS 加密模式必须设置为 "Full" 或 "Full (Strict)"，否则会导致循环重定向或握手失败。 (Komari heavily relies on WebSocket for real-time data push. If the panel freezes, check the link first. If using Cloudflare, ensure: 1. "WebSockets" is enabled in Network settings; 2. SSL/TLS mode is set to "Full" or "Full (Strict)" to prevent redirect loops or handshake failures.)
: '''日志分析排错： / Log Analysis Troubleshooting:''' 这里专门配置了 `/var/log/caddy/komari_access.log`。如果配置完出现 502 错误，切忌盲目瞎猜，直接使用 `tail -f /var/log/caddy/komari_access.log` 追踪日志，通过分析 HTTP 状态码和 Upstream 报错来精准定位问题。 (We specifically configured `/var/log/caddy/komari_access.log`. If a 502 error occurs, do not guess blindly; directly use `tail -f` to track the log and pinpoint the issue by analyzing HTTP status codes and Upstream errors.)

=== 2. 重载 Caddy 生效 / Reload Caddy to Apply ===
<syntaxhighlight lang="bash">
caddy reload --config /etc/caddy/Caddyfile
</syntaxhighlight>

== 第三步：多节点 Agent 接入实战 / Step 3: Multi-Node Agent Integration Practice ==

主控端稳如泰山后，现在我们可以把其他 VPS 统一接入面板进行管理了。
With the controller stable as a mountain, we can now integrate your other VPS nodes into the dashboard for unified management.

=== 1. 主控端获取连接参数 / Get Connection Parameters from Controller ===
登录你的 Komari 面板后台，点击“添加节点”。系统会为你生成一串专属的 Agent 连接命令，其中包含了你的 '''API 地址''' 和对应节点的 '''Secret Key'''。
Log into your Komari dashboard backend and click "Add Node". The system will generate a dedicated Agent connection command containing your '''API Address''' and the corresponding node's '''Secret Key'''.

=== 2. 在被控节点安装 Agent / Install Agent on the Managed Node ===
通过 SSH 登录到你需要监控的服务器，为了保持系统整洁，我们依然推荐使用 Docker 运行 Agent：
Log into the server you want to monitor via SSH. To keep the system clean, we still recommend running the Agent using Docker:

<syntaxhighlight lang="bash">
docker run -d \
--name komari-agent \
--restart unless-stopped \
--net=host \
-v /proc:/host/proc:ro \
-v /sys:/host/sys:ro \
-v /:/rootfs:ro \
ghcr.io/komari-monitor/komari-agent:latest \
-api "wss://status.yourdomain.com/api/v1/ws" \
-secret "你的节点专属SecretKey"
</syntaxhighlight>

; 🔍 Debug 与分析逻辑 / Debugging & Analysis Logic
: '''参数解析 `net=host` 与目录映射： / Parameter Parsing `net=host` and Directory Mapping:''' Agent 需要真实获取宿主机的网卡流量、CPU 和内存信息，因此必须使用 `--net=host` 共享网络命名空间，并将宿主机的 `/proc` 和 `/sys` 以只读 (`ro`) 模式映射进容器。 (The Agent needs to fetch real host network traffic, CPU, and memory info, so it must use `--net=host` to share the network namespace and map the host's `/proc` and `/sys` into the container in read-only (`ro`) mode.)
: '''协议检查： / Protocol Check:''' 确保 `-api` 参数使用的是 `wss://`（WebSocket Secure），因为我们的主控端已经配置了严格的 HTTPS。如果填成 `ws://` 将会被 Caddy 拒绝连接。 (Ensure the `-api` parameter uses `wss://` (WebSocket Secure) since our controller is configured with strict HTTPS. If filled as `ws://`, the connection will be rejected by Caddy.)

大功告成！现在，你可以坐在屏幕前，看着所有服务器的绿色心跳线，享受数据掌控在自己手中的极致快感了。
Mission accomplished! Now, you can sit in front of the screen, watch the green heartbeat lines of all your servers, and enjoy the ultimate thrill of having your data under your own control.

== 进阶探索与安全延展 / Advanced Exploration & Security Extension ==

Komari 其实还有更多强大的进阶玩法等待你发掘。例如，你可以配置 Telegram Bot 接收服务器到期续费、流量预警、系统高负载以及延迟异常的实时推送（测速节点 IP 推荐在 zstaticcdn.com 获取）。此外，面板还支持高度定制化的美化主题。关于这些高级配置，篇幅所限不再展开，强烈建议访问 GitHub 搜索 `komari` 或直达官方文档 (https://komari-document.pages.dev/) 自行探索学习。 Komari actually has many more powerful advanced features waiting for you to discover. For instance, you can configure a Telegram Bot to receive real-time push notifications for server expiration renewals, traffic warnings, high system load, and abnormal latency (we recommend getting speed test node IPs from zstaticcdn.com). Additionally, the dashboard supports highly customizable aesthetic themes. Due to space constraints, we won't expand on these advanced configurations here. It is highly recommended to search for `komari` on GitHub or visit the official documentation (https://komari-document.pages.dev/) to explore and learn on your own.

最后，虽然瓦工的线路极佳，但公网环境险恶。为了预防潜在的 DDoS 攻击或端口嗅探，你可以进一步研究如何为面板或网站套上“赛博菩萨” Cloudflare 的 Proxy (CDN) 甚至配置更为安全的 Cloudflare Tunnel。这些都是 VPS 玩家进阶的必修课，期待你查阅相关资料，继续点亮你的网络安全技能树！ Finally, although BandwagonHost's routing is excellent, the public internet environment is perilous. To prevent potential DDoS attacks or port sniffing, you can further research how to put your dashboard or website behind the "Cyber Bodhisattva" Cloudflare's Proxy (CDN) or even configure the much safer Cloudflare Tunnel. These are required courses for advanced VPS players. We look forward to you looking up relevant materials and continuing to light up your network security skill tree!

----
''Created by AlexLynn for md5.pw Community.''
[[Category:500 常见应用指南 — Application Guides]]

搬瓦工 CN2 GIA 与 Komari：轻量级 Go 语言探针呈现三网顶级网络艺术

2026-03-01T06:09:58Z

AlexLynn：重定向页面至BWH CN2 GIA 与 Komari：轻量级 Go 语言探针呈现三网顶级网络艺术

#REDIRECT [[BWH CN2 GIA 与 Komari：轻量级 Go 语言探针呈现三网顶级网络艺术]]

BWH CN2 GIA 与 Komari：轻量级 Go 语言探针呈现三网顶级网络艺术

2026-03-01T06:08:47Z

AlexLynn：创建页面，内容为“= 搬瓦工 CN2 GIA 与 Komari：轻量级 Go 语言探针呈现三网顶级网络艺术 = = BandwagonHost CN2 GIA & Komari: A Lightweight Go Probe Presenting the Art of Top-Tier Networking = 搬瓦工（BandwagonHost）的 CN2 GIA 线路堪称 VPS 界的网络天花板。其三网顶级直连架构不仅带来了令人惊叹的极致超低延迟，更是在晚高峰也能保持全天候 '''0 丢包''' 的神话。这种丝滑、纯粹的网络体验，如果…”

= 搬瓦工 CN2 GIA 与 Komari：轻量级 Go 语言探针呈现三网顶级网络艺术 =
= BandwagonHost CN2 GIA & Komari: A Lightweight Go Probe Presenting the Art of Top-Tier Networking =

搬瓦工（BandwagonHost）的 CN2 GIA 线路堪称 VPS 界的网络天花板。其三网顶级直连架构不仅带来了令人惊叹的极致超低延迟，更是在晚高峰也能保持全天候 '''0 丢包''' 的神话。这种丝滑、纯粹的网络体验，如果不配上一个优秀的现代监控探针将其彻底可视化，简直是暴殄天物！
BandwagonHost's CN2 GIA routing is arguably the network ceiling of the VPS world. Its top-tier direct connection across all three major networks brings not only amazingly stable and low latency but also maintains a mythical '''0 packet loss''' even during peak hours. Such a silky-smooth and pure network experience would be an absolute waste if not thoroughly visualized with an excellent modern monitoring dashboard!

为了不辜负瓦工如此顶级的线路，我们需要一款同样极致的探针。今天的主角 '''Komari''' 正是为此而生。
To live up to such top-tier routing from BandwagonHost, we need an equally ultimate probe. Today's protagonist, '''Komari''', was born for this exact purpose.

== 为什么选择 Komari？ / Why Choose Komari? ==

[[File:Komari.png|thumb]]

市面上的服务器监控面板琳琅满目，但 Komari 凭借其独特的架构脱颖而出：
The market is full of server monitoring panels, but Komari stands out with its unique architecture:

* '''基于 Go 语言构建 / Built with Go'''：Komari 的主控端和 Agent 均采用 Golang 编写。天生的高并发优势和出色的内存管理，使得它能以极低的系统资源占用，轻松处理并发连接。 Komari's controller and agent are both written in Golang. Its inherent high-concurrency advantages and excellent memory management allow it to easily handle concurrent connections with extremely low system resource consumption.
* '''优雅的 Controller + Agent 架构 / Elegant Controller + Agent Architecture'''：主控面板（Controller）负责节点管理与数据展示，轻量 Agent 负责采集系统指标，并通过 WebSocket 持久连接上报数据。这种设计避免了传统轮询式监控产生的大量请求开销，在低带宽 VPS 环境下依然能够保持高实时性与极低资源占用。 The controller dashboard is responsible for node management and data presentation, while the lightweight Agent collects system metrics and reports data via persistent WebSocket connections. This design avoids the massive request overhead generated by traditional polling-based monitoring, maintaining high real-time performance and extremely low resource usage even in low-bandwidth VPS environments.
* '''极致轻量与极简主义 / Extreme Lightweight & Minimalism'''：监控工具本身不应成为服务器的负担。Komari 没有臃肿的依赖库，对于极其珍贵的瓦工服务器资源来说，运行它几乎是“零感知”的。 Monitoring tools themselves shouldn't be a burden on the server. Komari has no bloated dependency libraries; for the extremely precious BandwagonHost server resources, running it is almost "zero-perception".

本文将通过严谨的逻辑，一步一步完成 Komari 的基础部署、高级安全反代，以及多节点 Agent 的接入。
This article will walk through the basic deployment of Komari, advanced secure reverse proxy configuration, and multi-node Agent integration, step-by-step with rigorous logic.

== 第一步：基础安装 - 部署 Komari 主控 / Step 1: Basic Installation - Deploying Komari Controller ==

无论你是在白天使用 Windows 办公，还是使用 macOS 的终端，请先通过 SSH 接入你的搬瓦工服务器。为了保证环境的隔离性和未来排错的便利性，我们采用 Docker Compose 进行部署。
Whether you are working on Windows during the day or using the macOS terminal, please SSH into your BandwagonHost server first. To ensure environmental isolation and ease of future troubleshooting, we will deploy using Docker Compose.

=== 1. 创建项目目录结构 / Create Project Directory Structure ===
<syntaxhighlight lang="bash">
mkdir -p /opt/komari && cd /opt/komari
</syntaxhighlight>

=== 2. 编写 Docker Compose 配置文件 / Write the Docker Compose Configuration ===
创建并编辑 Docker Compose 配置文件：
Create and edit the Docker Compose configuration file:
<syntaxhighlight lang="bash">
nano docker-compose.yml
</syntaxhighlight>

写入以下内容（注意端口映射的安全加固与版本控制）：
Write the following content (note the security hardening of port mapping and version control):
<syntaxhighlight lang="yaml">
version: '3.8'
services:
komari:
# 生产环境建议将 latest 替换为具体的 release 版本号以保证系统稳定性
# For production, it's recommended to replace 'latest' with a specific release version to ensure system stability
image: ghcr.io/komari-monitor/komari:latest
container_name: komari
restart: unless-stopped
ports:
- "127.0.0.1:25774:25774"
volumes:
- ./data:/app/data
</syntaxhighlight>

; 🔍 Debug 与安全分析逻辑 / Debugging & Security Analysis Logic
: '''为什么映射 `/app/data`？ / Why map `/app/data`?''' 探针的面板设置、节点信息都物理存储在这个目录。如果不做映射，一旦容器重启或销毁，所有配置数据将全部丢失。 (The panel settings and node information are physically stored in this directory. If not mapped, all configuration data will be completely lost once the container restarts or is destroyed.)
: '''安全加固 `127.0.0.1`： / Security Hardening `127.0.0.1`:''' 绑定本地环回地址 `127.0.0.1`，杜绝被批量扫描及 0day 漏洞攻击的潜在威胁。 (Binding to the local loopback address `127.0.0.1` eliminates the potential threat of being bulk-scanned and attacked by 0-day vulnerabilities.)

=== 3. 启动服务 / Start the Service ===
<syntaxhighlight lang="bash">
docker compose up -d
</syntaxhighlight>
启动后，执行 `docker logs komari` 查看系统自动生成的初始管理员账号和密码。
After starting, execute `docker logs komari` to view the initial admin account and password automatically generated by the system.

== 第二步：进阶配置 - Caddy 详尽反代与 HTTPS / Step 2: Advanced Configuration - Detailed Caddy Reverse Proxy & HTTPS ==

在前端，我们将使用 Caddy 申请免费证书并进行反向代理，将安全的 HTTPS 流量转发给内网的 Komari。
On the frontend, we will use Caddy to request a free certificate and set up a reverse proxy to forward secure HTTPS traffic to the internal Komari service.

=== 1. 编辑 Caddyfile / Edit the Caddyfile ===
打开你的 Caddy 配置文件（通常位于 `/etc/caddy/Caddyfile`）：
Open your Caddy config file (usually located at `/etc/caddy/Caddyfile`):
<syntaxhighlight lang="bash">
nano /etc/caddy/Caddyfile
</syntaxhighlight>

写入以下配置（请将 `status.yourdomain.com` 替换为你的真实域名）：
Write the following configuration (please replace `status.yourdomain.com` with your real domain name):
<syntaxhighlight lang="text">
status.yourdomain.com {
# 启用现代 TLS 协议 / Enable modern TLS protocols
tls {
protocols tls1.2 tls1.3
}

# 反向代理至本地环回地址的 Komari 端口 / Reverse proxy to the Komari port on the local loopback address
reverse_proxy localhost:25774 {
# 传递真实访客 IP 和协议 / Pass real visitor IP and protocol
header_up Host {host}
header_up X-Real-IP {remote}
header_up X-Forwarded-For {remote}
header_up X-Forwarded-Proto {scheme}
}

# 启用压缩机制以加快探针面板加载速度 / Enable compression to speed up dashboard loading
encode gzip zstd

# 现代且严谨的安全响应头设置 / Modern and rigorous security response headers setup
header {
# 注意：此处未加 preload，只有在你准备将域名提交到浏览器 HSTS preload list 时才建议加入 preload 参数
# Note: 'preload' is omitted here; it is only recommended if you plan to submit the domain to the browser HSTS preload list
Strict-Transport-Security "max-age=31536000; includeSubDomains"
X-Content-Type-Options "nosniff"
X-Frame-Options "SAMEORIGIN"
Referrer-Policy "strict-origin-when-cross-origin"
}

# 详尽的访问日志记录，为未来排错提供明确的数据分析支持 / Detailed access logging to provide clear data support for future debugging
log {
output file /var/log/caddy/komari_access.log {
roll_size 100mb
roll_keep 5
}
format json
}
}
</syntaxhighlight>

; 🔍 Debug 与排错逻辑 / Debugging & Troubleshooting Logic
: '''WebSocket 断连与 Cloudflare 避坑： / WebSocket Disconnection & Cloudflare Pitfalls:''' Komari 极其依赖 WebSocket 进行实时数据推送（Caddy v2 默认原生支持 WebSocket 转发）。如果你发现面板卡死不刷新，请首先检查链路。如果你在前端套用了 Cloudflare，请务必检查：1. 网络设置中的 "WebSockets" 选项是否开启；2. SSL/TLS 加密模式必须设置为 "Full" 或 "Full (Strict)"，否则会导致循环重定向或握手失败。 (Komari heavily relies on WebSocket for real-time data push. If the panel freezes, check the link first. If using Cloudflare, ensure: 1. "WebSockets" is enabled in Network settings; 2. SSL/TLS mode is set to "Full" or "Full (Strict)" to prevent redirect loops or handshake failures.)
: '''日志分析排错： / Log Analysis Troubleshooting:''' 这里专门配置了 `/var/log/caddy/komari_access.log`。如果配置完出现 502 错误，切忌盲目瞎猜，直接使用 `tail -f /var/log/caddy/komari_access.log` 追踪日志，通过分析 HTTP 状态码和 Upstream 报错来精准定位问题。 (We specifically configured `/var/log/caddy/komari_access.log`. If a 502 error occurs, do not guess blindly; directly use `tail -f` to track the log and pinpoint the issue by analyzing HTTP status codes and Upstream errors.)

=== 2. 重载 Caddy 生效 / Reload Caddy to Apply ===
<syntaxhighlight lang="bash">
caddy reload --config /etc/caddy/Caddyfile
</syntaxhighlight>

== 第三步：多节点 Agent 接入实战 / Step 3: Multi-Node Agent Integration Practice ==

主控端稳如泰山后，现在我们可以把其他 VPS 统一接入面板进行管理了。
With the controller stable as a mountain, we can now integrate your other VPS nodes into the dashboard for unified management.

=== 1. 主控端获取连接参数 / Get Connection Parameters from Controller ===
登录你的 Komari 面板后台，点击“添加节点”。系统会为你生成一串专属的 Agent 连接命令，其中包含了你的 '''API 地址''' 和对应节点的 '''Secret Key'''。
Log into your Komari dashboard backend and click "Add Node". The system will generate a dedicated Agent connection command containing your '''API Address''' and the corresponding node's '''Secret Key'''.

=== 2. 在被控节点安装 Agent / Install Agent on the Managed Node ===
通过 SSH 登录到你需要监控的服务器，为了保持系统整洁，我们依然推荐使用 Docker 运行 Agent：
Log into the server you want to monitor via SSH. To keep the system clean, we still recommend running the Agent using Docker:

<syntaxhighlight lang="bash">
docker run -d \
--name komari-agent \
--restart unless-stopped \
--net=host \
-v /proc:/host/proc:ro \
-v /sys:/host/sys:ro \
-v /:/rootfs:ro \
ghcr.io/komari-monitor/komari-agent:latest \
-api "wss://status.yourdomain.com/api/v1/ws" \
-secret "你的节点专属SecretKey"
</syntaxhighlight>

; 🔍 Debug 与分析逻辑 / Debugging & Analysis Logic
: '''参数解析 `net=host` 与目录映射： / Parameter Parsing `net=host` and Directory Mapping:''' Agent 需要真实获取宿主机的网卡流量、CPU 和内存信息，因此必须使用 `--net=host` 共享网络命名空间，并将宿主机的 `/proc` 和 `/sys` 以只读 (`ro`) 模式映射进容器。 (The Agent needs to fetch real host network traffic, CPU, and memory info, so it must use `--net=host` to share the network namespace and map the host's `/proc` and `/sys` into the container in read-only (`ro`) mode.)
: '''协议检查： / Protocol Check:''' 确保 `-api` 参数使用的是 `wss://`（WebSocket Secure），因为我们的主控端已经配置了严格的 HTTPS。如果填成 `ws://` 将会被 Caddy 拒绝连接。 (Ensure the `-api` parameter uses `wss://` (WebSocket Secure) since our controller is configured with strict HTTPS. If filled as `ws://`, the connection will be rejected by Caddy.)

大功告成！现在，你可以坐在屏幕前，看着所有服务器的绿色心跳线，享受数据掌控在自己手中的极致快感了。
Mission accomplished! Now, you can sit in front of the screen, watch the green heartbeat lines of all your servers, and enjoy the ultimate thrill of having your data under your own control.

== 进阶探索与安全延展 / Advanced Exploration & Security Extension ==

Komari 其实还有更多强大的进阶玩法等待你发掘。例如，你可以配置 Telegram Bot 接收服务器到期续费、流量预警、系统高负载以及延迟异常的实时推送（测速节点 IP 推荐在 zstaticcdn.com 获取）。此外，面板还支持高度定制化的美化主题。关于这些高级配置，篇幅所限不再展开，强烈建议访问 GitHub 搜索 `komari` 或直达官方文档 (https://komari-document.pages.dev/) 自行探索学习。 Komari actually has many more powerful advanced features waiting for you to discover. For instance, you can configure a Telegram Bot to receive real-time push notifications for server expiration renewals, traffic warnings, high system load, and abnormal latency (we recommend getting speed test node IPs from zstaticcdn.com). Additionally, the dashboard supports highly customizable aesthetic themes. Due to space constraints, we won't expand on these advanced configurations here. It is highly recommended to search for `komari` on GitHub or visit the official documentation (https://komari-document.pages.dev/) to explore and learn on your own.

最后，虽然瓦工的线路极佳，但公网环境险恶。为了预防潜在的 DDoS 攻击或端口嗅探，你可以进一步研究如何为面板或网站套上“赛博菩萨” Cloudflare 的 Proxy (CDN) 甚至配置更为安全的 Cloudflare Tunnel。这些都是 VPS 玩家进阶的必修课，期待你查阅相关资料，继续点亮你的网络安全技能树！ Finally, although BandwagonHost's routing is excellent, the public internet environment is perilous. To prevent potential DDoS attacks or port sniffing, you can further research how to put your dashboard or website behind the "Cyber Bodhisattva" Cloudflare's Proxy (CDN) or even configure the much safer Cloudflare Tunnel. These are required courses for advanced VPS players. We look forward to you looking up relevant materials and continuing to light up your network security skill tree!

----
''Created by AlexLynn for md5.pw Community.''
[[index.php?title=Category:500 常见应用指南 — Application Guides]]

搬瓦工 CN2 GIA 与 Komari：轻量级 Go 语言探针呈现三网顶级网络艺术

2026-03-01T06:02:48Z

AlexLynn：

搬瓦工 CN2 GIA 与 Komari：轻量级 Go 语言探针呈现三网顶级网络艺术

2026-03-01T06:00:28Z

AlexLynn：

= 搬瓦工 CN2 GIA 与 Komari：轻量级 Go 语言探针呈现三网顶级网络艺术 =
= BandwagonHost CN2 GIA & Komari: A Lightweight Go Probe Presenting the Art of Top-Tier Networking =

搬瓦工（BandwagonHost）的 CN2 GIA 线路堪称 VPS 界的网络天花板。其三网顶级直连架构不仅带来了令人惊叹的极致超低延迟，更是在晚高峰也能保持全天候 '''0 丢包''' 的神话。这种丝滑、纯粹的网络体验，如果不配上一个优秀的现代监控探针将其彻底可视化，简直是暴殄天物！
BandwagonHost's CN2 GIA routing is arguably the network ceiling of the VPS world. Its top-tier direct connection across all three major networks brings not only amazingly stable and low latency but also maintains a mythical '''0 packet loss''' even during peak hours. Such a silky-smooth and pure network experience would be an absolute waste if not thoroughly visualized with an excellent modern monitoring dashboard!

为了不辜负瓦工如此顶级的线路，我们需要一款同样极致的探针。今天的主角 '''Komari''' 正是为此而生。
To live up to such top-tier routing from BandwagonHost, we need an equally ultimate probe. Today's protagonist, '''Komari''', was born for this exact purpose.

== 为什么选择 Komari？ / Why Choose Komari? ==

[[File:Komari.png|thumb]]

市面上的服务器监控面板琳琅满目，但 Komari 凭借其独特的架构脱颖而出：
The market is full of server monitoring panels, but Komari stands out with its unique architecture:

* '''基于 Go 语言构建 / Built with Go'''：Komari 的主控端和 Agent 均采用 Golang 编写。天生的高并发优势和出色的内存管理，使得它能以极低的系统资源占用，轻松处理并发连接。 Komari's controller and agent are both written in Golang. Its inherent high-concurrency advantages and excellent memory management allow it to easily handle concurrent connections with extremely low system resource consumption.
* '''优雅的 Controller + Agent 架构 / Elegant Controller + Agent Architecture'''：主控面板（Controller）负责节点管理与数据展示，轻量 Agent 负责采集系统指标，并通过 WebSocket 持久连接上报数据。这种设计避免了传统轮询式监控产生的大量请求开销，在低带宽 VPS 环境下依然能够保持高实时性与极低资源占用。 The controller dashboard is responsible for node management and data presentation, while the lightweight Agent collects system metrics and reports data via persistent WebSocket connections. This design avoids the massive request overhead generated by traditional polling-based monitoring, maintaining high real-time performance and extremely low resource usage even in low-bandwidth VPS environments.
* '''极致轻量与极简主义 / Extreme Lightweight & Minimalism'''：监控工具本身不应成为服务器的负担。Komari 没有臃肿的依赖库，对于极其珍贵的瓦工服务器资源来说，运行它几乎是“零感知”的。 Monitoring tools themselves shouldn't be a burden on the server. Komari has no bloated dependency libraries; for the extremely precious BandwagonHost server resources, running it is almost "zero-perception".

本文将通过严谨的逻辑，一步一步完成 Komari 的基础部署、高级安全反代，以及多节点 Agent 的接入。
This article will walk through the basic deployment of Komari, advanced secure reverse proxy configuration, and multi-node Agent integration, step-by-step with rigorous logic.

== 第一步：基础安装 - 部署 Komari 主控 / Step 1: Basic Installation - Deploying Komari Controller ==

无论你是在白天使用 Windows 办公，还是使用 macOS 的终端，请先通过 SSH 接入你的搬瓦工服务器。为了保证环境的隔离性和未来排错的便利性，我们采用 Docker Compose 进行部署。
Whether you are working on Windows during the day or using the macOS terminal, please SSH into your BandwagonHost server first. To ensure environmental isolation and ease of future troubleshooting, we will deploy using Docker Compose.

=== 1. 创建项目目录结构 / Create Project Directory Structure ===
<syntaxhighlight lang="bash">
mkdir -p /opt/komari && cd /opt/komari
</syntaxhighlight>

=== 2. 编写 Docker Compose 配置文件 / Write the Docker Compose Configuration ===
创建并编辑 Docker Compose 配置文件：
Create and edit the Docker Compose configuration file:
<syntaxhighlight lang="bash">
nano docker-compose.yml
</syntaxhighlight>

写入以下内容（注意端口映射的安全加固与版本控制）：
Write the following content (note the security hardening of port mapping and version control):
<syntaxhighlight lang="yaml">
version: '3.8'
services:
komari:
# 生产环境建议将 latest 替换为具体的 release 版本号以保证系统稳定性
# For production, it's recommended to replace 'latest' with a specific release version to ensure system stability
image: ghcr.io/komari-monitor/komari:latest
container_name: komari
restart: unless-stopped
ports:
- "127.0.0.1:25774:25774"
volumes:
- ./data:/app/data
</syntaxhighlight>

; 🔍 Debug 与安全分析逻辑 / Debugging & Security Analysis Logic
: '''为什么映射 `/app/data`？ / Why map `/app/data`?''' 探针的面板设置、节点信息都物理存储在这个目录。如果不做映射，一旦容器重启或销毁，所有配置数据将全部丢失。 (The panel settings and node information are physically stored in this directory. If not mapped, all configuration data will be completely lost once the container restarts or is destroyed.)
: '''安全加固 `127.0.0.1`： / Security Hardening `127.0.0.1`:''' 绑定本地环回地址 `127.0.0.1`，杜绝被批量扫描及 0day 漏洞攻击的潜在威胁。 (Binding to the local loopback address `127.0.0.1` eliminates the potential threat of being bulk-scanned and attacked by 0-day vulnerabilities.)

=== 3. 启动服务 / Start the Service ===
<syntaxhighlight lang="bash">
docker compose up -d
</syntaxhighlight>
启动后，执行 `docker logs komari` 查看系统自动生成的初始管理员账号和密码。
After starting, execute `docker logs komari` to view the initial admin account and password automatically generated by the system.

== 第二步：进阶配置 - Caddy 详尽反代与 HTTPS / Step 2: Advanced Configuration - Detailed Caddy Reverse Proxy & HTTPS ==

在前端，我们将使用 Caddy 申请免费证书并进行反向代理，将安全的 HTTPS 流量转发给内网的 Komari。
On the frontend, we will use Caddy to request a free certificate and set up a reverse proxy to forward secure HTTPS traffic to the internal Komari service.

=== 1. 编辑 Caddyfile / Edit the Caddyfile ===
打开你的 Caddy 配置文件（通常位于 `/etc/caddy/Caddyfile`）：
Open your Caddy config file (usually located at `/etc/caddy/Caddyfile`):
<syntaxhighlight lang="bash">
nano /etc/caddy/Caddyfile
</syntaxhighlight>

写入以下配置（请将 `status.yourdomain.com` 替换为你的真实域名）：
Write the following configuration (please replace `status.yourdomain.com` with your real domain name):
<syntaxhighlight lang="text">
status.yourdomain.com {
# 启用现代 TLS 协议 / Enable modern TLS protocols
tls {
protocols tls1.2 tls1.3
}

# 反向代理至本地环回地址的 Komari 端口 / Reverse proxy to the Komari port on the local loopback address
reverse_proxy localhost:25774 {
# 传递真实访客 IP 和协议 / Pass real visitor IP and protocol
header_up Host {host}
header_up X-Real-IP {remote}
header_up X-Forwarded-For {remote}
header_up X-Forwarded-Proto {scheme}
}

# 启用压缩机制以加快探针面板加载速度 / Enable compression to speed up dashboard loading
encode gzip zstd

# 现代且严谨的安全响应头设置 / Modern and rigorous security response headers setup
header {
# 注意：此处未加 preload，只有在你准备将域名提交到浏览器 HSTS preload list 时才建议加入 preload 参数
# Note: 'preload' is omitted here; it is only recommended if you plan to submit the domain to the browser HSTS preload list
Strict-Transport-Security "max-age=31536000; includeSubDomains"
X-Content-Type-Options "nosniff"
X-Frame-Options "SAMEORIGIN"
Referrer-Policy "strict-origin-when-cross-origin"
}

# 详尽的访问日志记录，为未来排错提供明确的数据分析支持 / Detailed access logging to provide clear data support for future debugging
log {
output file /var/log/caddy/komari_access.log {
roll_size 100mb
roll_keep 5
}
format json
}
}
</syntaxhighlight>

; 🔍 Debug 与排错逻辑 / Debugging & Troubleshooting Logic
: '''WebSocket 断连与 Cloudflare 避坑： / WebSocket Disconnection & Cloudflare Pitfalls:''' Komari 极其依赖 WebSocket 进行实时数据推送（Caddy v2 默认原生支持 WebSocket 转发）。如果你发现面板卡死不刷新，请首先检查链路。如果你在前端套用了 Cloudflare，请务必检查：1. 网络设置中的 "WebSockets" 选项是否开启；2. SSL/TLS 加密模式必须设置为 "Full" 或 "Full (Strict)"，否则会导致循环重定向或握手失败。 (Komari heavily relies on WebSocket for real-time data push. If the panel freezes, check the link first. If using Cloudflare, ensure: 1. "WebSockets" is enabled in Network settings; 2. SSL/TLS mode is set to "Full" or "Full (Strict)" to prevent redirect loops or handshake failures.)
: '''日志分析排错： / Log Analysis Troubleshooting:''' 这里专门配置了 `/var/log/caddy/komari_access.log`。如果配置完出现 502 错误，切忌盲目瞎猜，直接使用 `tail -f /var/log/caddy/komari_access.log` 追踪日志，通过分析 HTTP 状态码和 Upstream 报错来精准定位问题。 (We specifically configured `/var/log/caddy/komari_access.log`. If a 502 error occurs, do not guess blindly; directly use `tail -f` to track the log and pinpoint the issue by analyzing HTTP status codes and Upstream errors.)

=== 2. 重载 Caddy 生效 / Reload Caddy to Apply ===
<syntaxhighlight lang="bash">
caddy reload --config /etc/caddy/Caddyfile
</syntaxhighlight>

== 第三步：多节点 Agent 接入实战 / Step 3: Multi-Node Agent Integration Practice ==

主控端稳如泰山后，现在我们可以把其他 VPS 统一接入面板进行管理了。
With the controller stable as a mountain, we can now integrate your other VPS nodes into the dashboard for unified management.

=== 1. 主控端获取连接参数 / Get Connection Parameters from Controller ===
登录你的 Komari 面板后台，点击“添加节点”。系统会为你生成一串专属的 Agent 连接命令，其中包含了你的 '''API 地址''' 和对应节点的 '''Secret Key'''。
Log into your Komari dashboard backend and click "Add Node". The system will generate a dedicated Agent connection command containing your '''API Address''' and the corresponding node's '''Secret Key'''.

=== 2. 在被控节点安装 Agent / Install Agent on the Managed Node ===
通过 SSH 登录到你需要监控的服务器，为了保持系统整洁，我们依然推荐使用 Docker 运行 Agent：
Log into the server you want to monitor via SSH. To keep the system clean, we still recommend running the Agent using Docker:

<syntaxhighlight lang="bash">
docker run -d \
--name komari-agent \
--restart unless-stopped \
--net=host \
-v /proc:/host/proc:ro \
-v /sys:/host/sys:ro \
-v /:/rootfs:ro \
ghcr.io/komari-monitor/komari-agent:latest \
-api "wss://status.yourdomain.com/api/v1/ws" \
-secret "你的节点专属SecretKey"
</syntaxhighlight>

; 🔍 Debug 与分析逻辑 / Debugging & Analysis Logic
: '''参数解析 `net=host` 与目录映射： / Parameter Parsing `net=host` and Directory Mapping:''' Agent 需要真实获取宿主机的网卡流量、CPU 和内存信息，因此必须使用 `--net=host` 共享网络命名空间，并将宿主机的 `/proc` 和 `/sys` 以只读 (`ro`) 模式映射进容器。 (The Agent needs to fetch real host network traffic, CPU, and memory info, so it must use `--net=host` to share the network namespace and map the host's `/proc` and `/sys` into the container in read-only (`ro`) mode.)
: '''协议检查： / Protocol Check:''' 确保 `-api` 参数使用的是 `wss://`（WebSocket Secure），因为我们的主控端已经配置了严格的 HTTPS。如果填成 `ws://` 将会被 Caddy 拒绝连接。 (Ensure the `-api` parameter uses `wss://` (WebSocket Secure) since our controller is configured with strict HTTPS. If filled as `ws://`, the connection will be rejected by Caddy.)

大功告成！现在，你可以坐在屏幕前，看着所有服务器的绿色心跳线，享受数据掌控在自己手中的极致快感了。
Mission accomplished! Now, you can sit in front of the screen, watch the green heartbeat lines of all your servers, and enjoy the ultimate thrill of having your data under your own control.

== 进阶探索与安全延展 / Advanced Exploration & Security Extension ==

Komari 其实还有更多强大的进阶玩法等待你发掘。例如，你可以配置 Telegram Bot 接收服务器到期续费、流量预警、系统高负载以及延迟异常的实时推送（测速节点 IP 推荐在 zstaticcdn.com 获取）。此外，面板还支持高度定制化的美化主题。关于这些高级配置，篇幅所限不再展开，强烈建议访问 GitHub 搜索 `komari` 或直达官方文档 (https://komari-document.pages.dev/) 自行探索学习。 Komari actually has many more powerful advanced features waiting for you to discover. For instance, you can configure a Telegram Bot to receive real-time push notifications for server expiration renewals, traffic warnings, high system load, and abnormal latency (we recommend getting speed test node IPs from zstaticcdn.com). Additionally, the dashboard supports highly customizable aesthetic themes. Due to space constraints, we won't expand on these advanced configurations here. It is highly recommended to search for `komari` on GitHub or visit the official documentation (https://komari-document.pages.dev/) to explore and learn on your own.

最后，虽然瓦工的线路极佳，但公网环境险恶。为了预防潜在的 DDoS 攻击或端口嗅探，你可以进一步研究如何为面板或网站套上“赛博菩萨” Cloudflare 的 Proxy (CDN) 甚至配置更为安全的 Cloudflare Tunnel。这些都是 VPS 玩家进阶的必修课，期待你查阅相关资料，继续点亮你的网络安全技能树！ Finally, although BandwagonHost's routing is excellent, the public internet environment is perilous. To prevent potential DDoS attacks or port sniffing, you can further research how to put your dashboard or website behind the "Cyber Bodhisattva" Cloudflare's Proxy (CDN) or even configure the much safer Cloudflare Tunnel. These are required courses for advanced VPS players. We look forward to you looking up relevant materials and continuing to light up your network security skill tree!

----
''Created by AlexLynn for md5.pw Community.''
[[index.php?title=Category:500 常见应用指南 — Application Guides]]

搬瓦工 CN2 GIA 与 Komari：轻量级 Go 语言探针呈现三网顶级网络艺术

2026-03-01T05:47:50Z

AlexLynn：

= 搬瓦工 CN2 GIA 与 Komari：轻量级 Go 语言探针呈现三网顶级网络艺术 =
= BandwagonHost CN2 GIA & Komari: A Lightweight Go Probe Presenting the Art of Top-Tier Networking =

搬瓦工（BandwagonHost）的 CN2 GIA 线路堪称 VPS 界的网络天花板。其三网顶级直连架构不仅带来了令人惊叹的极致超低延迟，更是在晚高峰也能保持全天候 '''0 丢包''' 的神话。这种丝滑、纯粹的网络体验，如果不配上一个优秀的现代监控探针将其彻底可视化，简直是暴殄天物！
BandwagonHost's CN2 GIA routing is arguably the network ceiling of the VPS world. Its top-tier direct connection across all three major networks brings not only amazingly stable and low latency but also maintains a mythical '''0 packet loss''' even during peak hours. Such a silky-smooth and pure network experience would be an absolute waste if not thoroughly visualized with an excellent modern monitoring dashboard!

为了不辜负瓦工如此顶级的线路，我们需要一款同样极致的探针。今天的主角 '''Komari''' 正是为此而生。
To live up to such top-tier routing from BandwagonHost, we need an equally ultimate probe. Today's protagonist, '''Komari''', was born for this exact purpose.

== 为什么选择 Komari？ / Why Choose Komari? ==

[[File:Komari.png|thumb]]

市面上的服务器监控面板琳琅满目，但 Komari 凭借其独特的架构脱颖而出：
The market is full of server monitoring panels, but Komari stands out with its unique architecture:

* '''基于 Go 语言构建 / Built with Go'''：Komari 的主控端和 Agent 均采用 Golang 编写。天生的高并发优势和出色的内存管理，使得它能以极低的系统资源占用，轻松处理并发连接。 Komari's controller and agent are both written in Golang. Its inherent high-concurrency advantages and excellent memory management allow it to easily handle concurrent connections with extremely low system resource consumption.
* '''优雅的 Controller + Agent 架构 / Elegant Controller + Agent Architecture'''：主控面板（Controller）负责节点管理与数据展示，轻量 Agent 负责采集系统指标，并通过 WebSocket 持久连接上报数据。这种设计避免了传统轮询式监控产生的大量请求开销，在低带宽 VPS 环境下依然能够保持高实时性与极低资源占用。 The controller dashboard is responsible for node management and data presentation, while the lightweight Agent collects system metrics and reports data via persistent WebSocket connections. This design avoids the massive request overhead generated by traditional polling-based monitoring, maintaining high real-time performance and extremely low resource usage even in low-bandwidth VPS environments.
* '''极致轻量与极简主义 / Extreme Lightweight & Minimalism'''：监控工具本身不应成为服务器的负担。Komari 没有臃肿的依赖库，对于极其珍贵的瓦工服务器资源来说，运行它几乎是“零感知”的。 Monitoring tools themselves shouldn't be a burden on the server. Komari has no bloated dependency libraries; for the extremely precious BandwagonHost server resources, running it is almost "zero-perception".

本文将通过严谨的逻辑，一步一步完成 Komari 的基础部署、高级安全反代，以及多节点 Agent 的接入。
This article will walk through the basic deployment of Komari, advanced secure reverse proxy configuration, and multi-node Agent integration, step-by-step with rigorous logic.

== 第一步：基础安装 - 部署 Komari 主控 / Step 1: Basic Installation - Deploying Komari Controller ==

无论你是在白天使用 Windows 办公，还是使用 macOS 的终端，请先通过 SSH 接入你的搬瓦工服务器。为了保证环境的隔离性和未来排错的便利性，我们采用 Docker Compose 进行部署。
Whether you are working on Windows during the day or using the macOS terminal, please SSH into your BandwagonHost server first. To ensure environmental isolation and ease of future troubleshooting, we will deploy using Docker Compose.

=== 1. 创建项目目录结构 / Create Project Directory Structure ===
<syntaxhighlight lang="bash">
mkdir -p /opt/komari && cd /opt/komari
</syntaxhighlight>

=== 2. 编写 Docker Compose 配置文件 / Write the Docker Compose Configuration ===
创建并编辑 Docker Compose 配置文件：
Create and edit the Docker Compose configuration file:
<syntaxhighlight lang="bash">
nano docker-compose.yml
</syntaxhighlight>

写入以下内容（注意端口映射的安全加固与版本控制）：
Write the following content (note the security hardening of port mapping and version control):
<syntaxhighlight lang="yaml">
version: '3.8'
services:
komari:
# 生产环境建议将 latest 替换为具体的 release 版本号以保证系统稳定性
# For production, it's recommended to replace 'latest' with a specific release version to ensure system stability
image: ghcr.io/komari-monitor/komari:latest
container_name: komari
restart: unless-stopped
ports:
- "127.0.0.1:25774:25774"
volumes:
- ./data:/app/data
</syntaxhighlight>

; 🔍 Debug 与安全分析逻辑 / Debugging & Security Analysis Logic
: '''为什么映射 `/app/data`？ / Why map `/app/data`?''' 探针的面板设置、节点信息都物理存储在这个目录。如果不做映射，一旦容器重启或销毁，所有配置数据将全部丢失。 (The panel settings and node information are physically stored in this directory. If not mapped, all configuration data will be completely lost once the container restarts or is destroyed.)
: '''安全加固 `127.0.0.1`： / Security Hardening `127.0.0.1`:''' 绑定本地环回地址 `127.0.0.1`，杜绝被批量扫描及 0day 漏洞攻击的潜在威胁。 (Binding to the local loopback address `127.0.0.1` eliminates the potential threat of being bulk-scanned and attacked by 0-day vulnerabilities.)

=== 3. 启动服务 / Start the Service ===
<syntaxhighlight lang="bash">
docker compose up -d
</syntaxhighlight>
启动后，执行 `docker logs komari` 查看系统自动生成的初始管理员账号和密码。
After starting, execute `docker logs komari` to view the initial admin account and password automatically generated by the system.

== 第二步：进阶配置 - Caddy 详尽反代与 HTTPS / Step 2: Advanced Configuration - Detailed Caddy Reverse Proxy & HTTPS ==

在前端，我们将使用 Caddy 申请免费证书并进行反向代理，将安全的 HTTPS 流量转发给内网的 Komari。
On the frontend, we will use Caddy to request a free certificate and set up a reverse proxy to forward secure HTTPS traffic to the internal Komari service.

=== 1. 编辑 Caddyfile / Edit the Caddyfile ===
打开你的 Caddy 配置文件（通常位于 `/etc/caddy/Caddyfile`）：
Open your Caddy config file (usually located at `/etc/caddy/Caddyfile`):
<syntaxhighlight lang="bash">
nano /etc/caddy/Caddyfile
</syntaxhighlight>

写入以下配置（请将 `status.yourdomain.com` 替换为你的真实域名）：
Write the following configuration (please replace `status.yourdomain.com` with your real domain name):
<syntaxhighlight lang="text">
status.yourdomain.com {
# 启用现代 TLS 协议 / Enable modern TLS protocols
tls {
protocols tls1.2 tls1.3
}

# 反向代理至本地环回地址的 Komari 端口 / Reverse proxy to the Komari port on the local loopback address
reverse_proxy localhost:25774 {
# 传递真实访客 IP 和协议 / Pass real visitor IP and protocol
header_up Host {host}
header_up X-Real-IP {remote}
header_up X-Forwarded-For {remote}
header_up X-Forwarded-Proto {scheme}
}

# 启用压缩机制以加快探针面板加载速度 / Enable compression to speed up dashboard loading
encode gzip zstd

# 现代且严谨的安全响应头设置 / Modern and rigorous security response headers setup
header {
# 注意：此处未加 preload，只有在你准备将域名提交到浏览器 HSTS preload list 时才建议加入 preload 参数
# Note: 'preload' is omitted here; it is only recommended if you plan to submit the domain to the browser HSTS preload list
Strict-Transport-Security "max-age=31536000; includeSubDomains"
X-Content-Type-Options "nosniff"
X-Frame-Options "SAMEORIGIN"
Referrer-Policy "strict-origin-when-cross-origin"
}

# 详尽的访问日志记录，为未来排错提供明确的数据分析支持 / Detailed access logging to provide clear data support for future debugging
log {
output file /var/log/caddy/komari_access.log {
roll_size 100mb
roll_keep 5
}
format json
}
}
</syntaxhighlight>

; 🔍 Debug 与排错逻辑 / Debugging & Troubleshooting Logic
: '''WebSocket 断连与 Cloudflare 避坑： / WebSocket Disconnection & Cloudflare Pitfalls:''' Komari 极其依赖 WebSocket 进行实时数据推送（Caddy v2 默认原生支持 WebSocket 转发）。如果你发现面板卡死不刷新，请首先检查链路。如果你在前端套用了 Cloudflare，请务必检查：1. 网络设置中的 "WebSockets" 选项是否开启；2. SSL/TLS 加密模式必须设置为 "Full" 或 "Full (Strict)"，否则会导致循环重定向或握手失败。 (Komari heavily relies on WebSocket for real-time data push. If the panel freezes, check the link first. If using Cloudflare, ensure: 1. "WebSockets" is enabled in Network settings; 2. SSL/TLS mode is set to "Full" or "Full (Strict)" to prevent redirect loops or handshake failures.)
: '''日志分析排错： / Log Analysis Troubleshooting:''' 这里专门配置了 `/var/log/caddy/komari_access.log`。如果配置完出现 502 错误，切忌盲目瞎猜，直接使用 `tail -f /var/log/caddy/komari_access.log` 追踪日志，通过分析 HTTP 状态码和 Upstream 报错来精准定位问题。 (We specifically configured `/var/log/caddy/komari_access.log`. If a 502 error occurs, do not guess blindly; directly use `tail -f` to track the log and pinpoint the issue by analyzing HTTP status codes and Upstream errors.)

=== 2. 重载 Caddy 生效 / Reload Caddy to Apply ===
<syntaxhighlight lang="bash">
caddy reload --config /etc/caddy/Caddyfile
</syntaxhighlight>

== 第三步：多节点 Agent 接入实战 / Step 3: Multi-Node Agent Integration Practice ==

主控端稳如泰山后，现在我们可以把其他 VPS 统一接入面板进行管理了。
With the controller stable as a mountain, we can now integrate your other VPS nodes into the dashboard for unified management.

=== 1. 主控端获取连接参数 / Get Connection Parameters from Controller ===
登录你的 Komari 面板后台，点击“添加节点”。系统会为你生成一串专属的 Agent 连接命令，其中包含了你的 '''API 地址''' 和对应节点的 '''Secret Key'''。
Log into your Komari dashboard backend and click "Add Node". The system will generate a dedicated Agent connection command containing your '''API Address''' and the corresponding node's '''Secret Key'''.

=== 2. 在被控节点安装 Agent / Install Agent on the Managed Node ===
通过 SSH 登录到你需要监控的服务器，为了保持系统整洁，我们依然推荐使用 Docker 运行 Agent：
Log into the server you want to monitor via SSH. To keep the system clean, we still recommend running the Agent using Docker:

<syntaxhighlight lang="bash">
docker run -d \
--name komari-agent \
--restart unless-stopped \
--net=host \
-v /proc:/host/proc:ro \
-v /sys:/host/sys:ro \
-v /:/rootfs:ro \
ghcr.io/komari-monitor/komari-agent:latest \
-api "wss://status.yourdomain.com/api/v1/ws" \
-secret "你的节点专属SecretKey"
</syntaxhighlight>

; 🔍 Debug 与分析逻辑 / Debugging & Analysis Logic
: '''参数解析 `net=host` 与目录映射： / Parameter Parsing `net=host` and Directory Mapping:''' Agent 需要真实获取宿主机的网卡流量、CPU 和内存信息，因此必须使用 `--net=host` 共享网络命名空间，并将宿主机的 `/proc` 和 `/sys` 以只读 (`ro`) 模式映射进容器。 (The Agent needs to fetch real host network traffic, CPU, and memory info, so it must use `--net=host` to share the network namespace and map the host's `/proc` and `/sys` into the container in read-only (`ro`) mode.)
: '''协议检查： / Protocol Check:''' 确保 `-api` 参数使用的是 `wss://`（WebSocket Secure），因为我们的主控端已经配置了严格的 HTTPS。如果填成 `ws://` 将会被 Caddy 拒绝连接。 (Ensure the `-api` parameter uses `wss://` (WebSocket Secure) since our controller is configured with strict HTTPS. If filled as `ws://`, the connection will be rejected by Caddy.)

大功告成！现在，你可以坐在屏幕前，看着所有服务器的绿色心跳线，享受数据掌控在自己手中的极致快感了。
Mission accomplished! Now, you can sit in front of the screen, watch the green heartbeat lines of all your servers, and enjoy the ultimate thrill of having your data under your own control.

----
''Created by AlexLynn for md5.pw Community.''
[[Category:500 常见应用指南 — Application Guides]]

搬瓦工 CN2 GIA 与 Komari：轻量级 Go 语言探针呈现三网顶级网络艺术

2026-03-01T05:41:25Z

AlexLynn：

= 搬瓦工 CN2 GIA 与 Komari：轻量级 Go 语言探针呈现三网顶级网络艺术 =
= BandwagonHost CN2 GIA & Komari: A Lightweight Go Probe Presenting the Art of Top-Tier Networking =

搬瓦工（BandwagonHost）的 CN2 GIA 线路堪称 VPS 界的网络天花板。其三网顶级直连架构不仅带来了令人惊叹的极致超低延迟，更是在晚高峰也能保持全天候 '''0 丢包''' 的神话。这种丝滑、纯粹的网络体验，如果不配上一个优秀的现代监控探针将其彻底可视化，简直是暴殄天物！
BandwagonHost's CN2 GIA routing is arguably the network ceiling of the VPS world. Its top-tier direct connection across all three major networks brings not only amazingly stable and low latency but also maintains a mythical '''0 packet loss''' even during peak hours. Such a silky-smooth and pure network experience would be an absolute waste if not thoroughly visualized with an excellent modern monitoring dashboard!

为了不辜负瓦工如此顶级的线路，我们需要一款同样极致的探针。今天的主角 '''Komari''' 正是为此而生。
To live up to such top-tier routing from BandwagonHost, we need an equally ultimate probe. Today's protagonist, '''Komari''', was born for this exact purpose.

== 为什么选择 Komari？ / Why Choose Komari? ==

[[File:Komari.png|thumb]]

市面上的服务器监控面板琳琅满目，但 Komari 凭借其独特的架构脱颖而出：
The market is full of server monitoring panels, but Komari stands out with its unique architecture:

* '''基于 Go 语言构建 / Built with Go'''：Komari 的主控端和 Agent 均采用 Golang 编写。天生的高并发优势和出色的内存管理，使得它能以极低的系统资源占用，轻松处理并发连接。 Komari's controller and agent are both written in Golang. Its inherent high-concurrency advantages and excellent memory management allow it to easily handle concurrent connections with extremely low system resource consumption.
* '''优雅的 Controller + Agent 架构 / Elegant Controller + Agent Architecture'''：主控面板（Controller）负责节点管理与数据展示，轻量 Agent 负责采集系统指标，并通过 WebSocket 持久连接上报数据。这种设计避免了传统轮询式监控产生的大量请求开销，在低带宽 VPS 环境下依然能够保持高实时性与极低资源占用。 The controller dashboard is responsible for node management and data presentation, while the lightweight Agent collects system metrics and reports data via persistent WebSocket connections. This design avoids the massive request overhead generated by traditional polling-based monitoring, maintaining high real-time performance and extremely low resource usage even in low-bandwidth VPS environments.
* '''极致轻量与极简主义 / Extreme Lightweight & Minimalism'''：监控工具本身不应成为服务器的负担。Komari 没有臃肿的依赖库，对于极其珍贵的瓦工服务器资源来说，运行它几乎是“零感知”的。 Monitoring tools themselves shouldn't be a burden on the server. Komari has no bloated dependency libraries; for the extremely precious BandwagonHost server resources, running it is almost "zero-perception".

本文将通过严谨的逻辑，一步一步完成 Komari 的基础部署、高级安全反代，以及多节点 Agent 的接入。
This article will walk through the basic deployment of Komari, advanced secure reverse proxy configuration, and multi-node Agent integration, step-by-step with rigorous logic.

== 第一步：基础安装 - 部署 Komari 主控 / Step 1: Basic Installation - Deploying Komari Controller ==

无论你是在白天使用 Windows 办公，还是使用 macOS 的终端，请先通过 SSH 接入你的搬瓦工服务器。为了保证环境的隔离性和未来排错的便利性，我们采用 Docker Compose 进行部署。
Whether you are working on Windows during the day or using the macOS terminal, please SSH into your BandwagonHost server first. To ensure environmental isolation and ease of future troubleshooting, we will deploy using Docker Compose.

=== 1. 创建项目目录结构 / Create Project Directory Structure ===
<syntaxhighlight lang="bash">
mkdir -p /opt/komari && cd /opt/komari
</syntaxhighlight>

=== 2. 编写 Docker Compose 配置文件 / Write the Docker Compose Configuration ===
创建并编辑 Docker Compose 配置文件：
Create and edit the Docker Compose configuration file:
<syntaxhighlight lang="bash">
nano docker-compose.yml
</syntaxhighlight>

写入以下内容（注意端口映射的安全加固与版本控制）：
Write the following content (note the security hardening of port mapping and version control):
<syntaxhighlight lang="yaml">
version: '3.8'
services:
komari:
# 生产环境建议将 latest 替换为具体的 release 版本号以保证系统稳定性
# For production, it's recommended to replace 'latest' with a specific release version to ensure system stability
image: ghcr.io/komari-monitor/komari:latest
container_name: komari
restart: unless-stopped
ports:
- "127.0.0.1:25774:25774"
volumes:
- ./data:/app/data
</syntaxhighlight>

; 🔍 Debug 与安全分析逻辑 / Debugging & Security Analysis Logic
: '''为什么映射 `/app/data`？ / Why map `/app/data`?''' 探针的面板设置、节点信息都物理存储在这个目录。如果不做映射，一旦容器重启或销毁，所有配置数据将全部丢失。 (The panel settings and node information are physically stored in this directory. If not mapped, all configuration data will be completely lost once the container restarts or is destroyed.)
: '''安全加固 `127.0.0.1`： / Security Hardening `127.0.0.1`:''' 绑定本地环回地址 `127.0.0.1`，杜绝被批量扫描及 0day 漏洞攻击的潜在威胁。 (Binding to the local loopback address `127.0.0.1` eliminates the potential threat of being bulk-scanned and attacked by 0-day vulnerabilities.)

=== 3. 启动服务 / Start the Service ===
<syntaxhighlight lang="bash">
docker compose up -d
</syntaxhighlight>
启动后，执行 `docker logs komari` 查看系统自动生成的初始管理员账号和密码。
After starting, execute `docker logs komari` to view the initial admin account and password automatically generated by the system.

== 第二步：进阶配置 - Caddy 详尽反代与 HTTPS / Step 2: Advanced Configuration - Detailed Caddy Reverse Proxy & HTTPS ==

在前端，我们将使用 Caddy 申请免费证书并进行反向代理，将安全的 HTTPS 流量转发给内网的 Komari。
On the frontend, we will use Caddy to request a free certificate and set up a reverse proxy to forward secure HTTPS traffic to the internal Komari service.

=== 1. 编辑 Caddyfile / Edit the Caddyfile ===
打开你的 Caddy 配置文件（通常位于 `/etc/caddy/Caddyfile`）：
Open your Caddy config file (usually located at `/etc/caddy/Caddyfile`):
<syntaxhighlight lang="bash">
nano /etc/caddy/Caddyfile
</syntaxhighlight>

写入以下配置（请将 `status.yourdomain.com` 替换为你的真实域名）：
Write the following configuration (please replace `status.yourdomain.com` with your real domain name):
<syntaxhighlight lang="text">
status.yourdomain.com {
# 启用现代 TLS 协议 / Enable modern TLS protocols
tls {
protocols tls1.2 tls1.3
}

# 反向代理至本地环回地址的 Komari 端口 / Reverse proxy to the Komari port on the local loopback address
reverse_proxy localhost:25774 {
# 传递真实访客 IP 和协议 / Pass real visitor IP and protocol
header_up Host {host}
header_up X-Real-IP {remote}
header_up X-Forwarded-For {remote}
header_up X-Forwarded-Proto {scheme}
}

# 启用压缩机制以加快探针面板加载速度 / Enable compression to speed up dashboard loading
encode gzip zstd

# 现代且严谨的安全响应头设置 / Modern and rigorous security response headers setup
header {
# 注意：此处未加 preload，只有在你准备将域名提交到浏览器 HSTS preload list 时才建议加入 preload 参数
# Note: 'preload' is omitted here; it is only recommended if you plan to submit the domain to the browser HSTS preload list
Strict-Transport-Security "max-age=31536000; includeSubDomains"
X-Content-Type-Options "nosniff"
X-Frame-Options "SAMEORIGIN"
Referrer-Policy "strict-origin-when-cross-origin"
}

# 详尽的访问日志记录，为未来排错提供明确的数据分析支持 / Detailed access logging to provide clear data support for future debugging
log {
output file /var/log/caddy/komari_access.log {
roll_size 100mb
roll_keep 5
}
format json
}
}
</syntaxhighlight>

; 🔍 Debug 与排错逻辑 / Debugging & Troubleshooting Logic
: '''WebSocket 断连与 Cloudflare 避坑： / WebSocket Disconnection & Cloudflare Pitfalls:''' Komari 极其依赖 WebSocket 进行实时数据推送（Caddy v2 默认原生支持 WebSocket 转发）。如果你发现面板卡死不刷新，请首先检查链路。如果你在前端套用了 Cloudflare，请务必检查：1. 网络设置中的 "WebSockets" 选项是否开启；2. SSL/TLS 加密模式必须设置为 "Full" 或 "Full (Strict)"，否则会导致循环重定向或握手失败。 (Komari heavily relies on WebSocket for real-time data push. If the panel freezes, check the link first. If using Cloudflare, ensure: 1. "WebSockets" is enabled in Network settings; 2. SSL/TLS mode is set to "Full" or "Full (Strict)" to prevent redirect loops or handshake failures.)
: '''日志分析排错： / Log Analysis Troubleshooting:''' 这里专门配置了 `/var/log/caddy/komari_access.log`。如果配置完出现 502 错误，切忌盲目瞎猜，直接使用 `tail -f /var/log/caddy/komari_access.log` 追踪日志，通过分析 HTTP 状态码和 Upstream 报错来精准定位问题。 (We specifically configured `/var/log/caddy/komari_access.log`. If a 502 error occurs, do not guess blindly; directly use `tail -f` to track the log and pinpoint the issue by analyzing HTTP status codes and Upstream errors.)

=== 2. 重载 Caddy 生效 / Reload Caddy to Apply ===
<syntaxhighlight lang="bash">
caddy reload --config /etc/caddy/Caddyfile
</syntaxhighlight>

== 第三步：多节点 Agent 接入实战 / Step 3: Multi-Node Agent Integration Practice ==

主控端稳如泰山后，现在我们可以把其他 VPS 统一接入面板进行管理了。
With the controller stable as a mountain, we can now integrate your other VPS nodes into the dashboard for unified management.

=== 1. 主控端获取连接参数 / Get Connection Parameters from Controller ===
登录你的 Komari 面板后台，点击“添加节点”。系统会为你生成一串专属的 Agent 连接命令，其中包含了你的 '''API 地址''' 和对应节点的 '''Secret Key'''。
Log into your Komari dashboard backend and click "Add Node". The system will generate a dedicated Agent connection command containing your '''API Address''' and the corresponding node's '''Secret Key'''.

=== 2. 在被控节点安装 Agent / Install Agent on the Managed Node ===
通过 SSH 登录到你需要监控的服务器，为了保持系统整洁，我们依然推荐使用 Docker 运行 Agent：
Log into the server you want to monitor via SSH. To keep the system clean, we still recommend running the Agent using Docker:

<syntaxhighlight lang="bash">
docker run -d \
--name komari-agent \
--restart unless-stopped \
--net=host \
-v /proc:/host/proc:ro \
-v /sys:/host/sys:ro \
-v /:/rootfs:ro \
ghcr.io/komari-monitor/komari-agent:latest \
-api "wss://status.yourdomain.com/api/v1/ws" \
-secret "你的节点专属SecretKey"
</syntaxhighlight>

; 🔍 Debug 与分析逻辑 / Debugging & Analysis Logic
: '''参数解析 `net=host` 与目录映射： / Parameter Parsing `net=host` and Directory Mapping:''' Agent 需要真实获取宿主机的网卡流量、CPU 和内存信息，因此必须使用 `--net=host` 共享网络命名空间，并将宿主机的 `/proc` 和 `/sys` 以只读 (`ro`) 模式映射进容器。 (The Agent needs to fetch real host network traffic, CPU, and memory info, so it must use `--net=host` to share the network namespace and map the host's `/proc` and `/sys` into the container in read-only (`ro`) mode.)
: '''协议检查： / Protocol Check:''' 确保 `-api` 参数使用的是 `wss://`（WebSocket Secure），因为我们的主控端已经配置了严格的 HTTPS。如果填成 `ws://` 将会被 Caddy 拒绝连接。 (Ensure the `-api` parameter uses `wss://` (WebSocket Secure) since our controller is configured with strict HTTPS. If filled as `ws://`, the connection will be rejected by Caddy.)

大功告成！现在，你可以坐在屏幕前，看着所有服务器的绿色心跳线，享受数据掌控在自己手中的极致快感了。
Mission accomplished! Now, you can sit in front of the screen, watch the green heartbeat lines of all your servers, and enjoy the ultimate thrill of having your data under your own control.

----
''Created by AlexLynn for md5.pw Community.''
[[index.php?title=Category:500 常见应用指南 — Application Guides]]

File:Komari.png

2026-03-01T05:40:59Z

AlexLynn：

description

搬瓦工 CN2 GIA 与 Komari：轻量级 Go 语言探针呈现三网顶级网络艺术

2026-03-01T05:30:07Z

AlexLynn：

= 搬瓦工 CN2 GIA 与 Komari：轻量级 Go 语言探针呈现三网顶级网络艺术 =
= BandwagonHost CN2 GIA & Komari: A Lightweight Go Probe Presenting the Art of Top-Tier Networking =

搬瓦工（BandwagonHost）的 CN2 GIA 线路堪称 VPS 界的网络天花板。其三网顶级直连架构不仅带来了令人惊叹的极致超低延迟，更是在晚高峰也能保持全天候 '''0 丢包''' 的神话。这种丝滑、纯粹的网络体验，如果不配上一个优秀的现代监控探针将其彻底可视化，简直是暴殄天物！
BandwagonHost's CN2 GIA routing is arguably the network ceiling of the VPS world. Its top-tier direct connection across all three major networks brings not only amazingly stable and low latency but also maintains a mythical '''0 packet loss''' even during peak hours. Such a silky-smooth and pure network experience would be an absolute waste if not thoroughly visualized with an excellent modern monitoring dashboard!

为了不辜负瓦工如此顶级的线路，我们需要一款同样极致的探针。今天的主角 '''Komari''' 正是为此而生。
To live up to such top-tier routing from BandwagonHost, we need an equally ultimate probe. Today's protagonist, '''Komari''', was born for this exact purpose.

== 为什么选择 Komari？ / Why Choose Komari? ==

市面上的服务器监控面板琳琅满目，但 Komari 凭借其独特的架构脱颖而出：
The market is full of server monitoring panels, but Komari stands out with its unique architecture:

* '''基于 Go 语言构建 / Built with Go'''：Komari 的主控端和 Agent 均采用 Golang 编写。天生的高并发优势和出色的内存管理，使得它能以极低的系统资源占用，轻松处理并发连接。 Komari's controller and agent are both written in Golang. Its inherent high-concurrency advantages and excellent memory management allow it to easily handle concurrent connections with extremely low system resource consumption.
* '''优雅的 Controller + Agent 架构 / Elegant Controller + Agent Architecture'''：主控面板（Controller）负责节点管理与数据展示，轻量 Agent 负责采集系统指标，并通过 WebSocket 持久连接上报数据。这种设计避免了传统轮询式监控产生的大量请求开销，在低带宽 VPS 环境下依然能够保持高实时性与极低资源占用。 The controller dashboard is responsible for node management and data presentation, while the lightweight Agent collects system metrics and reports data via persistent WebSocket connections. This design avoids the massive request overhead generated by traditional polling-based monitoring, maintaining high real-time performance and extremely low resource usage even in low-bandwidth VPS environments.
* '''极致轻量与极简主义 / Extreme Lightweight & Minimalism'''：监控工具本身不应成为服务器的负担。Komari 没有臃肿的依赖库，对于极其珍贵的瓦工服务器资源来说，运行它几乎是“零感知”的。 Monitoring tools themselves shouldn't be a burden on the server. Komari has no bloated dependency libraries; for the extremely precious BandwagonHost server resources, running it is almost "zero-perception".

本文将通过严谨的逻辑，一步一步完成 Komari 的基础部署、高级安全反代，以及多节点 Agent 的接入。
This article will walk through the basic deployment of Komari, advanced secure reverse proxy configuration, and multi-node Agent integration, step-by-step with rigorous logic.

== 第一步：基础安装 - 部署 Komari 主控 / Step 1: Basic Installation - Deploying Komari Controller ==

无论你是在白天使用 Windows 办公，还是使用 macOS 的终端，请先通过 SSH 接入你的搬瓦工服务器。为了保证环境的隔离性和未来排错的便利性，我们采用 Docker Compose 进行部署。
Whether you are working on Windows during the day or using the macOS terminal, please SSH into your BandwagonHost server first. To ensure environmental isolation and ease of future troubleshooting, we will deploy using Docker Compose.

=== 1. 创建项目目录结构 / Create Project Directory Structure ===
<syntaxhighlight lang="bash">
mkdir -p /opt/komari && cd /opt/komari
</syntaxhighlight>

=== 2. 编写 Docker Compose 配置文件 / Write the Docker Compose Configuration ===
创建并编辑 Docker Compose 配置文件：
Create and edit the Docker Compose configuration file:
<syntaxhighlight lang="bash">
nano docker-compose.yml
</syntaxhighlight>

写入以下内容（注意端口映射的安全加固与版本控制）：
Write the following content (note the security hardening of port mapping and version control):
<syntaxhighlight lang="yaml">
version: '3.8'
services:
komari:
# 生产环境建议将 latest 替换为具体的 release 版本号以保证系统稳定性
# For production, it's recommended to replace 'latest' with a specific release version to ensure system stability
image: ghcr.io/komari-monitor/komari:latest
container_name: komari
restart: unless-stopped
ports:
- "127.0.0.1:25774:25774"
volumes:
- ./data:/app/data
</syntaxhighlight>

; 🔍 Debug 与安全分析逻辑 / Debugging & Security Analysis Logic
: '''为什么映射 `/app/data`？ / Why map `/app/data`?''' 探针的面板设置、节点信息都物理存储在这个目录。如果不做映射，一旦容器重启或销毁，所有配置数据将全部丢失。 (The panel settings and node information are physically stored in this directory. If not mapped, all configuration data will be completely lost once the container restarts or is destroyed.)
: '''安全加固 `127.0.0.1`： / Security Hardening `127.0.0.1`:''' 绑定本地环回地址 `127.0.0.1`，杜绝被批量扫描及 0day 漏洞攻击的潜在威胁。 (Binding to the local loopback address `127.0.0.1` eliminates the potential threat of being bulk-scanned and attacked by 0-day vulnerabilities.)

=== 3. 启动服务 / Start the Service ===
<syntaxhighlight lang="bash">
docker compose up -d
</syntaxhighlight>
启动后，执行 `docker logs komari` 查看系统自动生成的初始管理员账号和密码。
After starting, execute `docker logs komari` to view the initial admin account and password automatically generated by the system.

== 第二步：进阶配置 - Caddy 详尽反代与 HTTPS / Step 2: Advanced Configuration - Detailed Caddy Reverse Proxy & HTTPS ==

在前端，我们将使用 Caddy 申请免费证书并进行反向代理，将安全的 HTTPS 流量转发给内网的 Komari。
On the frontend, we will use Caddy to request a free certificate and set up a reverse proxy to forward secure HTTPS traffic to the internal Komari service.

=== 1. 编辑 Caddyfile / Edit the Caddyfile ===
打开你的 Caddy 配置文件（通常位于 `/etc/caddy/Caddyfile`）：
Open your Caddy config file (usually located at `/etc/caddy/Caddyfile`):
<syntaxhighlight lang="bash">
nano /etc/caddy/Caddyfile
</syntaxhighlight>

写入以下配置（请将 `status.yourdomain.com` 替换为你的真实域名）：
Write the following configuration (please replace `status.yourdomain.com` with your real domain name):
<syntaxhighlight lang="text">
status.yourdomain.com {
# 启用现代 TLS 协议 / Enable modern TLS protocols
tls {
protocols tls1.2 tls1.3
}

# 反向代理至本地环回地址的 Komari 端口 / Reverse proxy to the Komari port on the local loopback address
reverse_proxy localhost:25774 {
# 传递真实访客 IP 和协议 / Pass real visitor IP and protocol
header_up Host {host}
header_up X-Real-IP {remote}
header_up X-Forwarded-For {remote}
header_up X-Forwarded-Proto {scheme}
}

# 启用压缩机制以加快探针面板加载速度 / Enable compression to speed up dashboard loading
encode gzip zstd

# 现代且严谨的安全响应头设置 / Modern and rigorous security response headers setup
header {
# 注意：此处未加 preload，只有在你准备将域名提交到浏览器 HSTS preload list 时才建议加入 preload 参数
# Note: 'preload' is omitted here; it is only recommended if you plan to submit the domain to the browser HSTS preload list
Strict-Transport-Security "max-age=31536000; includeSubDomains"
X-Content-Type-Options "nosniff"
X-Frame-Options "SAMEORIGIN"
Referrer-Policy "strict-origin-when-cross-origin"
}

# 详尽的访问日志记录，为未来排错提供明确的数据分析支持 / Detailed access logging to provide clear data support for future debugging
log {
output file /var/log/caddy/komari_access.log {
roll_size 100mb
roll_keep 5
}
format json
}
}
</syntaxhighlight>

; 🔍 Debug 与排错逻辑 / Debugging & Troubleshooting Logic
: '''WebSocket 断连与 Cloudflare 避坑： / WebSocket Disconnection & Cloudflare Pitfalls:''' Komari 极其依赖 WebSocket 进行实时数据推送（Caddy v2 默认原生支持 WebSocket 转发）。如果你发现面板卡死不刷新，请首先检查链路。如果你在前端套用了 Cloudflare，请务必检查：1. 网络设置中的 "WebSockets" 选项是否开启；2. SSL/TLS 加密模式必须设置为 "Full" 或 "Full (Strict)"，否则会导致循环重定向或握手失败。 (Komari heavily relies on WebSocket for real-time data push. If the panel freezes, check the link first. If using Cloudflare, ensure: 1. "WebSockets" is enabled in Network settings; 2. SSL/TLS mode is set to "Full" or "Full (Strict)" to prevent redirect loops or handshake failures.)
: '''日志分析排错： / Log Analysis Troubleshooting:''' 这里专门配置了 `/var/log/caddy/komari_access.log`。如果配置完出现 502 错误，切忌盲目瞎猜，直接使用 `tail -f /var/log/caddy/komari_access.log` 追踪日志，通过分析 HTTP 状态码和 Upstream 报错来精准定位问题。 (We specifically configured `/var/log/caddy/komari_access.log`. If a 502 error occurs, do not guess blindly; directly use `tail -f` to track the log and pinpoint the issue by analyzing HTTP status codes and Upstream errors.)

=== 2. 重载 Caddy 生效 / Reload Caddy to Apply ===
<syntaxhighlight lang="bash">
caddy reload --config /etc/caddy/Caddyfile
</syntaxhighlight>

== 第三步：多节点 Agent 接入实战 / Step 3: Multi-Node Agent Integration Practice ==

主控端稳如泰山后，现在我们可以把其他 VPS 统一接入面板进行管理了。
With the controller stable as a mountain, we can now integrate your other VPS nodes into the dashboard for unified management.

=== 1. 主控端获取连接参数 / Get Connection Parameters from Controller ===
登录你的 Komari 面板后台，点击“添加节点”。系统会为你生成一串专属的 Agent 连接命令，其中包含了你的 '''API 地址''' 和对应节点的 '''Secret Key'''。
Log into your Komari dashboard backend and click "Add Node". The system will generate a dedicated Agent connection command containing your '''API Address''' and the corresponding node's '''Secret Key'''.

=== 2. 在被控节点安装 Agent / Install Agent on the Managed Node ===
通过 SSH 登录到你需要监控的服务器，为了保持系统整洁，我们依然推荐使用 Docker 运行 Agent：
Log into the server you want to monitor via SSH. To keep the system clean, we still recommend running the Agent using Docker:

<syntaxhighlight lang="bash">
docker run -d \
--name komari-agent \
--restart unless-stopped \
--net=host \
-v /proc:/host/proc:ro \
-v /sys:/host/sys:ro \
-v /:/rootfs:ro \
ghcr.io/komari-monitor/komari-agent:latest \
-api "wss://status.yourdomain.com/api/v1/ws" \
-secret "你的节点专属SecretKey"
</syntaxhighlight>

; 🔍 Debug 与分析逻辑 / Debugging & Analysis Logic
: '''参数解析 `net=host` 与目录映射： / Parameter Parsing `net=host` and Directory Mapping:''' Agent 需要真实获取宿主机的网卡流量、CPU 和内存信息，因此必须使用 `--net=host` 共享网络命名空间，并将宿主机的 `/proc` 和 `/sys` 以只读 (`ro`) 模式映射进容器。 (The Agent needs to fetch real host network traffic, CPU, and memory info, so it must use `--net=host` to share the network namespace and map the host's `/proc` and `/sys` into the container in read-only (`ro`) mode.)
: '''协议检查： / Protocol Check:''' 确保 `-api` 参数使用的是 `wss://`（WebSocket Secure），因为我们的主控端已经配置了严格的 HTTPS。如果填成 `ws://` 将会被 Caddy 拒绝连接。 (Ensure the `-api` parameter uses `wss://` (WebSocket Secure) since our controller is configured with strict HTTPS. If filled as `ws://`, the connection will be rejected by Caddy.)

大功告成！现在，你可以坐在屏幕前，看着所有服务器的绿色心跳线，享受数据掌控在自己手中的极致快感了。
Mission accomplished! Now, you can sit in front of the screen, watch the green heartbeat lines of all your servers, and enjoy the ultimate thrill of having your data under your own control.

----
''Created by AlexLynn for md5.pw Community.''
[[index.php?title=Category:500 常见应用指南 — Application Guides]]

搬瓦工 CN2 GIA 与 Komari：轻量级 Go 语言探针呈现三网顶级网络艺术

2026-03-01T05:24:03Z

AlexLynn：

= 搬瓦工 CN2 GIA 与 Komari：轻量级 Go 语言探针呈现三网顶级网络艺术 =
= BandwagonHost CN2 GIA & Komari: A Lightweight Go Probe Presenting the Art of Top-Tier Networking =

搬瓦工（BandwagonHost）的 CN2 GIA 线路堪称 VPS 界的网络天花板。其三网顶级直连架构不仅带来了令人惊叹的极致超低延迟，更是在晚高峰也能保持全天候 '''0 丢包''' 的神话。这种丝滑、纯粹的网络体验，如果不配上一个优秀的现代监控探针将其彻底可视化，简直是暴殄天物！
BandwagonHost's CN2 GIA routing is arguably the network ceiling of the VPS world. Its top-tier direct connection across all three major networks brings not only amazingly stable and low latency but also maintains a mythical '''0 packet loss''' even during peak hours. Such a silky-smooth and pure network experience would be an absolute waste if not thoroughly visualized with an excellent modern monitoring dashboard!

为了不辜负瓦工如此顶级的线路，我们需要一款同样极致的探针。今天的主角 '''Komari''' 正是为此而生。
To live up to such top-tier routing from BandwagonHost, we need an equally ultimate probe. Today's protagonist, '''Komari''', was born for this exact purpose.

== 为什么选择 Komari？ / Why Choose Komari? ==

市面上的服务器监控面板琳琅满目，但 Komari 凭借其独特的架构脱颖而出：
The market is full of server monitoring panels, but Komari stands out with its unique architecture:

* '''基于 Go 语言构建 / Built with Go'''：Komari 的主控端和 Agent 均采用 Golang 编写。天生的高并发优势和出色的内存管理，使得它能以极低的系统资源占用，轻松处理并发连接。
Komari's controller and agent are both written in Golang. Its inherent high-concurrency advantages and excellent memory management allow it to easily handle concurrent connections with extremely low system resource consumption.
* '''优雅的 Controller + Agent 架构 / Elegant Controller + Agent Architecture'''：主控面板（Controller）负责节点管理与数据展示，轻量 Agent 负责采集系统指标，并通过 WebSocket 持久连接上报数据。这种设计避免了传统轮询式监控产生的大量请求开销，在低带宽 VPS 环境下依然能够保持高实时性与极低资源占用。
The controller dashboard is responsible for node management and data presentation, while the lightweight Agent collects system metrics and reports data via persistent WebSocket connections. This design avoids the massive request overhead generated by traditional polling-based monitoring, maintaining high real-time performance and extremely low resource usage even in low-bandwidth VPS environments.
* '''极致轻量与极简主义 / Extreme Lightweight & Minimalism'''：监控工具本身不应成为服务器的负担。Komari 没有臃肿的依赖库，对于极其珍贵的瓦工服务器资源来说，运行它几乎是“零感知”的。
Monitoring tools themselves shouldn't be a burden on the server. Komari has no bloated dependency libraries; for the extremely precious BandwagonHost server resources, running it is almost "zero-perception".

本文将通过严谨的逻辑，一步一步完成 Komari 的基础部署、高级安全反代，以及多节点 Agent 的接入。
This article will walk through the basic deployment of Komari, advanced secure reverse proxy configuration, and multi-node Agent integration, step-by-step with rigorous logic.

== 第一步：基础安装 - 部署 Komari 主控 / Step 1: Basic Installation - Deploying Komari Controller ==

无论你是在白天使用 Windows 办公，还是使用 macOS 的终端，请先通过 SSH 接入你的搬瓦工服务器。为了保证环境的隔离性和未来排错的便利性，我们采用 Docker Compose 进行部署。
Whether you are working on Windows during the day or using the macOS terminal, please SSH into your BandwagonHost server first. To ensure environmental isolation and ease of future troubleshooting, we will deploy using Docker Compose.

=== 1. 创建项目目录结构 / Create Project Directory Structure ===
<syntaxhighlight lang="bash">
mkdir -p /opt/komari && cd /opt/komari
</syntaxhighlight>

=== 2. 编写 Docker Compose 配置文件 / Write the Docker Compose Configuration ===
创建并编辑 Docker Compose 配置文件：
Create and edit the Docker Compose configuration file:
<syntaxhighlight lang="bash">
nano docker-compose.yml
</syntaxhighlight>

写入以下内容（注意端口映射的安全加固与版本控制）：
Write the following content (note the security hardening of port mapping and version control):
<syntaxhighlight lang="yaml">
version: '3.8'
services:
komari:
# 生产环境建议将 latest 替换为具体的 release 版本号以保证系统稳定性
# For production, it's recommended to replace 'latest' with a specific release version to ensure system stability
image: ghcr.io/komari-monitor/komari:latest
container_name: komari
restart: unless-stopped
ports:
- "127.0.0.1:25774:25774"
volumes:
- ./data:/app/data
</syntaxhighlight>

; 🔍 Debug 与安全分析逻辑 / Debugging & Security Analysis Logic
: '''为什么映射 `/app/data`？ / Why map `/app/data`?''' 探针的面板设置、节点信息都物理存储在这个目录。如果不做映射，一旦容器重启或销毁，所有配置数据将全部丢失。 (The panel settings and node information are physically stored in this directory. If not mapped, all configuration data will be completely lost once the container restarts or is destroyed.)
: '''安全加固 `127.0.0.1`： / Security Hardening `127.0.0.1`:''' 绑定本地环回地址 `127.0.0.1`，杜绝被批量扫描及 0day 漏洞攻击的潜在威胁。 (Binding to the local loopback address `127.0.0.1` eliminates the potential threat of being bulk-scanned and attacked by 0-day vulnerabilities.)

=== 3. 启动服务 / Start the Service ===
<syntaxhighlight lang="bash">
docker compose up -d
</syntaxhighlight>
启动后，执行 `docker logs komari` 查看系统自动生成的初始管理员账号和密码。
After starting, execute `docker logs komari` to view the initial admin account and password automatically generated by the system.

== 第二步：进阶配置 - Caddy 详尽反代与 HTTPS / Step 2: Advanced Configuration - Detailed Caddy Reverse Proxy & HTTPS ==

在前端，我们将使用 Caddy 申请免费证书并进行反向代理，将安全的 HTTPS 流量转发给内网的 Komari。
On the frontend, we will use Caddy to request a free certificate and set up a reverse proxy to forward secure HTTPS traffic to the internal Komari service.

=== 1. 编辑 Caddyfile / Edit the Caddyfile ===
打开你的 Caddy 配置文件（通常位于 `/etc/caddy/Caddyfile`）：
Open your Caddy config file (usually located at `/etc/caddy/Caddyfile`):
<syntaxhighlight lang="bash">
nano /etc/caddy/Caddyfile
</syntaxhighlight>

写入以下配置（请将 `status.yourdomain.com` 替换为你的真实域名）：
Write the following configuration (please replace `status.yourdomain.com` with your real domain name):
<syntaxhighlight lang="text">
status.yourdomain.com {
# 启用现代 TLS 协议 / Enable modern TLS protocols
tls {
protocols tls1.2 tls1.3
}

# 反向代理至本地环回地址的 Komari 端口 / Reverse proxy to the Komari port on the local loopback address
reverse_proxy localhost:25774 {
# 传递真实访客 IP 和协议 / Pass real visitor IP and protocol
header_up Host {host}
header_up X-Real-IP {remote}
header_up X-Forwarded-For {remote}
header_up X-Forwarded-Proto {scheme}
}

# 启用压缩机制以加快探针面板加载速度 / Enable compression to speed up dashboard loading
encode gzip zstd

# 现代且严谨的安全响应头设置 / Modern and rigorous security response headers setup
header {
# 注意：此处未加 preload，只有在你准备将域名提交到浏览器 HSTS preload list 时才建议加入 preload 参数
# Note: 'preload' is omitted here; it is only recommended if you plan to submit the domain to the browser HSTS preload list
Strict-Transport-Security "max-age=31536000; includeSubDomains"
X-Content-Type-Options "nosniff"
X-Frame-Options "SAMEORIGIN"
Referrer-Policy "strict-origin-when-cross-origin"
}

# 详尽的访问日志记录，为未来排错提供明确的数据分析支持 / Detailed access logging to provide clear data support for future debugging
log {
output file /var/log/caddy/komari_access.log {
roll_size 100mb
roll_keep 5
}
format json
}
}
</syntaxhighlight>

; 🔍 Debug 与排错逻辑 / Debugging & Troubleshooting Logic
: '''WebSocket 断连与 Cloudflare 避坑： / WebSocket Disconnection & Cloudflare Pitfalls:''' Komari 极其依赖 WebSocket 进行实时数据推送（Caddy v2 默认原生支持 WebSocket 转发）。如果你发现面板卡死不刷新，请首先检查链路。如果你在前端套用了 Cloudflare，请务必检查：1. 网络设置中的 "WebSockets" 选项是否开启；2. SSL/TLS 加密模式必须设置为 "Full" 或 "Full (Strict)"，否则会导致循环重定向或握手失败。 (Komari heavily relies on WebSocket for real-time data push. If the panel freezes, check the link first. If using Cloudflare, ensure: 1. "WebSockets" is enabled in Network settings; 2. SSL/TLS mode is set to "Full" or "Full (Strict)" to prevent redirect loops or handshake failures.)
: '''日志分析排错： / Log Analysis Troubleshooting:''' 这里专门配置了 `/var/log/caddy/komari_access.log`。如果配置完出现 502 错误，切忌盲目瞎猜，直接使用 `tail -f /var/log/caddy/komari_access.log` 追踪日志，通过分析 HTTP 状态码和 Upstream 报错来精准定位问题。 (We specifically configured `/var/log/caddy/komari_access.log`. If a 502 error occurs, do not guess blindly; directly use `tail -f` to track the log and pinpoint the issue by analyzing HTTP status codes and Upstream errors.)

=== 2. 重载 Caddy 生效 / Reload Caddy to Apply ===
<syntaxhighlight lang="bash">
caddy reload --config /etc/caddy/Caddyfile
</syntaxhighlight>

== 第三步：多节点 Agent 接入实战 / Step 3: Multi-Node Agent Integration Practice ==

主控端稳如泰山后，现在我们可以把其他 VPS 统一接入面板进行管理了。
With the controller stable as a mountain, we can now integrate your other VPS nodes into the dashboard for unified management.

=== 1. 主控端获取连接参数 / Get Connection Parameters from Controller ===
登录你的 Komari 面板后台，点击“添加节点”。系统会为你生成一串专属的 Agent 连接命令，其中包含了你的 '''API 地址''' 和对应节点的 '''Secret Key'''。
Log into your Komari dashboard backend and click "Add Node". The system will generate a dedicated Agent connection command containing your '''API Address''' and the corresponding node's '''Secret Key'''.

=== 2. 在被控节点安装 Agent / Install Agent on the Managed Node ===
通过 SSH 登录到你需要监控的服务器，为了保持系统整洁，我们依然推荐使用 Docker 运行 Agent：
Log into the server you want to monitor via SSH . To keep the system clean, we still recommend running the Agent using Docker:

<syntaxhighlight lang="bash">
docker run -d \
--name komari-agent \
--restart unless-stopped \
--net=host \
-v /proc:/host/proc:ro \
-v /sys:/host/sys:ro \
-v /:/rootfs:ro \
ghcr.io/komari-monitor/komari-agent:latest \
-api "wss://status.yourdomain.com/api/v1/ws" \
-secret "你的节点专属SecretKey"
</syntaxhighlight>

; 🔍 Debug 与分析逻辑 / Debugging & Analysis Logic
: '''参数解析 `net=host` 与目录映射： / Parameter Parsing `net=host` and Directory Mapping:''' Agent 需要真实获取宿主机的网卡流量、CPU 和内存信息，因此必须使用 `--net=host` 共享网络命名空间，并将宿主机的 `/proc` 和 `/sys` 以只读 (`ro`) 模式映射进容器。 (The Agent needs to fetch real host network traffic, CPU, and memory info, so it must use `--net=host` to share the network namespace and map the host's `/proc` and `/sys` into the container in read-only (`ro`) mode.)
: '''协议检查： / Protocol Check:''' 确保 `-api` 参数使用的是 `wss://`（WebSocket Secure），因为我们的主控端已经配置了严格的 HTTPS。如果填成 `ws://` 将会被 Caddy 拒绝连接。 (Ensure the `-api` parameter uses `wss://` (WebSocket Secure) since our controller is configured with strict HTTPS. If filled as `ws://`, the connection will be rejected by Caddy.)

大功告成！现在，你可以坐在屏幕前，看着所有服务器的绿色心跳线，享受数据掌控在自己手中的极致快感了。
Mission accomplished! Now, you can sit in front of the screen, watch the green heartbeat lines of all your servers, and enjoy the ultimate thrill of having your data under your own control.

----
''Created by AlexLynn for md5.pw Community.''
[[Category:500 常见应用指南 — Application Guides]]

搬瓦工 CN2 GIA 与 Komari：轻量级 Go 语言探针呈现三网顶级网络艺术

2026-03-01T05:08:14Z

AlexLynn：创建页面，内容为“= 搬瓦工 CN2 GIA 与 Komari：轻量级 Go 语言探针呈现三网顶级网络艺术 = 搬瓦工（BandwagonHost）的 CN2 GIA 线路堪称 VPS 界的网络天花板。其三网顶级直连架构不仅带来了令人惊叹的极致超低延迟，更是在晚高峰也能保持全天候 '''0 丢包''' 的神话。这种丝滑、纯粹的网络体验，如果不配上一个优秀的现代监控探针将其彻底可视化，简直是暴殄天物！为了不…”

= 搬瓦工 CN2 GIA 与 Komari：轻量级 Go 语言探针呈现三网顶级网络艺术 =

搬瓦工（BandwagonHost）的 CN2 GIA 线路堪称 VPS 界的网络天花板。其三网顶级直连架构不仅带来了令人惊叹的极致超低延迟，更是在晚高峰也能保持全天候 '''0 丢包''' 的神话。这种丝滑、纯粹的网络体验，如果不配上一个优秀的现代监控探针将其彻底可视化，简直是暴殄天物！

为了不辜负瓦工如此顶级的线路，我们需要一款同样极致的探针。今天的主角 '''Komari''' 正是为此而生。

== 为什么选择 Komari？ ==

市面上的服务器监控面板琳琅满目，但 Komari 凭借其独特的架构脱颖而出：

* '''基于 Go 语言构建'''：Komari 的主控端和 Agent 均采用 Golang 编写。天生的高并发优势和出色的内存管理，使得它能以极低的系统资源占用，轻松处理并发连接。
* '''极致轻量与极简主义'''：监控工具本身不应成为服务器的负担。Komari 没有臃肿的依赖库，对于极其珍贵的瓦工服务器资源来说，运行它几乎是“零感知”的。
* '''优雅的数据流转'''：采用 WebSocket 进行实时数据推送，延迟极低。你在面板上看到的每一次心跳闪烁，都精准地反映了搬瓦工 CN2 GIA 线路坚如磐石的网络质量。

本文将通过严谨的逻辑，一步一步完成 Komari 的基础部署，并进阶使用 Caddy 配置包含完整安全规范的 HTTPS 反向代理。

== 第一步：基础安装 - 部署 Komari 主控 ==

无论你是在白天使用 Windows 办公，还是使用 macOS 的终端，请先通过 SSH 接入你的搬瓦工服务器。为了保证环境的隔离性和未来排错的便利性，我们采用 Docker Compose 进行部署。

=== 1. 创建项目目录结构 ===
<syntaxhighlight lang="bash">
mkdir -p /opt/komari && cd /opt/komari
</syntaxhighlight>

=== 2. 编写 docker-compose.yml ===
创建并编辑配置文件：
<syntaxhighlight lang="bash">
nano docker-compose.yml
</syntaxhighlight>

写入以下内容：
<syntaxhighlight lang="yaml">
version: '3.8'
services:
komari:
image: ghcr.io/komari-monitor/komari:latest
container_name: komari
restart: unless-stopped
ports:
- "25774:25774"
volumes:
- ./data:/app/data
</syntaxhighlight>

; 🔍 Debug 与分析逻辑
: '''为什么映射 `/app/data`？''' 探针的面板设置、节点信息都存储在这个目录。如果不做物理映射，一旦容器重启或销毁，所有数据将全部丢失。
: '''关于端口 25774：''' 这是 Komari 的默认监听端口。如果启动后无法通过 IP 访问，排错的第一步不要瞎猜服务是否崩溃，而是严格检查服务器的 `ufw` 或 `iptables` 防火墙是否放行了 TCP 25774 端口。

=== 3. 启动服务 ===
<syntaxhighlight lang="bash">
docker compose up -d
</syntaxhighlight>
启动后，通过执行 `docker logs komari` 可以查看系统自动生成的初始管理员账号和密码。

== 第二步：进阶配置 - Caddy 详尽反代与 HTTPS ==

将面板直接暴露在 HTTP 端口是不安全的。我们将使用 Caddy 申请免费证书并进行反向代理。以下是一份'''完整且详尽'''的配置，而非精简的凑合版本。

=== 1. 编辑 Caddyfile ===
打开你的 Caddy 配置文件（通常位于 `/etc/caddy/Caddyfile`）：
<syntaxhighlight lang="bash">
nano /etc/caddy/Caddyfile
</syntaxhighlight>

写入以下配置（请将 `status.yourdomain.com` 替换为你的真实域名）：
<syntaxhighlight lang="text">
status.yourdomain.com {
# 启用现代 TLS 协议
tls {
protocols tls1.2 tls1.3
}

# 反向代理至本地的 Komari 端口
reverse_proxy localhost:25774 {
# 传递真实访客 IP 和协议，避免后端获取到的全为本地 IP 127.0.0.1
header_up Host {host}
header_up X-Real-IP {remote}
header_up X-Forwarded-For {remote}
header_up X-Forwarded-Proto {scheme}
}

# 启用压缩机制以加快探针面板加载速度
encode gzip zstd

# 完整的安全响应头设置
header {
Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
X-Content-Type-Options "nosniff"
X-Frame-Options "SAMEORIGIN"
X-XSS-Protection "1; mode=block"
}

# 详尽的访问日志记录，为未来排错提供明确的数据分析支持
log {
output file /var/log/caddy/komari_access.log {
roll_size 100mb
roll_keep 5
}
format json
}
}
</syntaxhighlight>

; 🔍 Debug 与分析逻辑
: '''Websocket 断连排错：''' Komari 极其依赖 Websocket 进行实时数据推送（注意：Caddy v2 默认原生支持 WebSocket 转发，无需手动配置 Upgrade 头）。如果你发现面板卡死不刷新，请首先检查链路。如果在外部套了 CDN（如 Cloudflare），排错的下一步是检查 CDN 控制台的 WebSocket 转发选项是否处于开启状态。
: '''日志分析排错：''' 这里专门配置了 `/var/log/caddy/komari_access.log`。如果配置完出现 502 错误，切忌盲目重启，直接使用 `tail -f /var/log/caddy/komari_access.log` 追踪日志。你能清晰地分析出是 Let's Encrypt 证书申请达到速率限制，还是后端的 `localhost:25774` 拒绝了连接请求。

=== 2. 重载 Caddy 生效 ===
<syntaxhighlight lang="bash">
caddy reload --config /etc/caddy/Caddyfile
</syntaxhighlight>

至此，一个架构完整、包含完善日志与安全头配置的 Komari 监控面板就搭建完成了。登录面板，看着各项指标的平稳绿线，细细品味搬瓦工带给你的极致网络享受吧。

----
''Created by AlexLynn for md5.pw Community.''
[[index.php?title=Category:500 常见应用指南 — Application Guides]]

数据主权：在搬瓦工 VPS 上部署 Vaultwarden (Bitwarden) 密码管理器

2026-01-23T06:16:46Z

AlexLynn：创建页面，内容为“= 数据主权：在搬瓦工 VPS 上部署 Vaultwarden (Bitwarden) 密码管理器 = 在数据泄露事件频发的今天，将密码托管在第三方服务器（如 LastPass）始终存在隐患。'''Vaultwarden''' 是大名鼎鼎的开源密码管理器 Bitwarden 的轻量化服务端（基于 Rust 编写），它完美兼容 Bitwarden 的所有官方客户端（iOS/Android/浏览器插件），但资源占用极低，非常适合在搬瓦工（BandwagonHo…”

= 数据主权：在搬瓦工 VPS 上部署 Vaultwarden (Bitwarden) 密码管理器 =

在数据泄露事件频发的今天，将密码托管在第三方服务器（如 LastPass）始终存在隐患。'''Vaultwarden''' 是大名鼎鼎的开源密码管理器 Bitwarden 的轻量化服务端（基于 Rust 编写），它完美兼容 Bitwarden 的所有官方客户端（iOS/Android/浏览器插件），但资源占用极低，非常适合在搬瓦工（BandwagonHost）VPS 上运行。

本文将指导你使用 Docker 搭建一套属于自己的、端到端加密的密码管理系统。

== 为什么选择在搬瓦工自建？ ==

* '''数据掌控'''：你的密码数据库加密存储在你自己的 VPS 磁盘上，不再受制于人。
* '''极致粘性'''：搬瓦工提供的高 SLA 保证和自动快照（Snapshot）功能，为密码库的持久化存储提供了双重保险。
* '''完全免费'''：解锁 Bitwarden 官方的高级会员功能（如 TOTP 二步验证、附件存储等）。

== 准备工作 ==

* 一台搬瓦工 VPS（任何套餐均可，内存 512MB 以上即可）。
* 一个域名（解析到 VPS 的 IP）。
* 已安装 Docker 和 Docker Compose。

== 第一步：部署环境配置 ==

为了简化 HTTPS 证书的申请过程，我们将使用 '''Caddy''' 作为 Web 服务器（它会自动申请并续期 SSL 证书），配合 Vaultwarden 运行。

=== 1. 创建工作目录 ===
<syntaxhighlight lang="bash">
mkdir -p /opt/vaultwarden
cd /opt/vaultwarden
</syntaxhighlight>

=== 2. 创建 docker-compose.yml ===
<syntaxhighlight lang="bash">
nano docker-compose.yml
</syntaxhighlight>

写入以下内容（'''请修改域名和 ADMIN_TOKEN'''）：

<syntaxhighlight lang="yaml">
version: '3'

services:
vaultwarden:
image: vaultwarden/server:latest
container_name: vaultwarden
restart: always
environment:
# 开启管理后台，请生成一个复杂的随机字符串作为 Token
# 可以在终端使用 `openssl rand -base64 48` 生成
- ADMIN_TOKEN=请替换为你的随机长字符串
# 允许注册 (建议搭建完成后改为 false 以关闭注册)
- SIGNUPS_ALLOWED=true
volumes:
- ./vw-data:/data

caddy:
image: caddy:2
container_name: caddy
restart: always
ports:
- "80:80"
- "443:443"
volumes:
- ./Caddyfile:/etc/caddy/Caddyfile
- ./caddy-data:/data
- ./caddy-config:/config
depends_on:
- vaultwarden
</syntaxhighlight>

=== 3. 配置 Caddy 自动 HTTPS ===
创建 Caddy 配置文件：
<syntaxhighlight lang="bash">
nano Caddyfile
</syntaxhighlight>

写入以下内容（将 `your-domain.com` 替换为你的真实域名）：

<syntaxhighlight lang="text">
your-domain.com {
# 反向代理到 vaultwarden 容器的 80 端口
reverse_proxy vaultwarden:80
}
</syntaxhighlight>

== 第二步：启动服务 ==

在 `/opt/vaultwarden` 目录下执行：

<syntaxhighlight lang="bash">
docker compose up -d
</syntaxhighlight>

稍等片刻，Caddy 会自动向 Let's Encrypt 申请 SSL 证书。打开浏览器访问你的域名 `https://your-domain.com`，如果看到蓝色的 Bitwarden 登录界面，说明部署成功！

== 第三步：初始设置与安全加固 ==

=== 1. 注册账号 ===
点击“创建账号”，注册你的主账号。

=== 2. 关闭新用户注册（重要！） ===
为了防止陌生人恶意注册占用你的资源，建议注册完自己账号后，立即关闭注册功能。

修改 `docker-compose.yml`：
<syntaxhighlight lang="yaml">
- SIGNUPS_ALLOWED=false
</syntaxhighlight>

然后重启容器生效：
<syntaxhighlight lang="bash">
docker compose up -d
</syntaxhighlight>

== 第四步：数据备份（核心） ==

密码库是核心资产，'''备份重于泰山'''。得益于搬瓦工的 KiwiVM 面板，我们可以轻松保护数据。

; 方案 A：KiwiVM 自动快照 (推荐)
: 进入搬瓦工 KiwiVM 后台 -> '''Snapshots''' -> 将 '''Automatic snapshots''' 设置为 "Sticky"（永久保留最新的 2 个快照）。这样即使你误删了文件，也能一键回滚。

; 方案 B：手动导出
: 登录你的 Vaultwarden 网页版后台，定期在“工具” -> “导出密码库”中下载 JSON/CSV 备份。

== 客户端连接方法 ==

* 下载 Bitwarden 官方手机 App 或浏览器插件。
* 点击登录界面的 '''小齿轮图标'''（设置）。
* 在 '''自托管环境 (Self-hosted environment)''' -> '''服务器 URL''' 中填入你的域名（例如 `https://your-domain.com`）。
* 保存后即可正常登录使用。

== 常见问题 (FAQ) ==

; Q: 为什么必须用 HTTPS？
: A: Bitwarden 的加密算法依赖于 Web Crypto API，现代浏览器强制要求该 API 必须在 HTTPS 环境下才能运行。如果不用 HTTPS，你将无法注册或登录。

; Q: 内存占用大吗？
: A: 极小。Vaultwarden 基于 Rust 编写，空闲时内存占用通常仅需 20MB-50MB，即便是搬瓦工最入门的套餐也能流畅运行。

----
''Created by AlexLynn for md5.pw Community.''
[[Category:500 常见应用指南 — Application Guides]]
[[Category:300 VPS 设置与管理 — VPS Setup and Management]]

极速安全：在搬瓦工 VPS 上部署 WireGuard (WG) 详细指南

2026-01-23T05:53:05Z

AlexLynn：创建页面，内容为“= 极速安全：在搬瓦工 VPS 上部署 WireGuard (WG) 详细指南 = '''WireGuard''' 是被整合进 Linux 内核的新一代 VPN 协议，以其极简的代码库、极高的性能和先进的加密技术著称。相比传统的 OpenVPN 或 IPsec，WireGuard 在搬瓦工（BandwagonHost）VPS 上能提供更低的延迟和更高的吞吐量，非常适合作为个人的安全加密通道。本文将手把手教你如何在 Ubuntu/Debian 系统上手动…”

= 极速安全：在搬瓦工 VPS 上部署 WireGuard (WG) 详细指南 =

'''WireGuard''' 是被整合进 Linux 内核的新一代 VPN 协议，以其极简的代码库、极高的性能和先进的加密技术著称。相比传统的 OpenVPN 或 IPsec，WireGuard 在搬瓦工（BandwagonHost）VPS 上能提供更低的延迟和更高的吞吐量，非常适合作为个人的安全加密通道。

本文将手把手教你如何在 Ubuntu/Debian 系统上手动部署 WireGuard 服务端，并配置客户端连接。

== 准备工作 ==

* 一台搬瓦工 VPS（推荐使用 '''Ubuntu 20.04/22.04''' 或 '''Debian 10/11''' 系统）。
* 确保已通过 SSH 连接到服务器 root 用户。

== 第一步：安装 WireGuard ==

得益于搬瓦工提供的 KVM 架构和较新的内核，安装 WireGuard 非常简单。

在终端执行以下命令更新软件源并安装：

<syntaxhighlight lang="bash">
apt update && apt install -y wireguard qrencode
</syntaxhighlight>
* ''注意：这里顺便安装了 <code>qrencode</code>，后面用于生成手机扫描的二维码。''

== 第二步：生成密钥对 ==

WireGuard 使用类似 SSH 的公钥/私钥体系。我们需要分别为“服务端”和“客户端”生成密钥。

=== 1. 生成服务端密钥 ===
<syntaxhighlight lang="bash">
cd /etc/wireguard
umask 077
wg genkey | tee server_private.key | wg pubkey > server_public.key
</syntaxhighlight>

=== 2. 生成客户端密钥 ===
<syntaxhighlight lang="bash">
wg genkey | tee client_private.key | wg pubkey > client_public.key
</syntaxhighlight>

现在目录下应该有4个文件。你可以用 <code>cat</code> 命令查看并记录它们的内容（'''千万不要泄露私钥 Private Key'''）。

== 第三步：配置服务端 ==

创建并编辑 WireGuard 的主配置文件 <code>wg0.conf</code>：

<syntaxhighlight lang="bash">
nano /etc/wireguard/wg0.conf
</syntaxhighlight>

将以下内容粘贴进去（'''注意替换密钥部分'''）：

<syntaxhighlight lang="ini">
[Interface]
# 服务端私钥 (server_private.key 的内容)
PrivateKey = <这里填入你的 server_private.key>
# 服务端内网 IP，一般保持默认
Address = 10.0.0.1/24
# 监听端口 (UDP)，如果被防火墙拦截可尝试修改
ListenPort = 51820
# 启动后执行的路由规则 (开启 NAT 转发)
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o eth0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
# 关闭后清除路由规则
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o eth0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
# 客户端公钥 (client_public.key 的内容)
PublicKey = <这里填入你的 client_public.key>
# 允许该客户端使用的内网 IP
AllowedIPs = 10.0.0.2/32
</syntaxhighlight>

* '''注意'''：如果你的网卡名称不是 <code>eth0</code>（可以用 <code>ip a</code> 查看），请将 PostUp/PostDown 中的 <code>eth0</code> 替换为实际网卡名称（如 <code>ens3</code>）。

== 第四步：开启 IP 转发 ==

为了让 VPS 能转发流量，必须开启内核 IP 转发功能。

<syntaxhighlight lang="bash">
echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
sysctl -p
</syntaxhighlight>

== 第五步：启动服务 ==

启动 WireGuard 并设置开机自启：

<syntaxhighlight lang="bash">
wg-quick up wg0
systemctl enable wg-quick@wg0
</syntaxhighlight>

如果没有任何报错，输入 <code>wg</code> 命令应该能看到接口状态。

== 第六步：配置客户端 ==

=== 选项 A：手机端 (iOS/Android) ===
这是最酷的一步！我们可以直接在终端生成配置并转为二维码。

1. 创建客户端配置文件模板 <code>client.conf</code>：
<syntaxhighlight lang="bash">
nano /etc/wireguard/client.conf
</syntaxhighlight>

2. 填入以下内容：
<syntaxhighlight lang="ini">
[Interface]
# 客户端私钥 (client_private.key 的内容)
PrivateKey = <这里填入你的 client_private.key>
Address = 10.0.0.2/24
DNS = 8.8.8.8

[Peer]
# 服务端公钥 (server_public.key 的内容)
PublicKey = <这里填入你的 server_public.key>
# 服务端公网 IP : 端口
Endpoint = <你的VPS公网IP>:51820
# 路由流量：0.0.0.0/0 代表代理所有流量
AllowedIPs = 0.0.0.0/0
# 保持连接心跳，防止 NAT 断连
PersistentKeepalive = 25
</syntaxhighlight>

3. 生成二维码：
<syntaxhighlight lang="bash">
qrencode -t ansiutf8 < client.conf
</syntaxhighlight>

此时你的 SSH 终端里会直接显示一个巨大的二维码，打开手机 WireGuard APP 扫描即可连接！

=== 选项 B：电脑端 (Windows/macOS) ===
将上面的 <code>client.conf</code> 内容复制，保存为 <code>wg0.conf</code>，导入电脑版 WireGuard 客户端即可。

== 常见问题排查 ==

; Q: 连上了但无法上网？
: A: 检查 '''第四步''' 是否开启了 IP 转发。另外检查 VPS 的防火墙（UFW/IPTables）是否放行了 51820 UDP 端口。
: <syntaxhighlight lang="bash">ufw allow 51820/udp</syntaxhighlight>

; Q: 搬瓦工某些机房连不上？
: A: WireGuard 使用 UDP 协议，极少数地区的运营商可能会对大流量 UDP 进行 QOS 限速或阻断。如果遇到这种情况，可以尝试更换 ListenPort 端口，或者配合 udp2raw 使用（进阶玩法）。

----
''Created by AlexLynn for md5.pw Community.''
[[Category:500 常见应用指南 — Application Guides]]
[[Category:300 VPS 设置与管理 — VPS Setup and Management]]

搬瓦工VPS性能优化：原生BBR开启指南

2026-01-23T05:49:19Z

AlexLynn：

= 搬瓦工 VPS 性能飞跃：原生 BBR 拥塞控制开启与 TCP 协议栈优化指南 =

很多用户在购买了搬瓦工（BandwagonHost）的高速线路（如 CN2 GIA 或 CMIN2）后，在晚高峰期间偶尔仍会感觉网络吞吐量波动。这通常不是线路问题，而是 Linux 默认的 TCP 拥塞控制算法（Cubic 或 Reno）在高丢包或高延迟环境下表现保守导致的。

本文将指导你如何在不使用任何第三方“一键脚本”的情况下，安全地通过 Linux 原生命令开启 '''BBR (Bottleneck Bandwidth and Round-trip propagation time)'''，并进行 TCP 协议栈的微调，以榨干服务器的每一滴网络性能。

<blockquote>'''警告'''：虽然本文操作均为系统原生命令，但在修改内核参数前，建议在 KiwiVM 后台对 VPS 进行'''快照备份（Snapshot）'''，以防万一。</blockquote>

== 什么是 BBR？为什么它能加速？ ==

传统的 TCP 拥塞控制算法（如 Cubic）是基于“丢包”来判断网络拥堵的。一旦发现丢包，它就会剧烈降低发送速度。而在跨国网络环境中，丢包是常态，这导致带宽往往跑不满。

Google 开发的 '''BBR''' 算法则是基于“带宽”和“延迟”来建模。它不把丢包当作拥塞信号，而是尽可能探测物理链路的最大带宽。简单来说：'''BBR 就像给你的数据包装上了智能导航，能在拥堵的网络公路上更激进地抢占车道。'''

== 第一步：检查 Linux 内核版本 ==

BBR 需要 Linux Kernel '''4.9''' 以上版本支持。搬瓦工目前的系统镜像（CentOS 7/8, Ubuntu 20.04/22.04, Debian 10/11）默认内核均已支持，通常无需更换内核。

在终端输入以下命令查看内核版本：

<syntaxhighlight lang="bash">
uname -r
</syntaxhighlight>

* 如果输出类似 <code>4.18.0-xxx</code>、<code>5.4.0-xxx</code> 或更高，说明内核符合要求。
* 如果输出是 <code>3.10.x</code>（主要是老旧的 CentOS 7），建议先重装系统至 Debian 11 或 Ubuntu 22.04（推荐）。

== 第二步：开启 BBR (无需安装任何脚本) ==

我们拒绝使用来路不明的“暴力魔改 BBR 脚本”，因为它们可能会破坏系统库文件或植入后门。Linux 原生开启 BBR 只需要修改 <code>/etc/sysctl.conf</code>。

=== 1. 开启 IP 转发和 BBR ===

复制以下完整命令块并在终端执行：

<syntaxhighlight lang="bash">
# 开启 IP 转发
echo "net.ipv4.ip_forward = 1" | sudo tee -a /etc/sysctl.conf

# 设置队列算法为 fq (Fair Queuing)
echo "net.core.default_qdisc = fq" | sudo tee -a /etc/sysctl.conf

# 设置拥塞控制算法为 bbr
echo "net.ipv4.tcp_congestion_control = bbr" | sudo tee -a /etc/sysctl.conf
</syntaxhighlight>

=== 2. 使配置生效 ===

执行以下命令让刚才的修改立即生效：

<syntaxhighlight lang="bash">
sudo sysctl -p
</syntaxhighlight>

=== 3. 验证是否开启成功 ===

执行以下命令检查：

<syntaxhighlight lang="bash">
lsmod | grep bbr
</syntaxhighlight>

如果输出中包含 <code>tcp_bbr</code>（如下图所示），说明 BBR 模块已成功加载并运行。

<pre>
tcp_bbr 20480 14
</pre>

== 第三步：进阶 TCP 协议栈优化 (可选) ==

开启 BBR 已经能解决 90% 的问题。如果你想进一步优化高并发场景下的表现（例如建站），可以添加以下参数。

编辑配置文件：
<syntaxhighlight lang="bash">
nano /etc/sysctl.conf
</syntaxhighlight>

在文件末尾添加以下优化参数（请仔细阅读注释）：

<syntaxhighlight lang="ini">
# 增加 TCP 缓冲区大小，提升大文件传输速度
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

# 开启 TCP 窗口缩放 (Window Scaling)，现代网络必备
net.ipv4.tcp_window_scaling = 1

# 开启 SYN Cookies，防止 SYN Flood 攻击
net.ipv4.tcp_syncookies = 1

# 缩短 TCP 连接的保活时间 (Keepalive)，默认 7200 秒太长了
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_keepalive_intvl = 15
net.ipv4.tcp_keepalive_probes = 5

# 允许更多的半连接，应对突发流量
net.ipv4.tcp_max_syn_backlog = 8192
</syntaxhighlight>

保存并退出 (<code>Ctrl+O</code>, <code>Enter</code>, <code>Ctrl+X</code>)，然后再次执行 <code>sysctl -p</code> 使其生效。

== 常见问题 (FAQ) ==

; Q: 网上说的“BBR Plus”、“BBR 魔改版”比原版更好吗？
: A: '''不推荐在生产环境使用。''' 魔改版通常是不仅修改了算法参数（极度激进，可能导致断流），还替换了非官方编译的内核。对于搬瓦工这种本身质量就很高的线路（CN2 GIA），原生 BBR 的稳定性与速度平衡是最好的。

; Q: 我是 OpenVZ 架构的 VPS，能用吗？
: A: 不能。本文教程仅适用于 KVM 架构（搬瓦工目前在售的所有 VPS 均为 KVM）。OpenVZ 用户受限于宿主机内核，无法自行开启 BBR。

; Q: 开启后速度反而变慢了？
: A: 极少数情况下，特定地区的 ISP可能会对长时间高发包的 UDP/TCP 连接进行 QOS 限制。如果发现变慢，只需将 <code>sysctl.conf</code> 中的 <code>bbr</code> 改回 <code>cubic</code> 并执行 <code>sysctl -p</code> 即可复原。

----
''Created by AlexLynn for md5.pw Community.''
[[Category:300 VPS 设置与管理 — VPS Setup and Management]]
[[Category:500 常见应用指南 — Application Guides]]

搬瓦工VPS性能优化：原生BBR开启指南

2026-01-23T05:36:27Z

AlexLynn：创建页面，内容为“= 搬瓦工 VPS 性能飞跃：原生 BBR 拥塞控制开启与 TCP 协议栈优化指南 = 很多用户在购买了搬瓦工（BandwagonHost）的高速线路（如 CN2 GIA 或 CMIN2）后，在晚高峰期间偶尔仍会感觉网络吞吐量波动。这通常不是线路问题，而是 Linux 默认的 TCP 拥塞控制算法（Cubic 或 Reno）在高丢包或高延迟环境下表现保守导致的。本文将指导你如何在不使用任何第三方“一…”

= 搬瓦工 VPS 性能飞跃：原生 BBR 拥塞控制开启与 TCP 协议栈优化指南 =

很多用户在购买了搬瓦工（BandwagonHost）的高速线路（如 CN2 GIA 或 CMIN2）后，在晚高峰期间偶尔仍会感觉网络吞吐量波动。这通常不是线路问题，而是 Linux 默认的 TCP 拥塞控制算法（Cubic 或 Reno）在高丢包或高延迟环境下表现保守导致的。

本文将指导你如何在不使用任何第三方“一键脚本”的情况下，安全地通过 Linux 原生命令开启 '''BBR (Bottleneck Bandwidth and Round-trip propagation time)'''，并进行 TCP 协议栈的微调，以榨干服务器的每一滴网络性能。

<blockquote>'''警告'''：虽然本文操作均为系统原生命令，但在修改内核参数前，建议在 KiwiVM 后台对 VPS 进行'''快照备份（Snapshot）'''，以防万一。</blockquote>

== 什么是 BBR？为什么它能加速？ ==

传统的 TCP 拥塞控制算法（如 Cubic）是基于“丢包”来判断网络拥堵的。一旦发现丢包，它就会剧烈降低发送速度。而在跨国网络环境中，丢包是常态，这导致带宽往往跑不满。

Google 开发的 '''BBR''' 算法则是基于“带宽”和“延迟”来建模。它不把丢包当作拥塞信号，而是尽可能探测物理链路的最大带宽。简单来说：'''BBR 就像给你的数据包装上了智能导航，能在拥堵的网络公路上更激进地抢占车道。'''

== 第一步：检查 Linux 内核版本 ==

BBR 需要 Linux Kernel '''4.9''' 以上版本支持。搬瓦工目前的系统镜像（CentOS 7/8, Ubuntu 20.04/22.04, Debian 10/11）默认内核均已支持，通常无需更换内核。

在终端输入以下命令查看内核版本：

<syntaxhighlight lang="bash">
uname -r
</syntaxhighlight>

* 如果输出类似 <code>4.18.0-xxx</code>、<code>5.4.0-xxx</code> 或更高，说明内核符合要求。
* 如果输出是 <code>3.10.x</code>（主要是老旧的 CentOS 7），建议先重装系统至 Debian 11 或 Ubuntu 22.04（推荐）。

== 第二步：开启 BBR (无需安装任何脚本) ==

我们拒绝使用来路不明的“暴力魔改 BBR 脚本”，因为它们可能会破坏系统库文件或植入后门。Linux 原生开启 BBR 只需要修改 <code>/etc/sysctl.conf</code>。

=== 1. 开启 IP 转发和 BBR ===

复制以下完整命令块并在终端执行：

<syntaxhighlight lang="bash">
# 开启 IP 转发
echo "net.ipv4.ip_forward = 1" | sudo tee -a /etc/sysctl.conf

# 设置队列算法为 fq (Fair Queuing)
echo "net.core.default_qdisc = fq" | sudo tee -a /etc/sysctl.conf

# 设置拥塞控制算法为 bbr
echo "net.ipv4.tcp_congestion_control = bbr" | sudo tee -a /etc/sysctl.conf
</syntaxhighlight>

=== 2. 使配置生效 ===

执行以下命令让刚才的修改立即生效：

<syntaxhighlight lang="bash">
sudo sysctl -p
</syntaxhighlight>

=== 3. 验证是否开启成功 ===

执行以下命令检查：

<syntaxhighlight lang="bash">
lsmod | grep bbr
</syntaxhighlight>

如果输出中包含 <code>tcp_bbr</code>（如下图所示），说明 BBR 模块已成功加载并运行。

<pre>
tcp_bbr 20480 14
</pre>

== 第三步：进阶 TCP 协议栈优化 (可选) ==

开启 BBR 已经能解决 90% 的问题。如果你想进一步优化高并发场景下的表现（例如建站），可以添加以下参数。

编辑配置文件：
<syntaxhighlight lang="bash">
nano /etc/sysctl.conf
</syntaxhighlight>

在文件末尾添加以下优化参数（请仔细阅读注释）：

<syntaxhighlight lang="ini">
# 增加 TCP 缓冲区大小，提升大文件传输速度
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

# 开启 TCP 窗口缩放 (Window Scaling)，现代网络必备
net.ipv4.tcp_window_scaling = 1

# 开启 SYN Cookies，防止 SYN Flood 攻击
net.ipv4.tcp_syncookies = 1

# 缩短 TCP 连接的保活时间 (Keepalive)，默认 7200 秒太长了
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_keepalive_intvl = 15
net.ipv4.tcp_keepalive_probes = 5

# 允许更多的半连接，应对突发流量
net.ipv4.tcp_max_syn_backlog = 8192
</syntaxhighlight>

保存并退出 (<code>Ctrl+O</code>, <code>Enter</code>, <code>Ctrl+X</code>)，然后再次执行 <code>sysctl -p</code> 使其生效。

== 常见问题 (FAQ) ==

; Q: 网上说的“BBR Plus”、“BBR 魔改版”比原版更好吗？
: A: '''不推荐在生产环境使用。''' 魔改版通常是不仅修改了算法参数（极度激进，可能导致断流），还替换了非官方编译的内核。对于搬瓦工这种本身质量就很高的线路（CN2 GIA），原生 BBR 的稳定性与速度平衡是最好的。

; Q: 我是 OpenVZ 架构的 VPS，能用吗？
: A: 不能。本文教程仅适用于 KVM 架构（搬瓦工目前在售的所有 VPS 均为 KVM）。OpenVZ 用户受限于宿主机内核，无法自行开启 BBR。

; Q: 开启后速度反而变慢了？
: A: 极少数情况下，特定地区的 ISP可能会对长时间高发包的 UDP/TCP 连接进行 QOS 限制。如果发现变慢，只需将 <code>sysctl.conf</code> 中的 <code>bbr</code> 改回 <code>cubic</code> 并执行 <code>sysctl -p</code> 即可复原。

----
''Created by AlexLynn for md5.pw Community.''
[[Category:500 常见应用指南]]
[[Category:300 VPS 设置与管理]]