最近在维护自己的 Minecraft 服务器，遇到个挺真实的需求 因为服务器是放在宿舍局域网里通过 FRP 穿透出去的，平时想知道有没有朋友上线，只能登到服务器上，我又不想用别人改过的服务端 于是写了一个 Caddy 的 Layer 4 扩展插件 mc_monitor。它能在不对 MC 服务端做任何改动的前提下，在网关层直接“嗅探”出登录的玩家名称，并异步推送到 Telegram 或 Discord。 这个插件工作在 OSI 模型的第四层（传输层）。 它的核心逻辑是在 TCP 连接建立时，利用 io.TeeReader 这种“三通”技术，在不消耗原始数据流的情况下，把玩家发来的握手包（Handshake）和登录包（Login Start）复制一份出来。 通过解析这些二进制包提取出玩家 ID（Username），然后再把流量原封不动地转发给后端的 MC 服务器。最后计算玩家从连接到断开的时长，生成报告。 当然，我这里用到了之前之前大佬写的关于mc服务端相关的库 核心代码实现 这里贴一下这个 Caddy 模块的核心逻辑代码，主要是 Handle 和 parseMCLogin 方法，它们负责了主要的流量劫持和协议解析工作： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 // Handle 处理连接的核心逻辑 // 这里我们利用 io.TeeReader 在建立连接初期“偷听”流量，提取用户名 func (m *MCMonitor) Handle(cx *layer4.Connection, next layer4.Handler) error { startTime := time.Now() // 1. 创建一个 Buffer 用来暂存读取的数据 replayBuf := new(bytes.Buffer) // 2. 创建 TeeReader：从 cx 读取的数据会同时写入 replayBuf teeReader := io.TeeReader(cx, replayBuf) // 设置读取超时，防止非 MC 流量导致卡死 cx.SetReadDeadline(time.Now().Add(3 * time.Second)) // 3. 解析登录包，提取用户名 (同时数据被 TeeReader 存入 replayBuf) username, err := m.parseMCLogin(teeReader) cx.SetReadDeadline(time.Time{}) // 重置超时 // ... (日志记录逻辑) // 4. 连接真实的后端 MC 服务器 remote, err := net.Dial("tcp", m.BackendAddress) if err != nil { return err } defer remote.Close() // 5. 关键步骤：先把刚才“偷听”并存在 replayBuf 里的握手包发给后端 // 否则后端会因为缺少握手包而拒绝连接 if _, err := io.Copy(remote, replayBuf); err != nil { return err } // 6. 发送上线通知 if username != "Unknown" { if m.WebhookUrl != "" { go m.sendWebhook(username, fmt.Sprintf("Player %s connected", username)) } } // 7. 开启双向管道转发后续流量 errc := make(chan error, 1) go func() { _, err := io.Copy(cx, remote) errc <- err }() go func() { _, err := io.Copy(remote, cx) errc <- err }() <-errc // 阻塞等待连接断开 // 8. 计算时长并发送下线通知 duration := time.Since(startTime) if username != "Unknown" && m.WebhookUrl != "" { go m.sendWebhook(username, fmt.Sprintf("Player %s disconnected. Duration: %s", username, duration)) } return nil } // parseMCLogin 极其简化的协议解析 // 依次读取 Handshake 包和 Login Start 包 func (m *MCMonitor) parseMCLogin(r io.Reader) (string, error) { // 使用 go-mc 库帮助解包，避免手动处理 VarInt var p packet.Packet // --- 第一步：读取 Handshake 包 --- if err := p.UnPack(r, -1); err != nil { return "", err } // Handshake 包结构: Protocol Version | Server Address | Server Port | Next State var ( protocolVersion packet.VarInt serverAddr packet.String serverPort packet.UnsignedShort nextState packet.VarInt ) if err := p.Scan(&protocolVersion, &serverAddr, &serverPort, &nextState); err != nil { return "", err } if nextState != 2 { // 2 代表登录状态 return "", fmt.Errorf("not a login handshake") } // --- 第二步：读取 Login Start 包 --- // 紧接着发来的就是包含了用户名的包 if err := p.UnPack(r, -1); err != nil { return "", err } var username packet.String // Login Start 包结构: Username | (Optional UUID) err := p.Scan(&username) return string(username), err } Caddyfile 配置 插件的使用非常简单，直接在 Caddyfile 的 layer4 块里定义即可。 ...

前言 最近在和几个做开发的朋友聊天，发现大家对“梯子”这个基础设施的认知两极分化很严重。 A 君是典型的“实用主义者”，手里握着三个月付 5 块钱的机场，挂了一个切另一个，主打一个“能用就行”。B 君则是“重度依赖者”，非 Tag 这种一线专线机场不用，每个月在网络上的开销比话费还贵。那对我来说，我肯定是重度依赖者（笑 这其中争论的焦点无非是：都是翻墙，为什么价格差了 20 倍？ 作为一个新入门的SRE，并且是曾经开过机场的人，知道这背后其实是可用性与成本控制的博弈问题，今天我就试着抛开“良心”这种主观词汇，用 SRE 的视角来聊聊机场的选择。 架构与链路：公网拥堵 vs 内网专线 那我就要问了，买机场买的是什么？买的不就是一个能看 YouTube、刷推特的工具吗？ 如果你只是为了娱乐，那确实是这样。但对于大多数 IT 从业者来说，带宽其实是最廉价的指标，稳定性才是最昂贵的。 一元机场的架构：又不是不能用 廉价机场（比如月付 1 元、5 元这种）通常采用的是公网中转甚至直连架构。 也就是说，从网络拓扑上看，你的流量是这样的： 你的电脑 -> 运营商公网 -> 中转机（通常是移动/联通） -> 公网骨干网 -> 落地机 -> 目标网站 什么是中转机？ 中转机 (Relay Server) 在技术架构上是一台部署在国内优质网络节点（如广州移动、上海联通 BGP 机房）的 流量转发服务器。与很多人误解的不同，中转机本身并不运行代理协议（如 Shadowsocks、V2Ray），它只负责「搬运」加密后的数据包。 实现转发的常用工具包括： Gost：支持多种传输协议的隧道工具，是目前中转机最主流的选择 Realm：Rust 编写的高性能端口转发工具，以低资源占用著称 iptables/nftables：Linux 内核级的端口转发，性能最高但功能简单 socat / rinetd：轻量级的 TCP 转发工具 从网络层面看，中转机主要解决两个问题： 优化国内段路由：通过选择与中国电信、联通、移动直连且延迟低的机房，减少数据包在出境前经过的跳数（Hops）和运营商间结算点（Peering Point），从而降低延迟和丢包。 规避 GFW 的 QoS 干扰：GFW 会对长期大流量或特征明显的境外连接进行限速或干扰。中转机将「用户‑落地机」的长连接拆分为「用户‑中转机」和「中转机‑落地机」两段，使得 GFW 更难追踪完整链路。 因此，中转机本质上是一个 「透明隧道」+「路由优化器」 的组合——它不解密你的流量，只负责把数据包以更优的路径送到境外落地机。真正的代理协议解密发生在落地机上。 ...

2025年的总结，该从哪里开始呢？ 我承认我是一个窥私欲很强烈的人，但是不写年度总结也不是真的就只想看别人的年度总结 只是因为我这几年的生活一成不变，好玩的都在私聊或者是群聊中释放了 今年不一样 但是今年确实不一样，直到2025年我才真正开始掌控了自己的生活 在这年里，我拿到了人生中第一份自己选择的工作 说起这份工作，准确来说是实习，过程也有点坎坷 人生第一面，是面了一家深圳的外企，当晚上口头offer了，结果第二天早上反悔，加面一轮，遂挂 后面又面了一些奇怪的厂商，有游戏有安全的，面试官给我的感觉是不尊重人，面SRE给我问 transformer原理，简直有病 最后一面，面了一家在成都做AI客服的公司，面我的是+2，当时给我的感觉就是非常和蔼，本来想着在成都，离家太远不打算去的，面完一轮就给我发了offer 给完offer后我还答应了一个很紧迫的时间，差不多是过完周末就飞去成都了 也是佩服自己，这么短时间就能搞定租房（其实也踩坑了 难搞的那些人和事 成都的经历是痛并快乐着的 自己光速租的房子到后面发现有大问题，本来是双层公寓，硬改成的两层分开的房间 在没住进多人的时候还没什么问题，等楼下住进住户之后，天天大喊大叫，声音透过薄薄的楼板直刺我的耳朵 楼下的吵就算了，骂了他几句就收敛了，建筑外立面的疑似空调管还是什么没固定好，6月份起风的时候摇的撞墙乓乓响 更折磨的是租房之外的事情 来了个实习生，+1说是招来配合我的，实际招来让我难受了好一阵子，好多东西都要教，而我作为实习认为带实习生不应该是我的工作，这也是我提前跑路的原因 总有一点收获 今年的社交可能是大学以来最多的一年，特别是网上社交 年初跟网友N一起看展，自己也去一直念想的深圳“奇特”景点逛了一圈 在华强北，自己跟老板讲价，购入了一台美版Xs，玩起了越狱 也去传说中的三和大神聚集地“暗访”了一波，确实看到了很多不一样的生活 也可能只有在三和，才能在深圳有6块钱荤素搭配的饭 网友N也带我体验了很多不同的东西，人生中第一次住网友家，第一次看livehouse，还有第一次用apple tv？ 君は「引力」を信じるか？ 你相信引力吗？曾几何时我是不相信的，只相信世界比较小，人们才容易聚在一起 当时在牛客上刷到一篇特别有干货的面经，后面竟然在推特刷到了，也从3月份一直聊到了现在 同时也是这个网友A鼓励我多写面经，我写的面经也帮到了不少人，每次打开牛客都能收获赞和私信，虽然总有些奇奇怪怪的人，但是总有一点收获 秋招？就当是一场梦 当然2025年也是不顺的一年 秋招的结果简直算是爆炸，猛投，0约面，更不要说offer了 当然这也是我咎由自取，秋招开始的太晚，投大厂甚至是11月才开始 到12月只有一个实习面试，面的还很烂 只能收拾铺盖回家准备春招再战了 躲进赛博避风港 今年最大的一笔消费莫过于组了人生中第一台正经的NAS 说是NAS，其实不如说是home server 并且作为一个纯正的垃圾佬，硬件自然是二手的，主板是笔记本U魔改的，硬盘买来的时候已经写入不知道多少T了，可以说只有机箱是新的 但也就是这样的垃圾让我获得了真正的满足，用它开了mc服务器，度过我等待面试的每一天 也在上面部署了telegram search，顺便提了个pr，实现了我想要的功能（这也是我第一次参加开源 相比现实世界，还是赛博空间让人感到安心 当然，赛博空间的乐趣不止如此 这几年我一直在使用各类大模型，感觉是到今年才是真正的模型能力的大爆发 年初尝试自己搓了个MCP玩，给朋友实现了输入讲义PPT自动生成实现报告，以为这就是agent能力的极限了 后面用 Gemini CLI 搓了很多不大不小的项目，再后面用 Antigravity 配合 Gemini 3 Pro 真正实现了一天撸完学校课程设计前后端+客户端 以前很多想做但因为技术栈不熟而搁置的想法，今年都一一实现了，大模型让我变成了个懒人（虽然本来也很懒），也让我开始挑战那些真正复杂的领域 也是大模型能力的提升让我变成一个“架构师”了，以前“打字”的繁琐很多可以交给它来实现 软件工程真的是越来越重要了呢😝 NO GAME NO LIFE 抛开乱七八糟的事情，玩乐才是人生的主旋律 ...

前言 Google One Pro 提供了 2TB 的存储空间以及 Gemini Advanced 的使用权限，通常价格不菲。最近 Google 推出了针对学生的优惠活动，只要通过学生身份认证，即可免费获得一年的订阅服务。本文将记录我如何利用学生身份成功领取的全过程。 准备工作 在开始之前，你需要准备以下几样东西： 教育账户： 需要一个能够通过 SheerID 验证的邮箱。亲测宾夕法尼亚州立大学（PSU）的邮箱可用。 注册地址：http://accounts.psu.edu/create/new 美国地址信息： 订阅时需要填写账单地址，建议使用生成器生成一个美国地址，并保持一致。 地址生成器：https://www.meiguodizhi.com/usa-address/pennsylvania 网络环境： 需要将你的网络节点切换到活动支持的地区，推荐使用 美国、日本或新加坡节点。 支付方式： 虽然是免费试用，但 Google 需要验证支付方式。你需要一张 Visa 或 MasterCard 的信用卡/借记卡（国内发行的双币卡通常也可以，或者使用 U 卡）。 领取步骤 1. 网络测试 首先，确保你的网络环境已经切换到美国节点，先使用ping0.cc测试你的IP是否足够纯净 我的IP风险如下，如果风控值超过50可能难以注册 2. 学生身份注册认证 进入PSU注册页面后，依次填入信息（不一定要是真的） 到达第四步后，在最上方的邮箱地址处填入你想要接受邮件的邮箱 之后继续注册，会把注册邮件发到你的邮箱 在这里，给我分配的邮箱是[email protected]，拿着这个邮箱在登录页面登录即可 到这里，一个有认证资格的账户就注册好了，谷歌的认证不一定需要发送邮件，能通过sheedID即可 白嫖订阅 访问 Google One 的学生优惠活动页面： http://one.google.com/ai-student 点击页面上的订阅按钮后，会跳转到 SheerID 的认证界面。 在学校列表中找到你邮箱对应的学校（例如 Pennsylvania State University）。 选择学校后，就像刚刚登录认证页面那样登录你在PSU的账户 到此，sheerID认证成功！ 3. 绑定支付方式并订阅 通过身份验证后，会回到 Google One 的订阅页面。 ...

我有这么一个需求：查询某个云服务商的服务器账单信息。比如我想查询Volcengine上所有昵称包含nginx的服务器的账单信息。(话说怎么不直接用sql呢,一定不是因为我懒得写sql吧？) 我的GenAI Toolbox配置如下： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 sources: cost_analysis: kind: postgres host: "10.0.2.49" port: 5432 user: "postgres" password: "123456" database: "cost_analysis_db" tools: find-server-billing-by-nickname-and-provider: kind: postgres-sql source: cost_analysis statement: | SELECT s.instance_id, s.nickname, b.billing_cycle, b.pretax_amount, b.provider FROM servers AS s JOIN billing_details AS b ON s.instance_id = b.resource_id AND s.provider = b.provider WHERE s.nickname LIKE '%' || $1 || '%' AND s.provider = $2 LIMIT 20 description: | 根据服务器昵称关键字和云服务商名称查询服务器及其账单信息。 输入 nickname 关键字（支持模糊匹配）和 provider（如 Volcengine,AlibabaCloud,TencentCloud），返回相关服务器和账单数据。 示例参数： { "nickname_keyword": "nginx", "provider": "Volcengine" } parameters: - name: nickname_keyword type: string description: 服务器昵称的关键字，支持模糊查询（如 nginx） - name: provider type: string description: 云服务商名称（如 Volcengine） 在这里我定义了两个变量nickname_keyword和provider，分别表示服务器昵称的关键字和云服务商名称。 ...