# 前言
自从部署了open-webui和searxng，每天都提心吊胆，open-webui的模型访问时灵时不灵，searxng则一直处于不可用的状态。今天调试了一个下午+晚上，终于找到了问题的根源所在

问题就在于系统未开启NAT转发



# 症状描述
一开始的症状
- 模型能够输出，联网搜索不能访问bing和google，或是时行时不行，重启docker服务有概率刷新状态变得行，过一天就又不行了
- open-webui有时不能访问海外的模型，如grok，重启docker服务有概率刷新状态

中度患病症状
- open-webui能够通过api获得模型服务，但是无法访问searxng返回的链接地址。查询日志发现是dns寄，下面是报错节选
  >   File "/app/backend/open_webui/main.py", line 1263, in chat_completion
    form_data, metadata, events = await process_chat_payload(
    │          │                        └ <function process_chat_payload at 0x7a094b3f4900>
    │          └ {'user_id': '88809597-0b64-42bc-8051-f3a2762f16f5', 'chat_id': 'fa6e9087-cd55-4a3f-9b68-7fb1c1bedf0f', 'message_id': '1128f12...
    └ {'stream': True, 'model': 'deepseek-ai/DeepSeek-V3', 'messages': [{'role': 'user', 'content': '量子力学都讲了什么？'}], 'stream_options...
  >File "/app/backend/open_webui/utils/middleware.py", line 837, in process_chat_payload
    form_data = await chat_web_search_handler(
                      └ <function chat_web_search_handler at 0x7a094b3f4540>
  > File "/app/backend/open_webui/utils/middleware.py", line 418, in chat_web_search_handler
    results = await process_web_search(
                    └ <function process_web_search at 0x7a094e988400>
  > File "/app/backend/open_webui/routers/retrieval.py", line 1903, in process_web_search
    raise HTTPException(
          └ <class 'fastapi.exceptions.HTTPException'>
  > fastapi.exceptions.HTTPException: 400: [ERROR: [Errno -3] Temporary failure in name resolution]

  注意到最后一行明确说域名解析出错

- searxng彻底寄了，再也没有返回搜索结果

重度患病症状
- open-webui彻底上不了网了，curl解析任何域名都是错误，ping也无法ping同
- 所有桥接模式的容器均无连接网络，内网地址也无法ping通

不过非常奇怪的是居然wget可以而ping不行，太奇妙了...... 鉴于应用容器里可能并没有网络工具可以用，利用共享网络可以进行排查
```sh
# Ping测试（测试基础网络连通性）
docker run -it --rm --network container:open-webui busybox ping www.google.com

# DNS解析测试（检查DNS是否正常）
docker run -it --rm --network container:open-webui --dns 223.6.6.6 busybox nslookup www.google.com

# HTTP/HTTPS测试（检查Web访问）
docker run -it --rm --network container:open-webui curlimages/curl -v https://www.google.com
```
其中`container`冒号后面的可以替换为你想要排查的容器

# 原因及解决方案

出现这种问题的原因是宿主机没有开启NAT转发这是因为docker的桥接模式相当于在内部开启了很多子网，通过NAT访问外部网络，如果没有设置NAT转发表，那自然什么包都发不出去

查看 NAT 表和转发规则
```sh
sudo iptables -t nat -L -n
```

如果发现输出空空如也，就像这样
```sh
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination 
```
那么恭喜你，遇到了同样的问题，只需要更新转发表就可以解决了

```sh
sudo iptables -t nat -A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE
```
其中的`172.17.0.0/16`是子网网段，查看可以使用
```sh
sudo docker network ls
```
输出可能如下
```sh
NETWORK ID     NAME                         DRIVER    SCOPE
a75edbc74b8d   bridge                       bridge    local
5d8c3bc411e6   gitea_network                bridge    local
35b3d93a3e07   host                         host      local
f57a8a296aed   none                         null      local
cf99908db9ed   openwebui_network            bridge    local
4342734b5b0b   searxng-docker_searxng       bridge    local
55a3f3ff8c8a   vanblog-docker_vanblog_net   bridge    local
```
然后就可以挑其中出问题的网络，比如`openwebui_network`，查看它的具体网段
```sh
sudo docker inspect openwebui_network
```
输出可能会长这样子
```sh
[
    {
        "Name": "openwebui_network",
        "Id": "cf99908db9ed89908c479a43488d384175e18f1235d381609472ccff30508310",
        "Created": "2025-05-31T12:15:30.632791272Z",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv4": true,
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                {
                    "Subnet": "172.20.0.0/24",
                    "Gateway": "172.20.0.1"
                }
            ]
        },
        "Internal": false,
        "Attachable": false,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {
            "2fdc42d8b5a0b4a4749b8e008adacb3a26bfbee79b49b3c56f4012d763f29946": {
                "Name": "open-webui",
                "EndpointID": "b760eba143788b3f8d0f8f222318a2f6fc5b13c55530c31e4fcfe7126ff86fe2",
                "MacAddress": "86:40:da:4a:d8:fc",
                "IPv4Address": "172.20.0.2/24",
                "IPv6Address": ""
            }
        },
        "Options": {},
        "Labels": {
            "com.docker.compose.config-hash": "0fc5495dcbf807ab9ff256763ac3e1205637af01bb04915ff76c9cfb8ec5f0a8",
            "com.docker.compose.network": "openwebui_net",
            "com.docker.compose.project": "open-webui",
            "com.docker.compose.version": "2.36.2"
        }
    }
]
```

注意到其中`Subnet`字段，这正是需要添加进转发表的网段，完成后就可以愉快地玩耍了

解决Docker容器内桥接模式无法上网的问题

没有免费午餐定理是说：对于完全随机的问题，所有算法的平均性能相同。这意味着如果一个算法在某些问题上工作得较好，那么一定存在一些其他的问题使得该算法的性能较差。因此脱离具体的问题而空谈算法好坏没有意义



假定样本空间$\chi$与假设空间$H$离散，现有一个算法$L$，设其经过训练数据$X$的训练后得到假设空间中的一个函数$h$的概率为
$$
P(h|X,L)
$$

再设真实的函数为$f$，那么误差就是
$$
E(L|X,f)=\sum_h\sum_{x\in \chi-X}P(x)\mathbb{I}[h(x)\neq f(x)]P(h|X,L)
$$
其中$\mathbb{I}$为示性函数
$$
\mathbb{I}(x)=
\begin{cases}
1&x=true\\
0&x=false
\end{cases}
$$

考察二分类问题，可能的真实目标函数空间是
$$
\{0,1\}^{|\chi|}
$$

意为对于所有样本，都有不同的函数将它们映射到0或是1。假设所有的$f$服从均匀分布，那么对于所有可能的$f$误差之和为
$$
\sum_fE(L|X,f)=\sum_f\sum_h\sum_{x\in \chi-X}P(x)\mathbb{I}[h(x)\neq f(x)]P(h|X,L)
$$

调整求和顺序
$$
\sum_fE(L|X,f)=\sum_{x\in \chi-X}P(x)\sum_hP(h|X,L)\sum_f\mathbb{I}[h(x)\neq f(x)]
$$

由于$f$服从均匀分布，所以对一个样本而言有一半分类正确另一半分类不正确。又因为总的函数数目为$2^{|\chi|}$，所以
$$
\sum_fE(L|X,f)=\dfrac12\cdot2^{|\chi|}\sum_{x\in \chi-X}P(x)\sum_hP(h|X,L)
$$

对所有的$h$其生成概率之和应当是归一化的，所以
$$
\sum_fE(L|X,f)=2^{|\chi|-1}\sum_{x\in \chi-X}P(x)
$$

所以得到分类错误与算法$L$是无关的

没有免费午餐定理NFL

不知道怎么回事，我的Ubuntu24.04经常时不时自动重启，这是让人难以接受的。不过一番寻找并没有找到这个重启是谁干的，所以并不能阻止它。但是每次还得我手动把服务开起来，这也太难受了，所以需要写一个脚本将服务在开机时自动开起来。一般来讲后台任务使用`screen`，开机自启动使用`systemd`是比较好的做法



# 启动screen的脚本
```sh
#!/bin/bash

# 定义一个函数来检查并创建 screen 会话
create_screen_if_not_exists() {
    local session_name="$1"
    local command="$2"
    
    # 检查 screen 会话是否存在
    if screen -list | grep -q "\.${session_name}\s"; then
        echo "Screen session '${session_name}' already exists. Skipping."
    else
        echo "Creating screen session '${session_name}'."
        screen -d -m -S "$session_name" bash -c "$command"
    fi
}

# 使用函数创建各个 screen 会话
create_screen_if_not_exists "<screen name>" '<command1 && command2 && ... && bash>'
...
```
`create_screen_if_not_exists`函数接受两个参数：名称和命令。命令可以有很多条，用`&&`连在一起。这里需要注意的是结尾的`&& bash`表示screen会话一直打开。如果希望执行命令后退出，则应使用`&& exit`

执行函数时会检查是否已经创建了screen，如果已经有了就不会执行相应的命令

写好脚本后需要赋予其可执行权限
```sh
chmod +x <path_to_the_script>
```

# 使用systemd管理开机自启动任务
首先创建systemd服务文件
```sh
sudo nano /etc/systemd/system/start-screens.service
```
其中`start-screens.service`是名字可以随意。如果没有`nano`可以装一个，然后输入
```ini
[Unit]
Description=<描述一下这个服务是干什么的>
After=network.target

[Service]
Type=oneshot
ExecStart=<要执行的脚本的路径>
RemainAfterExit=yes
User=<用户名>

[Install]
WantedBy=multi-user.target
```
其中`After=network.target`确保网络启动后再运行脚本（因为我这个脚本是为了启动网络服务）。按`Ctrl+S`保存文件，然后按`Ctrl+X`退出编辑

随后重新加载systemd配置
```sh
sudo systemctl daemon-reload
```

然后启用服务
```sh
sudo systemctl enable start-screens.service
```

可以执行下面的命令来执行一次脚本
```sh
sudo systemctl start start-screens.service
```

查看screen会话是否正常开启
```sh
screen -ls
```

使用systemd添加开机自启动screen后台任务

Gitea是一个安装便捷，轻量级的自建 Git 服务，通过Docker非常容易部署与迁移

本文参考自gitea的文档：[https://docs.gitea.com/zh-cn/](https://docs.gitea.com/zh-cn/)


# docker部署gitea
首先创建一个gitea的文件夹并进入
```sh
mkdir gitea-docker
cd gitea-docker
```
随后创建`docker-compose.yml`文件，并编辑之
```sh
touch docker-compose.yml
nano docker-compose.yml
```
编辑`docker-compose.yml`如下
```yml
version: "2"

services:
  server:
    image: docker.gitea.com/gitea:latest-rootless
    restart: always
    volumes:
      - ./data:/var/lib/gitea
      - ./config:/etc/gitea
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    ports:
      - "3000:3000"
      - "2222:2222"
```
按`Ctrl`+`S`保存，并按`Ctrl`+`X`退出编辑。随后创建两个文件夹`config`与`data`

```sh
mkdir config data
```
赋予它们权限
```sh
sudo chown 1000:1000 config/ data/
```
随后，启动容器
```
sudo docker-compose up -d
```

# nginx配置反向代理
如果将gitea配置到某个域名，应该如此配置nginx
```nginx
server {
    ...
    location / {
        client_max_body_size 512M;
        proxy_pass http://localhost:3000;
        proxy_set_header Connection $http_connection;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}
```
然后重启nginx
```sh
sudo nginx -s relaod
```

# nginx 将gitea反向代理到某个子路径
比如我想把gitea反向代理到`gbwater.icu/git`，那么首先应当编辑`config/app.ini`
```sh
nano config/app.ini
```
随后将`ROOT_URL`配置改为
```sh
ROOT_URL = https://gbwater.icu/git/
```
将nginx配置为
```nginx
server {
    ...
    location ~ ^/(gitea|v2)($|/) {
        client_max_body_size 512M;

        # 确保 nginx 使用未转义 URI， 按原样保持 "%2F"。 确保 nginx 去除 "/gitea" 子路径前缀， 按原样传递 "/v2"。
        rewrite ^ $request_uri;
        rewrite ^(/gitea)?(/.*) $2 break;
        proxy_pass http://127.0.0.1:3000$uri;

        # 其他的常规 HTTP 表头，见上面“使用 Nginx 作为反向代理服务”小节的配置
        proxy_set_header Connection $http_connection;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}
```
随后重启gitea与nginx
```sh
sudo docker stop gitea-docker-server-1
sudo docker-compose up -d
sudo nginx -s reload
```
这么做是不推荐的，已知的问题是，在本地使用git登录时会跳转到不带`/git/`的路径

私有代码库: 使用Docker部署Gitea

如果不清楚数据中到底包含几类，则聚类算法可以分为**层次聚类**和**密度聚类**。层次聚类不断将两类合并为一类，形成一棵聚类树，然后划分聚类树得到类别；密度聚类则按密度扩张类别，不形成聚类树。层次聚类可以自动进行，不需要人为设置参数；而密度聚类需要给定密度阈值参数，并且对不同密度的簇聚类效果不好

将层次聚类与密度聚类相结合就能得到HDBSCAN算法，它通过空间变换使得适应不同密度的簇，并且引入稳定度的概念自动划分聚类树，并获得对噪声的良好抵抗效果



# 空间变换：核心距离与互达距离

进行空间变换的目的是适应不同密度的簇。对于一个数据点，给定参数k，它的**核心距离**定义为

:::info{title="核心距离"}
一个样本点的核心距离是距离它最近的第k个样本点与它的距离
:::

如果取$k=5$，则核心距离的示意图如图（图源[hdbscan.readthedocs.io](https://hdbscan.readthedocs.io/en/latest/how_hdbscan_works.html)）

![image.png](/static/img/ab9d521015331991dc2a4837eef720b0.image.webp)

进一步，得到每个样本点的距离之后，就可以对距离矩阵（每两个样本点之间的距离）做变换，得到**互达距离**矩阵

:::info{title="互达距离"}
两个样本点的互达距离是以下三者的最大值
1. 它们之间的距离
2. 一个样本点的核心距离
3. 另一个样本点的核心距离
:::

如果取$k=5$，则互达距离的示意图如图（图源[hdbscan.readthedocs.io](https://hdbscan.readthedocs.io/en/latest/how_hdbscan_works.html)）

这种情况下互达距离是其中一个样本点的核心距离
![image.png](/static/img/ccad0e99e08c5f2ff453fb8bf869a85b.image.webp)

这种情况下互达距离是两个样本点的距离
![image.png](/static/img/6d5caf127251b77c33a1d4f1e490c24d.image.webp)


# 构造最小生成树，进行层次聚类

假定有一个二维样本点分布是这样的（图源[hdbscan.readthedocs.io](https://hdbscan.readthedocs.io/en/latest/how_hdbscan_works.html)）

![image.png](/static/img/b86c1051a3590eb5c808c5813ac628fa.image.webp)

记样本点数目为$n$，利用$n(n-1)/2$个互达距离作为边连接各个样本点形成一张图，在此图的基础上构造最小生成树。由于这是一个稠密图，利用Prim算法会取得较优的时间复杂度

构造得到的最小生成树如图（图源[hdbscan.readthedocs.io](https://hdbscan.readthedocs.io/en/latest/how_hdbscan_works.html)）

![image.png](/static/img/d45163b1d6d11fc50d30ddd031ea2626.image.webp)

这样就得到了连接$n$个样本点的$n-1$条边，任何一条边都可以将大树分为两棵子树，可以利用它们进行层次聚类

0. 初始化每一个样本点为一个初始簇
1. 取出长度最小的边，将两端的两个簇合并
2. 重复1，直到所有边都取出

这样，就得到了一颗聚类树（图源[hdbscan.readthedocs.io](https://hdbscan.readthedocs.io/en/latest/how_hdbscan_works.html)）

![image.png](/static/img/16c312804f44316e0ef1e4955acde2dc.image.webp)

图中每一个节点的高度代表合并它两个子簇的最小生成树的边的长度，它下面竖条的颜色代表它含有的样本点数目

# 稳定度与类选择

为了噪声过滤与选择类，定义一个参数：**最小簇大小**，不妨将其记为m。进行如下的噪声过滤过程

0. 初始考察根节点
1. 若当前节点所含的样本数目小于最小簇大小，将其标记为噪声，不再递归考察子节点，返回
2. 若当前节点的两个子节点存在一个小于最小簇大小，则将小的那个标记为噪声，考察大的子节点
3. 若两个子节点都大于最小簇大小，分别再考察两个子节点

这一步排除了所有的小簇，下一步是分配类标签

0. 为根节点分配类标签，考察根节点
1. 若当前节点是噪声，则认为它从属的类在此时消亡，不再递归考察，返回
2. 若两个子节点都不是噪声，则认为分裂有效，为两个子节点分别分配新的类标签，并考察两个子节点。认为当前节点从属的类在此时消亡，两个新的类在此时诞生
3. 若两个子节点存在一个是噪声，则另一个子节点继承当前节点的类标签，递归考察它

做完这一步后，就从聚类树得到了一颗类树（图源[hdbscan.readthedocs.io](https://hdbscan.readthedocs.io/en/latest/how_hdbscan_works.html)）

![image.png](/static/img/cd2124dff56b10d6b150ef5665d646e1.image.webp)

从根类开始，类不断分裂为两个子类，直到消亡。至于左侧的 $\lambda$ 是什么，这就需要定义**生命周期**

定义一个聚类树中节点$\lambda$值为
$$
\lambda=\dfrac1{distance}
$$

其中$distance$是层级聚类过程中合并产生该节点的边的长度。$\lambda$可以看作时间，$\lambda$增大的过程看作是时间的演化。那么类树的分裂就可以看作是：随着时间的演化，不断有样本从大类中剥离，大类不断分裂为子类。由此定义类的生命周期

- $\lambda_{birth}$: 父类分裂诞生两个新类，分裂处节点的 $\lambda$ 值
- $\lambda_{death}$: 类消亡，消亡处节点的 $\lambda$ 值

对于一个类，对于它的包含的某个样本$p$，可以定义$\lambda_p$：在某个节点处，样本$p$被剥离出父类，该节点的$\lambda$值即为$\lambda_p$

随后，对于任意类$S$，可以计算它的稳定度
$$
stability=\sum_{p\in S} (\lambda_p-\lambda_{birth})
$$
直观上来看，一个类的稳定度就是类树中它下面的那一长条的面积。自然，稳定度越大的类是越好的，所以有这样的类选择规则

:::info{title="类选择规则"}
将所有叶子类设置为选择，自下而上地考察父类
- 若父类的稳定度小于两个子类的稳定度之和，那么不选择父类，并把父类的稳定度设置为两个子类的稳定度之和
- 若父类的稳定度大于两个子类的稳定度之和，则将父类设置为选择，将所有的子类设置为不选择
:::

这样，就从类树中选择了一系列的类（图源[hdbscan.readthedocs.io](https://hdbscan.readthedocs.io/en/latest/how_hdbscan_works.html)）
![image.png](/static/img/eeff157f1410522403ac7c9f99be7a0d.image.webp)

最终的聚类结构就是（图源[hdbscan.readthedocs.io](https://hdbscan.readthedocs.io/en/latest/how_hdbscan_works.html)）
![image.png](/static/img/cc7418f0dbdcaafd1ca272dfd1013205.image.webp)