![合并.png](https://pic.mereith.com/img/1d0dd6572d4487e30d2366b6836eae61.%E5%90%88%E5%B9%B6.png)

> 项目主页: [https://vanblog.mereith.com](https://vanblog.mereith.com)<br/>
> 开源地址: [https://github.com/mereithhh/van-blog](https://github.com/mereithhh/van-blog)<br/>
> Demo 站: [https://blog-demo.mereith.com](https://blog-demo.mereith.com)<br/>
> 喜欢的话可以给个 star 哦 🙏



## 前因

我大二那年，第一次接触到了个人博客这个东东。看着别人炫酷的个人网站很羡慕，于是第一次买了一台云服务器，在网上到处搜教程，用 `hexo` 和 `next` 主题部署了我的第一版博客。

那时候抱着巨大的热情，我折腾了背景，折腾了 `live2d`，折腾了鼠标特效，等等。

但用了一阵子觉得有些很不方便。因为 `hexo` 这类的静态网站生成器本身是没有后台的，所以我必须用自己的方式写 `markdown` 文件、敲命令行、发布到网上（那时候还不会搞 CI/CD）。

后面我陆续尝试了其他带后台的博客系统，比如 `typecho` 、`wordpress` ，后者给我的感觉有些臃肿，前者感觉挺依赖主题的，很多也没有满足我的审美，有些特效加多了还挺卡，而且自带的编辑器和图床也没有很好用。

毕业的时候我用 `react` 写了一版带前后台的博客，`SSR` 渲染的博客，但是因为当时没有一个统一的规划，小问题不断，也不支持暗色模式，也没有内置图床，加载速度也并没有很快。

工作后闲暇时间，我又用 `gastby` 重构了一版博客，加载速度快了很多，但本质上 `gastby` 也是个静态页面生成器，而且每次发版都要全量构建。

## 后果

辞职后在家有时间了，我又想折腾一下博客，我的核心要求大概是：

1. 最好是静态页面（`SSG`），方便 `SEO` 和 `CDN`。
2. 要带一个方便的后台。
3. 要内置图床，支持剪切板上传图片，支持不同的图床。
4. 前后台都要支持移动端，都要支持暗色模式且能自动切换。
5. `SSG` 的话希望不要每次发版都全量构建。
6. 不要花里胡哨的特效，首屏加载一定要快。
7. 可以 `docker` 一键部署。
8. 支持访客统计和评论。

于是我调研了一番，发现现有的没有特别符合要求的，于是干脆自己写了一个，具有以下的特点：

- [x] 快到极致的响应速度，Lighthouse 接近满分。
- [x] 独一份的按需全自动 HTTPS，甚至不用填域名。
- [x] 包括完整的前后台和服务端。
- [x] 前台和后台都为响应式设计，完美适配移动端和多尺寸设备。
- [x] 前台和后台都支持黑暗模式，并可自动切换。
- [x] 前台为静态网页（SSG），并支持秒级的增量渲染，每次改动无需重新构建全部页面。
- [x] 静态网页，CDN 友好。
- [x] 基于 React，项目工程化，二次开发友好。
- [x] SEO 和无障碍友好。
- [x] 版本号展示和更新提醒。
- [x] 内置强大的分析功能，可统计访客等数据。并配有精美看板。
- [x] 内嵌评论系统。
- [x] 强大的 markdown 编辑器，支持图表和数学公式，一键插入 more 标记，一键剪切板及本地图片上传，
- [x] TOC、草稿、代码复制、访客数、评论数、分类、标签、搜索、加密、友链、打赏、自定义导航栏。
- [x] 多个布局设置，可自定义页面细节。
- [x] 支持自定义页面。
- [x] 可添加具有指定权限的协作者。
- [x] 高度客制化，可添加自定义 CSS、HTML 和 JS 代码。
- [x] 内置图床，并支持各种 OSS 图床、github 图床（外部图床基于 picgo）等。
- [x] 极致轻量化，没有花里胡哨。页面秒切换、图片懒加载。
- [x] docker 一键部署，支持 ARM 平台。
- [x] 支持 GA、百度分析
- [x] 简单易用的后台，支持数据的导出与导入。
- [x] 完善的 API，完全利用本项目后台和服务端，自己写前端或适配其他页面生成器
- [x] 有较完善的日志记录，后台可直接查看登录日志和 Caddy 日志。

我把它命名为 [VanBlog](https://vanblog.mereith.com)，有兴趣的话可以试一下哦。

> 项目主页:[https://vanblog.mereith.com](https://vanblog.mereith.com)
> 开源地址:[https://github.com/mereithhh/van-blog](https://github.com/mereithhh/van-blog)
> Demo 站: [https://blog-demo.mereith.com](https://blog-demo.mereith.com)

## 一键脚本部署

```bash
curl -L https://vanblog.mereith.com/vanblog.sh -o vanblog.sh && chmod +x vanblog.sh && ./vanblog.sh
```

其他部署方式和详细说明请移步 [项目文档](https://vanblog.mereith.com/guide/docker.html) 

PS: 不然的话每次改一点部署文档，所有平台都要改好麻烦233

## 预览图


![前台-白色.png](https://pic.mereith.com/img/2afb648e4cd43b8479bba29caa0f5679.%E5%89%8D%E5%8F%B0-%E7%99%BD%E8%89%B2.png)


![前台-黑色.png](https://pic.mereith.com/img/2658c90cda2f9a7ef69a9795d05ce6c7.%E5%89%8D%E5%8F%B0-%E9%BB%91%E8%89%B2.png)


![后台-白色.png](https://pic.mereith.com/img/7b343a679cdf9a51d6674b1f5ad45dd7.%E5%90%8E%E5%8F%B0-%E7%99%BD%E8%89%B2.png)


![后台-黑色.png](https://pic.mereith.com/img/cc4b603d6db746c3fb9b1a34beb74cbc.%E5%90%8E%E5%8F%B0-%E9%BB%91%E8%89%B2.png)

![](https://pic.mereith.com/img/7b0e81378a84eba82e4fbfde9cb5bc7d.clipboard-2022-08-27.png)

因为选择艰难症，自己写了一套开源博客系统

:::info{title="注意"}
以下内容通过 AI 整理汇总。
:::

## 背景

最近我遇到了一个看似简单，但实际上颇为棘手的网络问题。事情是这样的：

我在国内工作，手上有一个海外的HTTP代理服务，格式是 `http://username:password@proxy.example.com:31212`。由于众所周知的原因，这个代理在国内是直接访问不了的。不过，我还有一台位于海外的VPS服务器（IP：x.x.x.x），国内是可以正常访问的。

我的想法很简单：既然我能访问海外VPS，VPS能访问代理，那我就在VPS上搭建一个转发服务，让流量走这样的路径：

```
本地电脑(中国) → 海外VPS → HTTP代理 → 目标网站
```

听起来是不是很合理？我当时也是这么想的。





## 初次尝试

### 验证代理可用性

首先，我SSH登录到海外VPS上，写了个简单的Python脚本测试代理是否正常：

```python
import asyncio
import aiohttp

async def test_proxy():
    proxy = "http://username:password@proxy.example.com:31212"
    async with aiohttp.ClientSession() as session:
        async with session.get(
                url="http://www.google.com",
                headers={
                    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"
                },
                proxy=proxy,
        ) as response:
            print(f"Status: {response.status}")
            print(f"Response length: {len(await response.text())}")

asyncio.run(test_proxy())
```

运行结果：完全正常！代理是可用的。

### 搭建转发服务

接下来，我尝试了多种转发方案：

1. **Python脚本转发**：写了个简单的HTTP转发服务
2. **Gost工具**：使用了专业的代理转发工具
3. **其他各种转发工具**

然而，奇怪的事情发生了...

## 诡异的现象

当我在本地通过这些转发服务访问时，全部失败！错误信息都是：

```
Connection reset by peer
```

更诡异的是，我发现了一个规律：

- ❌ 当我的电脑**不使用任何代理**，直接访问VPS上的转发服务时 → 失败
- ✅ 当我的电脑**使用透明代理**（如Shadowsocks）时，再访问VPS上的转发服务 → 成功

这就很奇怪了。按理说，如果是转发服务的问题，那应该一直都不能用才对。为什么使用了透明代理就能工作呢？

## 问题分析

经过一番思考和查阅资料，我终于明白了问题所在：**GFW的深度包检测（DPI）**。

### 原理解析

当我们从国内直接访问海外服务器时，所有的数据包都会经过GFW。GFW不仅仅是简单地封锁IP或域名，它还会进行深度包检测，分析数据包的内容和模式。

对于HTTP代理来说，有几个明显的特征：

1. **CONNECT方法**：HTTP代理在建立HTTPS连接时，会发送明文的CONNECT请求
2. **特定的请求头**：如`Proxy-Authorization`等
3. **流量模式**：代理流量有其特定的模式

当GFW检测到这些特征时，它会认为这是一个代理连接，然后主动发送RST包来断开连接。这就是为什么我们会收到"Connection reset by peer"的错误。

### 为什么透明代理可以工作？

当使用Shadowsocks等透明代理时，我们的流量已经被加密和混淆了。GFW看到的只是一堆加密数据，无法识别出里面包含的HTTP代理协议特征，所以就不会干扰连接。

这就像是：
- 直接转发 = 透明的玻璃箱子运输违禁品
- 透明代理后转发 = 不透明的铁箱子运输违禁品

## 最终解决方案

在尝试了各种复杂的转发方案后，我意识到：**与其在应用层做各种转发和伪装，不如直接在网络层解决问题**。

最终我采用了一个简单粗暴但非常有效的方案：

### 1. 在VPS上部署 sing-box

直接在海外VPS上使用 sing-box 搭建了一个 VLESS 节点。sing-box 是一个强大的网络代理平台，支持多种协议，而 VLESS 是一个轻量级的代理协议，具有良好的性能和安全性。

配置非常简单，sing-box 可以直接配置上游代理，这样就形成了：
```
本地 → VLESS加密隧道 → VPS上的sing-box → HTTP代理 → 目标网站
```

### 2. 本地使用 Clash 的 TUN 模式

在本地电脑上，我使用 Clash 配置了 VLESS 节点，并开启了 TUN 模式。TUN 模式是一种透明代理模式，它会在系统层面创建一个虚拟网卡，所有的网络流量都会经过这个虚拟网卡。

这样做的好处是：
- **完全透明**：应用程序完全感知不到代理的存在
- **全局生效**：所有的网络请求都会自动走代理
- **无需修改代码**：原来的代码一行都不用改

### 3. 代码层面的解放

配置好之后，我的Python代码可以直接这样写：

```python
import aiohttp
import asyncio

async def fetch_youtube():
    # 直接用代理，clash 已经接管了系统流量，会自动绕到中转节点的。
    proxy = "http://user:passj@proxy.example.com:31212"
    async with aiohttp.ClientSession() as session:
        async with session.get("https://www.youtube.com",proxy=proxy) as response:
            print(f"Status: {response.status}")
            print(f"Title found: {'YouTube' in await response.text()}")

asyncio.run(fetch_youtube())
```

## 可能的其他方案

### 方案一：SSH隧道
SSH是一个非常常见的服务器管理协议，不容易被封锁。我们可以利用SSH的端口转发功能：

在VPS上运行HTTP转发服务（监听本地端口）
在本地建立SSH隧道：
```bash
ssh -N -L 8080:localhost:8888 root@your-vps-ip
```
这样，访问本地的8080端口就相当于访问VPS上的8888端口，而且所有流量都是通过SSH加密的。

### 方案二：gost/nodepass/realm 加密隧道
使用专业的工具，进行加密隧道转发。

### 方案三：国内找一个 server，与国外中转服务器组成加密隧道
国内的网络是没有 gfw 的，如果我有多台中转服务器，就是想在代码里精确控制，灵活搭配，而且还得用 http 代理。

那么可以找一个国内的中转服务器，与国外的若干个中转服务器组成加密隧道或者 vps（wireguard、tailscale、gost 等），然后在国内搭建 http 代理转发，流量在国内的中转节点加密后到国外的中转节点，然后再到海外的代理服务器。


## 总结

这次经历让我深刻理解了几个道理：

1. **问题要从根源解决**：与其在应用层做各种复杂的转发和伪装，不如直接在网络层用成熟的方案
2. **工具选择很重要**：sing-box + Clash 的组合非常强大，既有良好的加密特性，又有优秀的易用性
3. **透明代理是最优雅的方案**：TUN模式让所有应用都能无感知地使用代理，极大地提升了开发体验

最重要的是，这个方案让我可以专注于业务逻辑，而不是纠结于网络问题。代码该怎么写就怎么写，就像没有任何网络限制一样。

有时候，最简单的方案反而是最好的方案。**与其绕来绕去，不如一步到位！**

记一次代理转发问题的排查与解决

我有好几个集群，用 `PVE DataCenter Manager` 管理的时候，发现跳转有 bug。

比如我用 `https://pve.xxxx.com` （不用 8006 端口号），我在前端点 `Open WebUI` 跳转自动给我带上了 8006。

解法是登录到服务器，修改 `/usr/share/javascript/proxmox-datacenter-manager/index.hbs`，在 `head` 标签下面加入这个 `script` 标签。


```html
 <script type="text/javascript">
       (function() {
         // 判断字符串是否为IP地址
         function isIPAddress(host) {
             // IPv4地址正则表达式
             const ipv4Pattern = /^(\d{1,3})\.(\d{1,3})\.(\d{1,3})\.(\d{1,3})$/;
             if (!ipv4Pattern.test(host)) return false;
             
             // 验证每个段是否在0-255范围内
             const parts = host.split('.');
             for (let i = 0; i < parts.length; i++) {
                 const part = parseInt(parts[i], 10);
                 if (part < 0 || part > 255) return false;
             }
             return true;
         }
         
         // 判断是否以.top结尾
         function isTopDomain(host) {
             return host.endsWith('.top');
         }
         
         // 移除8006端口号 - 修复正则表达式
         function removePort8006(url) {
             return url.replace(/:8006(\b|\/|#|\?)/, function(match, p1) {
                 return p1; // 保留分隔符但移除端口
             });
         }
         
         // 处理URL函数
         function processUrl(url) {
             try {
                 const urlObj = new URL(url, window.location.href);
                 const host = urlObj.hostname;
                 
                 console.log("处理URL:", url, "主机名:", host, "端口:", urlObj.port);
                 
                 // 如果是IP地址，不做处理
                 if (isIPAddress(host)) {
                     console.log('IP地址链接，不做处理:', url);
                     return url;
                 }
                 
                 // 如果不是.top域名，且有8006端口，去除端口号
                 if (!isTopDomain(host) && urlObj.port === '8006') {
                     const newUrl = removePort8006(url);
                     console.log('已移除端口号，新URL:', newUrl);
                     return newUrl;
                 }
                 
                 return url;
             } catch (e) {
                 console.error('解析URL时出错:', e);
                 return url;
             }
         }
         
         // 立即覆盖window.open方法
         const originalWindowOpen = window.open;
         window.open = function(url, target) {
             if (url) {
                 console.log("拦截到window.open调用:", url, target);
                 // 移除对target的检查，无论是否有target参数都处理
                 const newUrl = processUrl(url);
                 if (newUrl !== url) {
                     console.log("调用原始window.open，参数已修改:", newUrl, target);
                     return originalWindowOpen.call(this, newUrl, target || "_blank");
                 }
             }
             return originalWindowOpen.apply(this, arguments);
         };
         
         // 初始化其他拦截器
         function initInterceptors() {
             console.log("初始化拦截器...");
             
             // 拦截所有链接点击事件
             document.removeEventListener('click', linkClickHandler, true);
             document.addEventListener('click', linkClickHandler, true);
             
             // 拦截location.assign
             const originalAssign = window.location.assign;
             window.location.assign = function(url) {
                 console.log("拦截到location.assign调用:", url);
                 return originalAssign.call(window.location, processUrl(url));
             };
             
             // 尝试拦截location.href设置
             try {
                 const originalLocationDescriptor = Object.getOwnPropertyDescriptor(Location.prototype, 'href');
                 if (originalLocationDescriptor && originalLocationDescriptor.configurable) {
                     Object.defineProperty(Location.prototype, 'href', {
                         set: function(url) {
                             console.log("拦截到location.href设置:", url);
                             return originalLocationDescriptor.set.call(this, processUrl(url));
                         },
                         get: originalLocationDescriptor.get,
                         configurable: true
                     });
                 }
             } catch (e) {
                 console.error('拦截location.href失败:', e);
             }
             
             console.log("拦截器初始化完成");
         }
         
         // 链接点击处理函数
         function linkClickHandler(event) {
             // 查找事件路径中的链接元素
             let element = event.target;
             while (element && element.tagName !== 'A') {
                 element = element.parentElement;
                 if (!element) break;
             }
             
             // 如果找到链接
             if (element && element.tagName === 'A') {
                 console.log("拦截到链接点击:", element.href, "target:", element.target);
                 
                 const newUrl = processUrl(element.href);
                 if (newUrl !== element.href) {
                     event.preventDefault();
                     console.log("阻止默认操作，使用新URL打开:", newUrl);
                     
                     if (element.target === '_blank') {
                         window.open(newUrl, '_blank');
                     } else {
                         window.location.href = newUrl;
                     }
                 }
             }
         }
         
         // 添加MutationObserver以监视DOM变化
         function setupMutationObserver() {
             console.log("设置MutationObserver...");
             
             const observer = new MutationObserver(function(mutations) {
                 // 当DOM变化时重新初始化拦截器
                 initInterceptors();
             });
             
             observer.observe(document.body, {
                 childList: true,
                 subtree: true
             });
             
             console.log("MutationObserver已设置");
         }
         
         // 初始化函数
         function initialize() {
             console.log("初始化拦截脚本...");
             initInterceptors();
             
             // DOM加载完成后设置MutationObserver
             if (document.body) {
                 setupMutationObserver();
             } else {
                 window.addEventListener('DOMContentLoaded', setupMutationObserver);
             }
             
             // 页面完全加载后再次初始化
             window.addEventListener('load', function() {
                 console.log("页面加载完成，重新初始化拦截器");
                 initInterceptors();
                 
                 // 延迟1秒再次初始化，确保WASM应用加载完成
                 setTimeout(initInterceptors, 1000);
             });
             
             console.log("拦截脚本初始化完成");
         }
         
         // 立即初始化
         initialize();
         
         // 添加到window对象，方便调试
         window.__interceptorFunctions = {
             initialize: initialize,
             processUrl: processUrl,
             isIPAddress: isIPAddress,
             isTopDomain: isTopDomain,
             removePort8006: removePort8006
         };
       })();
     </script>
```

PVE DataCenter Manager 端口号跳转错误修复

k8s + jenkins + gitlab 触发器

> 颇有感触，记录一下。 转载自： [theres-no-such-thing-as-software-productivity](https://www.benrady.com/2012/11/theres-no-such-thing-as-software-productivity.html)

正如马丁·福勒（Martin Fowler）所观察到的那样，程序员的编程生产力无法有效地衡量，因为它不存在。

软件开发并不是一项必然会产生任何东西的活动。

假设你有两个开发人员在同一个项目上工作，并且偶然地，他俩在同一天接受了相同的任务。

甲写了一个1000行的框架，完美地解决了这个问题。代码编写良好，并经过充分测试，每一步都有详细记录。

乙则是当天去了公园，一边喂鸽子一边思考问题，然后漫步回到办公室，删除了100行代码，部署了更改......问题就解决了。

请问谁的生产力更高？

回答是，这不重要。重要的是乙解决了问题，同时降低了团队的长期维护成本。甲也解决了这个问题，但是他通过增加代码，增加了维护成本，因此（在其他条件相同的情况下）他的解决方案较差。

我们能说，乙具有更高的生产力吗？显然，很难找到编程生产力的正确衡量指标。

我认为，优秀的软件开发者所做的就是解决问题。但是，生产力的衡量指标，比如代码、文档、数据等等，都只是解决问题的工具，并不是解决问题本身。