IT on 达蒙西的囚笼

Gitea 私有代码仓库快速部署

Wed, 22 Apr 2026 16:03:12 +0800

摘要: 基于真实踩坑案例，实现 1Panle 平台 + Gitea 私有仓库快速部署。

前情提要

前面文章中提到了 MCP server 快速部署案例。

其中有一种场景：用户自己开发了一个 mcp server 代码，希望运行在 1Panel 的MCP 组件中，而不是只能够在本地运行。

并且文章中提到，1Panel 中新增的 mcp server配置如下——

`1`	`/bin/sh -c "apk add git && uvx --from git+http://lab.nxlan.cn:3008/pdream/jobsearch-mcp-server.git jobsearch-mcp-server --transport stdio"`

上面用到代码仓库 http://lab.nxlan.cn:3008/pdream/jobsearch-mcp-server.git 就是本文主角——gitea 个人仓库。

一、Gitea 基础配置

延续1Panel 中特色功能：图形化部署+应用内部关联。

可以 2分钟快速实现 gitea 应用的部署，5分钟完成初始化，10分钟完成反向代理配置。

之后，就可以同步自己的代码到gitea 仓库中了。

感兴趣的话，不妨参考本文一步一步操作完成。

1.1 Gitea 应用创建

首先在 “应用商店” -> “全部” -> “搜索” 栏中输入 gitea 关键字，找到可以安装的应用。

注意点击第一个 Gitea “安装”。

如果 1Panel 中没有安装过数据库服务，会有需要安装数据库的提醒（如下图）——

如果是这种情况，就需要先安装数据库。

点击"去安装"后，直接跳转到数据库安装界面——

点击**“确认”** 按键，等待数据库安装完成。

如果点击"安装" 后，提示：“未开启外部映射，将无法从外外网访问数据库服务”。

可以根据自己需求，再勾选 “高级设置"中的 “端口外部访问"选项。

一般不建议 直接开放数据库服务到外部，所以我这里默认不启用此功能。

再次回到Gitea 安装界面，数据库服务可以选择刚创建好的postgres 了。

因为，稍后使用 ssh 协议同步代码，需要访问 gitea 的ssh 服务，这里需要勾选 “端口外部访问” 的选项。

点击"确认"后，就开始自动安装 gitea 应用了。

安装成功后，可以在应用商店中看到刚新增的两个应用——

1.2 追加反代配置

默认安装完成时，gitea 应用的web 服务绑定在宿主机的 3000端口。对应我的主机就是 http://lab.nxlan.cn:3000。

如果1Panel 在你的内部局域网，就可以直接访问上述页面，进行后续初始化工作。（可以跳过本段）

但是，如果gitea 宿主机在云上，又怎么能直接访问这个管理页面呢？

一种方式就是：追加反向代理配置，通过已经上线的https 服务，代理/gitea 流量到 http://127.0.0.1:3000 的真实服务。

还有一种方法是：登录到云主机管理页面，在安全策略下，追加一条——放行公网访问主机 3000 端口的策略。

考虑到：这样临时放行后，还是要取消并开通反代，我就没有这么操作。

操作步骤上，还是先进入**“网站” -> “反向代理” -> “创建”**，创建一条新代理规则，请求路径假设就是 /gitea。

并在原始代理配置文件内容基础上追加——

location ^~ /gitea {
    # 追加配置：去掉 /gitea 前缀，发给后端
    rewrite ^/gitea(/.*)$ $1 break; 

    # --- 默认设置 ---
    proxy_pass http://127.0.0.1:3000; 
    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 REMOTE-HOST $remote_addr; 
    proxy_set_header Upgrade $http_upgrade; 
    proxy_set_header Connection $http_connection; 
    proxy_set_header X-Forwarded-Proto $scheme; 
    proxy_set_header X-Forwarded-Port $server_port; 
    proxy_http_version 1.1; 
    add_header X-Cache $upstream_cache_status; 
    proxy_ssl_server_name off; 
    proxy_ssl_name $proxy_host; 
}

保存反代配置后，进入gitea 配置文件目录——/opt/1panel/apps/gitea/gitea/data/gitea/conf

修改配置文件app.ini中的一条配置：

[server]
APP_DATA_PATH = /data/gitea
DOMAIN = localhost
SSH_DOMAIN = localhost
HTTP_PORT = 3000
# 修改为自己外部域名和代理接口
ROOT_URL = https://lab.nxlan.cn/gitea/
DISABLE_SSH = false
SSH_PORT = 22
SSH_LISTEN_PORT = 22
LFS_START_SERVER = false

修改好后，重启gitea 应用新配置。再次访问反代地址—— https://lab.nxlan.cn/gitea，就可以看到初始化配置页面了。

1.3 完成应用初始化

在上述初始化页面中，1Panel 已经帮我们补充好了数据库地址、名称、用户、密码等信息。

这里保持默认，点击 “立即安装” 完成最后的初始化工作。

最后，完成管理员账户的设置——

管理账户创建后，重新登录。

1.4 同步代码至仓库

同步本地写好的代码前，需要先在 Gitea 上创建仓库。

我们的第一个代码仓库，名字就叫 “jobsearch-mcp-server”。

为了方便mcp server 拉取项目代码，项目可见性不勾选 “将仓库设为私有”——也就是公开的意思。

其他保持默认，这样我们第一个代码仓库就创建完成了。

仓库创建完后，需要追加个人应用访问令牌——方便开发主机同步代码。

在 “个人信息” -> “应用” -> “生成新的令牌” 中输入令牌名称，并追加repository 等读写的权限。

添加成功后，会出现一行令牌字符串，类似于——a385cac305f80ff43dfe202d727b5a33176d18b3

在开发主机上，按照以下命令顺序执行，同步代码到gitea 仓库：

# git 项目初始化
git init

# 查看当前 remote
git remote -v

# 删除过往 remote
git remote remove origin

# 追加
git remote add origin https://pdream:[TOKEN]@lab.nxlan.cn/gitea/pdream/jobsearch-mcp-server.git

# 推送本地代码到仓库
git push --set-upstream origin master
Enumerating objects: 52, done.
Counting objects: 100% (52/52), done.
Delta compression using up to 4 threads
Compressing objects: 100% (42/42), done.
Writing objects: 100% (52/52), 100.22 KiB | 5.90 MiB/s, done.
Total 52 (delta 19), reused 0 (delta 0), pack-reused 0
remote: . Processing 1 references
remote: Processed 1 references in total
To https://lab.nxlan.cn/gitea/pdream/jobsearch-mcp-server.git
 * [new branch]      master -> master
branch 'master' set up to track 'origin/master'.

提示同步成功。此时访问仓库页面，就可以看到刚上传的代码了。

二、1Panel MCP Server 部署（从 Gitea 拉取）

2.1 场景

在 1Panel 上通过 MCP 管理界面部署 MCP Server时，因为源代码在个人 Gitea上，所以在MCP server 启动要指定git项目地址。

2.2 正确启动命令

经过反代服务器（推荐）：

`1`	`/bin/sh -c "apk add git && uvx --from git+https://lab.nxlan.cn/gitea/pdream/jobsearch-mcp-server jobsearch-mcp-server --transport stdio"`

直连 Gitea（不经反代，数据未加密）：

`1`	`/bin/sh -c "apk add git && uvx --from git+http://lab.nxlan.cn:3000/pdream/jobsearch-mcp-server.git jobsearch-mcp-server --transport stdio"`

参数说明：

--transport stdio — 1Panel MCP 托管必须使用 stdio 传输模式（解决 SSE 嵌套冲突）

2.3 注意事项

路径格式：git+https:// 而非本地路径，容器内无法访问宿主机文件系统
传输模式：必须加 --transport stdio，否则与 1Panel MCP 托管机制冲突
反代 vs 直连：经反代走 443 端口（SSL 由反代终止），直连走 3000 数据不经加密传输（服务直接暴露在公网）。
环境变量：在jobserch 这个 MCP Server 项目中需要声明环境变量 “DEEPSEEK_API_KEY”，否则提示 OPENAI_API_KEY 未配置。

三、补充：使用ssh方式同步代码

前提：

Gitea 应用创建时，勾选了 “端口外部访问” 的选项。

3.1 SSH Key 生成

开发主机密钥生成：

ssh-keygen -t ed25519 -C "your_email@xx.com"
# 输出：
#   id_ed25519      (私钥)
#   id_ed25519.pub  (公钥)

添加主机的ssh key到 Gitea：

# 查看公钥
cat ~/.ssh/id_ed25519.pub
# 复制内容 → Gitea Web UI → 用户设置 → SSH 密钥 → 添加

# 验证连通性
ssh -p 222 git@lab.nxlan.cn -T
# 预期：Welcome to Gitea!

仓库 ssh 密钥截图：

3.2 修改git remote 配置

# 删除之前的 remote
git remote remove origin

# 将 之前配置的 HTTPS 改为 SSH（注意端口 222）
git remote set-url origin ssh://git@lab.nxlan.cn:222/pdream/jobsearch-mcp-server.git

# 验证
git remote -v

3.3 HTTP 与 SSH 的分工

通道	用途	使用场景
HTTP（S）	拉取源代码	MCP Server 容器内 `uvx --from git+https://...` 从 Gitea 拉代码
HTTP（S）	上传源代码	本地编辑完成后 `git push` 将代码同步回 Gitea。此时origin为： https://pdream:[TOKEN]@lab.nxlan.cn/gitea/pdream/jobsearch-mcp-server.git
SSH	上传源代码	本地编辑完成后 `git push` 将代码同步回 Gitea 。此时origin为： ssh://git@lab.nxlan.cn:222/pdream/jobsearch-mcp-server.git

本例实战：

MCP Server 部署：容器通过 HTTPS 拉取 jobsearch-mcp-server 源码
代码编辑后推送：本地也通过 HTTPS 方式 ( https://pdream:[TOKEN]@lab.nxlan.cn/...) 提交到 Gitea

两者各司其职，不冲突。

四、mcp server 排错速查

症状	原因	解法
`uvx --from /path/to/repo` 报错	容器内无法访问宿主机路径	改用 `git+https://`
`git clone` 卡住/超时	容器网络不通或缺 git	`apk add git`，检查网络
`SSL certificate problem`	自签证书	`git config --global http.sslVerify false`
容器启动后立刻退出	缺环境变量	检查 `OPENAI_API_KEY` 等必填变量
SSH 克隆认证失败	端口非 22	确认 Gitea SSH 端口为 222

五、Principle（经验规则）

supergateway 容器内操作默认缺 git，先用 apk add git 兜底
MCP server 启动命令只支持单字段，用 /bin/sh -c 串联多条指令
使用 HTTPS 服务推送源代码时，注意令牌权限要给够，否则会报告 403 的错误
Gitea SSH 端口映射为 222，配置 remote 时需注意指定端口

手把手初始化GCP云主机并快速完成MCP Server的配置

Wed, 08 Apr 2026 11:13:01 +0800

前情提要

之前发布的文章：“手把手带你薅 Gemini 付费 API 与 Google 免费服务器” 被人投诉下架了。

这里把文章链接放出来，感兴趣的同学可以去薅一下——

前提：需要先开通自己帐号的 google pro服务

详细步骤：https://blog.cba.nxlan.cn/p/setup_gemini_api

具体怎么开通、初始化机器、登录的过程，上面文章中已经说得很清楚了。

只是还剩下一个任务，也就是本文的主题：

使用1Panel 申请https 免费证书，搭建MCP server 供Agent使用。

肝了两天，文章有点长，觉得好用点个赞呗。

步骤概要

强化防火墙策略
ddns-go 组件安装
1panel 安全配置优化 (启用ACME证书注册 )
启用 MCP server
反向代理服务配置
可以一键安装“龙虾” ^.^ （也是我推荐的方式）

Step0 强化防火墙策略

系统初始化后。VPC上默认放行了 ssh http https 这些服务端口。

具体到OS层面，熟悉Linux 的同学知道，默认INPUT 方向的策略是全部放行的——

1
2
3

> iptables -nvL INPUT
Chain INPUT (policy ACCEPT 85401 packets, 12M bytes)
 pkts bytes target     prot opt in     out     source               destination

这就导致一个什么问题呢？

ssh 服务经常被暴力攻击——

所以，系统初始化后，第一步是更新系统组件： apt update & apt upgrade 。

第二步就应该是 加固ssh 服务——避免被外部暴力破解。

这里，使用了iptables 的 “recent"模块，去动态创建&更新一个叫做"openssh"的白名单库。

实现只有白名单库里的公网IP 可以访问这台 Ubuntu的ssh服务，进一步说：只有这些白名单地址所在的地址

1. 创建iptabls 策略脚本

> cat /usr/local/sbin/Protect_SSH_port.sh 
#!/bin/bash
#
# set iptables input rules for protecting ssh port service
# This script is intended to be run by root via a systemd service.

# Flush ONLY the INPUT chain rules to ensure a clean state before applying new ones.
/sbin/iptables -F INPUT

# Set rules
/sbin/iptables -I INPUT 1 -p tcp -m state --state RELATED,ESTABLISHED -j ACCEPT
# option： 放行Google IDC的跳板登录
/sbin/iptables -I INPUT 2 -s 34.81.160.0/24 -p tcp --dport 22 -j ACCEPT
/sbin/iptables -I INPUT 3 -p icmp --icmp-type 8 -m length --length 879 -j LOG --log-prefix 'SSH_OPEN_KEY'
/sbin/iptables -I INPUT 4 -p icmp --icmp-type 8 -m length --length 879 -m recent --name openssh --set --rsource -j ACCEPT
/sbin/iptables -I INPUT 5 -p tcp --dport 22 --syn -m recent --name openssh --rcheck --seconds 60 --rsource -j ACCEPT
/sbin/iptables -I INPUT 6 -p tcp --dport 22 -j DROP
/sbin/iptables -A INPUT -p icmp -j DROP

2. 创建 protect-ssh 服务，设置开机运行

> cat /etc/systemd/system/protect-ssh.service 
[Unit]
Description=Apply custom iptables rules to protect SSH port
After=network.target

[Service]
Type=oneshot
RemainAfterExit=yes

ExecStart=/usr/local/sbin/Protect_SSH_port.sh

# 当服务停止时，只清空 INPUT 链的规则
ExecStop=/sbin/iptables -F INPUT

[Install]
WantedBy=multi-user.target

启动并查看服务状态——

> systemctl enable protect-ssh
> systemctl restart protect-ssh
> systemctl status protect-ssh
● protect-ssh.service - Apply custom iptables rules to protect SSH port
     Loaded: loaded (/etc/systemd/system/protect-ssh.service; enabled; preset: enabled)
     Active: active (exited) since Thu 2026-03-09 16:43:15 CST; 7s ago
    Process: 141811 ExecStart=/usr/local/sbin/Protect_SSH_port.sh (code=exited, status=0/SUCCESS)
   Main PID: 141811 (code=exited, status=0/SUCCESS)
        CPU: 42ms

3. 效果展示

陌生用户，默认没有登录令牌。

连ssh 会话都建立不起来——

知道登录令牌，先“敲门”登记一下——

这里有个计算公式：

因为： ICMP令牌长度 = Packetsize + ICMP 头部 [ 8 字节 ] + IP 头部 [ 20 字节 ]

所以：packetsize [ 敲门令牌 ] = ICMP令牌长度 [ 这里是879 ] - 8 - 20 = 851 字节

ping通主机后，才可以正常登录——

这样就可以避免：主机被陌生人/主机探测、破解的可能。

部署后，再也没有陌生人的登录记录。

Step1 ddns-go 组件安装

因为云主机的固定IP是收费的，为了减少支出，在云主机创建时外部IP是临时的。

外部IP地址不固定就带来一个问题——某天google 给主机更换外部IP 后，域名访问就失效了。

除非人工重新进入 GCP 控制页面，查看新的IP，再手动重新映射域名。

有没有简单的办法解决这个问题呢？有的，兄弟，有的！

解决办法就是常听到的ddns 服务——通过一个探测脚本，定时去更新域名和IP映射关系。

所以，下面以ddns-go 组件为例，在这台ubuntu 上完成域名自动映射服务。

1. 下载ddns-go 源码，创建应用目录

先下载源码——

> cd /tmp/
wget https://github.com/jeessy2/ddns-go/releases/download/v6.16.5/ddns-go_6.16.5_linux_x86_64.tar.gz
tar -zxvf ddns-go_6.16.5_linux_x86_64.tar.gz 

> /tmp# ./ddns-go -v
v6.16.5

创建应用目录和空的配置文件——

1
2
3

mkdir -p /usr/local/bin/ddns-go
touch /usr/local/bin/ddns-go/ddns_go_config.yaml
cp /tmp/ddns-go /usr/local/bin/ddns-go/

2. 导入配置文件

ddns-go配置文件模板如下。

注意更新 ddns账户的域名和 TOKEN（这里以CloudFlare 上的DNS 服务为例）

# cat /usr/local/bin/ddns-go/ddns_go_config.yaml 
dnsconf:
    - name: cloudflare
      ipv4:
        enable: true
        gettype: url
        url: https://checkip.synology.com, https://ddns.oray.com/checkip, https://ip.3322.net,
        netinterface: ens4
        cmd: ""
        domains:
            - YOUR-DOMAIN-NAME
      ipv6:
        enable: false
        gettype: url
        url: https://speed.neu6.edu.cn/getIP.php, https://v6.ident.me, https://6.ipw.cn
        netinterface: ""
        cmd: ""
        ipv6reg: ""
        domains:
            - ""
      dns:
        name: cloudflare
        id: ""
        secret: YOUR-DDNS-TOKEN
        extparam: ""
      ttl: ""
user:
    username: YOURNAME
    password: YOURPASS
webhook:
    webhookurl: YOUR-FEISHU-WEBHOOK
    webhookrequestbody: |-
        {
            "msg_type": "post",
            "content": {
                "post": {
                    "zh_cn": {
                        "title": "您的谷歌云主机公网IP变了",
                        "content": [
                            [
                                {
                                    "tag": "text",
                                    "text": "新的IPv4地址：#{ipv4Addr}"
                                }
                            ],
                            [
                                {
                                    "tag": "text",
                                    "text": "域名更新结果：#{ipv4Result}"
                                }
                            ]
                        ]
                    }
                }
            }
        }
    webhookheaders: 'Content-Type: application/json'
notallowwanaccess: false
lang: zh

3. 创建ddns-go 服务，设置开机运行

和之前一样，为ddns-go 应用创建一个系统服务。

路径和上面一致的话，复制粘贴就好。

# cat /etc/systemd/system/ddns-go.service 
[Unit]
Description=Simple and easy to use DDNS. Automatically update domain name resolution to public IP (Support Aliyun, Tencent Cloud, Dnspod, Cloudflare, Callback, Huawei Cloud, Baidu Cloud, Porkbun, GoDaddy...)
ConditionFileIsExecutable=/usr/local/bin/ddns-go/ddns-go
Requires=network.target  
After=network-online.target 

[Service]
StartLimitInterval=5
StartLimitBurst=10
ExecStart=/usr/local/bin/ddns-go/ddns-go "-l" "127.0.0.1:9876" "-f" "300" "-cacheTimes" "5" "-c" "/usr/local/bin/ddns-go/ddns_go_config.yaml"
Restart=always
RestartSec=120

[Install]
WantedBy=multi-user.target

然后，启动服务——

1
2
3

> systemctl enable ddns-go 
> systemctl start ddns-go 
> systemctl status ddns-go

可以看到类似日志： Apr 1 11:47:22 systemd[1]: Started ddns-go.service - Simple and easy to use DDNS. Automatically update domain name resol> Apr 1 11:47:22 ddns-go[242234]: 2026/04/15 11:47:22 监听 127.0.0.1:9876 Apr 1 11:47:22 ddns-go[242234]: 2026/04/15 11:47:22 你的IP 35.212.158.199 没有变化, 域名 cloud.nxlan.cn

4. 效果展示

当云主机 IP 地址变化，会通知到feishu 中。

因为，目前ddns-go的web 管理页面只开放在本地的 127.0.0.1:9876上，目前还不能通过web 方式去配置、修改它。

等到 Step4 中的https 反向代理服务配置好后，就可以通过web 界面去管理了。（服务支持的 DDNS 厂商还是很多的，根据自己情况选择吧）

Step2 1panel 安全配置优化

1. 加固ssh 登录

1Panel的一个好处是：通过web 界面图形化地查看系统日志、设置系统基础配置。

例如，这里的ssh 服务。

进入**“系统” -> “SSH 管理”**页面。

关闭密码认证和反向解析。并且设置root用户“ 仅允许密钥登录 ”。

如果对Linux系统比较熟悉，建议将root 用户的登录也关闭掉。

登录时使用 google 创建云主机时自动创建的普通用户帐号和密钥就行。

此时只需将密钥公钥信息添加到家目录的authorized_keys文件中就行。

~# cat /home/YOURUSER/.ssh/authorized_keys ecdsa-sha2-nistp256 AAAA…..

然后，点击页面中的“密钥信息”，1Panel会自动创建一组登录密钥用于root 用户登录。

进一步，点击“详情”。把公钥和私钥信息全部“下载”下来。用于本地 ssh 客户端登录这台Google Cloud主机。

点击“授权密钥”，可以看到密钥信息已经加载到 root 用户的ssh 白名单（就是 /root/.ssh/authorized_keys）中了。

配合上一步的ddns 动态域名，使用ssh 客户端就可以顺利以root 用户身份登录这台云主机了。

2. 申请 ACME 证书

其实也就是申请 “Let’s Encrypt” 颁发的免费证书，并自动续签。

想必你也不希望自己的数据“裸奔”在不可信的互联网上。

首先来到**“网站” -> “证书”** 页面。

点击“DNS 账户”，关联自己的 DNS 域名和TOKEN。

“类型” 这里与之前ddns-go 域名设置中的域名服务商保持一致——CloudFlare。

点击 “ACME 账户”，创建一个Let’s Encrypt账户，邮箱输入自己常用的就行。

最后，点击"申请证书”，完成自动化证书申请和更新的配置。

注意，“验证方式"为刚才创建的DNS 帐号，并勾选"自动续签”。这样免费证书到期后，也不用人工干预，就可以自动续续订证书。

申请过程需要等1分钟左右，日志可以查看进度和完成情况——

拿到证书，后续就可以用在很多地方，例如下面的 1Panel 管理页面。

3. 1panel 管理页面加固

来到 “面板设置” -> “安全” 页面。

绑定自己域名，并开启 “面板 SSL”。开启后，1Panel 管理页面会关联之前申请到的 ACME 证书。（如下图中的效果）

同时最好开启两步验证，进一步加强登录安全。

开启两步验证后的效果——

Step3 启用 MCP server

1. MCP server 初始配置

首先来到 “AI” -> “MCP” -> “Servers” 。

我们知道，MCP 下层用的是HTTP 协议，为了不直接将MCP server 暴露在外网，需要先安装 HTTP 反向代理服务。

进入"应用商店" -> 筛选"web 服务器"标签，安装 OpenResty。

该应用和后面提到的每一个独立的 MCP server，本质上都是以docker 方式运行的运行时。

关于OpenResty 的简单介绍——

2. 绑定网站

选中 “MCP"页面中的"绑定网站”——

“域名”还是输入 ddns-go 那用到的自己域名。

再次关联之前通过 ACME 拿到的证书。

相同的证书，用在不同的服务上：

之前是用于1Panel管理页面的登录（非443端口），这次是用于标准443 端口上全部https服务的反向代理。

反代类似于在客户端和真实服务间加了一层垫片。它的好处是：

缩小被攻击的范围；2. 隔离不同服务；3. 内部服务不用重复申请证书；4. 统一访问日志，可追加安全控制策略。

3. 创建第一个MCP 服务

我们先创建一个常用的MCP 服务——sequential-thinking。

它可以为大模型对话，提供多轮思考的上下文内容。

“类型“选择 npx。 “启动命令“中填入——

`1`	`npx -y @modelcontextprotocol/server-sequential-thinking`

如果不使用HTTP 反向代理服务，这里就应该允许"端口外部访问”。

因为之前已经启用了 OpenResty ，访问这个 MCP server 的请求，都会经反向代理转给真实服务。

这里真实服务端口（8002）自然也不用暴露到外网。

上面"SSE 路径"就是 MCP server 的服务路径。

来到 “网站” -> “HTTPS 域名” -> “反向代理” 中可以看到，1Panel 自动为MCP 服务追加了一条反向代理配置。（下图第二条）

此时，测试一下这个MCP server 地址——

服务正常响应了。

“网站日志"中也可以看到访问记录。

怎么样是不是很简单？分分钟一个 MCP server 服务就启动和上线了。

后续文章中，也会提到这个 thinking 工具的使用案例。

4. 运行自己的MCP 源码

上面的方式，本质是把他人写好并打包发布 的 MCP server代码拉取到 1Panel 的supergateway 容器中运行。

那能不能把自己写好的服务，也跑在1Panel 上呢？例如之前文章 MCP 案例：求职助手中的代码。

这就相当于有一个 7＊24 的服务跑在云主机上，不用每次运行MCP server时输入那一长串启动命令——

`1`	`uv --directory S:\trae_pj\jobsearch_mcp_server-1.0.0\src\jobsearch_mcp_server run jobsearch-mcp-server`

说干就干。

测试下，来可以通过 git 拉取项目源代码到1Panel 的supergateway 容器中，并以 uvx 方式更新并运行我们自己的代码。

效果如下。

1Panel 配置方面不复杂，一页图就能看明白——

“类型” 选择uvx，“启动命令"就这么一行。

`1`	`/bin/sh -c "apk add git && uvx --from git+http://lab.nxlan.cn:3008/pdream/jobsearch-mcp-server.git jobsearch-mcp-server --transport stdio"`

这里使用了 gitea 的 docker版本，用于管理项目代码。它可以兼容 git 命令。

并且页面也类似于 github 的效果，属于轻量化的本地部署方案，回头有机会再讲讲这块的搭建和设置。

为什么说 uvx 可以刷新最新代码呢？看下日志就会发现，它每次重启都会从gitea 上同步下源码。

这样每次改好源码，在"AI” -> “MCP” -> “Servers” 下重启jobsearch 这个应用，就自动完成了更新和发布。

Step4 反向代理服务配置

1. 自动创建的反代服务

在 “网站” -> “HTTPS 域名” -> “反向代理” 中可以看到：

之前启用mcp server 时，1Panel 自动帮我们创建好的两个反向代理配置。

具体配置长啥样呢？点击 “源文” 就可以看到详细配置。这里以 jobsearch 这个服务为例——

location ^~ /jobsearch {
    proxy_pass http://127.0.0.1:8005/jobsearch; 
    proxy_buffering off; 
    proxy_http_version 1.1; 
    proxy_set_header Connection ''; 
    chunked_transfer_encoding off; 
}

简单地说就是，当客户端浏览器访问站点 (https://lab.nxlan.cn) 时，反向代理服务会根据客户端请求的路径进行请求转发。例如这里: 当匹配客户请求含有 “/jobsearch” 就转发至 “http://127.0.0.1:8005/jobsearch”。

同理，当匹配客户请求含有 “/sequential-thinking” 就转发至 “http://127.0.0.1:8000/sequential-thinking”。

1Panel自动创建的代理设置是简单场景下的配置，没问题就不用手动修改。

可是，还有些特殊的web 应用，就不能使用默认的配置。

2. ddns-go 的反代配置

本文涉及需要手动修改的配置，有两个——

一个是前面安装的 ddns-go, 它也是有web 管理界面的。
还有一个就是 OpenClaw 小龙虾了。

先看ddns-go 的——


location ^~ /ddns {
    # 1. 请求时：去掉 /ddns 前缀，发给后端
    rewrite ^/ddns(/.*)$ $1 break; 
    # 2. 响应时：如果后端想重定向到 /，就把它修正为 /ddns/
    # 这条规则能修正所有类似 /login -> /ddns/login 的重定向
    proxy_redirect / /ddns/; 
    
    # --- 其他代理设置 ---
    proxy_pass http://127.0.0.1:9876; 
    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; 
    add_header Cache-Control no-cache; 
    proxy_ssl_server_name off; 
}

如果在原始服务中写死了请求 url ，所以当用户发起这种请求到达代理服务时，会破坏默认的转发规则。

此时，需要改写用户请求。——ddns-go 就是这样的例子。

正常的请求：

用户请求网页 https://lab.nxlan.cn/ddns –> 反代 –>原始服务 http://127.0.0.1:9876

异常的请求：（因为 ddns-go 的登录页面路径为 /login）

用户请求网页 https://lab.nxlan.cn/login –> 反代 –> ？？？这是什么玩意我这没有这个规则

修正规则后的请求：

用户请求网页 https://lab.nxlan.cn/login –> 反代 –> 规则重定向到 https://lab.nxlan.cn/ddns/login –> 反代发现匹配现有/ddns 路由的规则 –> 原始服务 http://127.0.0.1:9876/login

策略应用后，客户端看到的页面效果就是——

3. OpenClaw 的反代配置

OpenClaw 则是另一种情况：

从安全性的角度考量，建议开启gateway 中的 “allowedOrigins” 校验。

"gateway": {
    "port": 18789,
    "mode": "local",
    "bind": "lan",
    "controlUi": {
      "allowedOrigins": [
        "https://lab.nxlan.cn",
        "http://127.0.0.1:18789",
        "http://localhost:18789"
      ],
      "dangerouslyAllowHostHeaderOriginFallback": false,
      "dangerouslyDisableDeviceAuth": false
    },
    "auth": {
      "mode": "token",
      "token": "${OPENCLAW_GATEWAY_TOKEN}",
    }
}

该校验内容来自哪里呢？

需要在代理服务器上追加这部分请求信息，由"X-Forwarded-Proto"和 “X-Forwarded-For” 字段组成。

location ^~ / {
    proxy_pass http://127.0.0.1:18789; 
    proxy_http_version 1.1; 
    proxy_set_header Upgrade $http_upgrade; 
    proxy_set_header Connection "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; 
    proxy_read_timeout 3600; 
    proxy_send_timeout 3600; 
    proxy_ssl_server_name off; 
    proxy_ssl_name $proxy_host; 
}

此外还需要追加 OpenClaw 用到的 WebSocket 的支持。

后续，其他应用，也可以参考这两种方式灵活调整。毕竟，谁还没有一两个 AI 助手呢？

Step5 一键安装“龙虾”

龙虾最近不是很火么，恰好最近1Panel 丰富了龙虾安装配置，这里简单提一下。

1. 管理模型

“AI” -> “模型” -> “模型帐号” 中关联自己的大模型API 帐号。

2. 创建配置

基础配置图形化点击就可以快速完成。

3. 下载官方通信插件

图形化功能适配，还比较方便，这里以飞书为例。

当然，复杂的配置还是得修改 openclaw.json 这个主配置文件。

4. 血泪史

OpenClaw的配置文件是核心，但是它的接口适配做得很难用。

每一项优化起来太麻烦了——

目前最让我记忆深刻的有两点：

我是在使用小龙虾两个星期后，才知道 feishu 通信渠道插件有两个（一个是 openclaw 社区的，一个是feishu 自己的）；
每次 OpenClaw 版本大更新后配置文件的格式就变得乱七八糟，有的配置之前和现在完全不一样——毫无友好性。

如果为了修复升级后的配置问题，大概要花上半天时间继续调试它。

目前 1Panel 官方维护一套他们根据 OpenClaw 发布后自动打包的 docker 镜像。

https://hub.docker.com/r/1panel/openclaw

所以，有需要的话还是找成功的案例去复制一下吧，自己折腾还是太折磨了。

最后，祝AI 时代每个人不用更焦虑，做自己的主人，而不是交给AI 做主。

生产环境“删库”救命指南：NAS + vSphere 下的虚拟机数据恢复实操记录

Mon, 16 Mar 2026 01:06:45 +0800

声明：本文为真实操作记录，旨在为运维同学在面对“数据误删”或“虚机崩溃”时提供一套经过验证的恢复路径。

核心金律：操作千万条，备份第一条；挂载新签名，数据不破坏。

一、场景回溯：灾难发生的第 0 小时

最近使用1panel(v2版本)时遇到个坑：如果“网站” 创建时指定了app 应用，在删除“网站”时不留意会顺带把应用一起删除（见下图）。。

我刚养了两天的龙虾(OpenClaw) 数据，全没了。。。呜呜呜~~

而且本来就在调试，相关应用备份我是一点没准备好。这数据重新弄可老麻烦了（里面还有它刚给我调试好的 Agent web 页面）。

冷静下来，思索的第一件事是：我有没有快照？能恢复数据不？

因为我是在虚拟机上安装的1panel和OpenClaw：

系统备份是4天前的——还原了也用不了
存储上整个iSCSI的块存储（Lun）倒是每天有一个快照——全部还原意味着 8-9台虚拟机的数据也一并还原了。。。

这可咋办？

最后，在服务不停机的情况下，使用这个快照将应用（OpenClaw）数据恢复到了前一天的状态。

先介绍下我的测试环境：

存储端：NAS (Btrfs 文件系统，开启了快照功能)
计算端：VMware vSphere (ESXi 宿主机)
协议：iSCSI

二、灾难发生的第 1小时：召回“丢失的世界”

不要直接在原始快照上操作，最稳妥的方法是克隆一个临时的 LUN。

快照定位：在 NAS 管理后台（如 SAN 管理器）找到最近一个完好的快照。
克隆 LUN：基于快照克隆出一份数据卷（例如命名为 LUN-Recover-Temp）。
暴露目标：新增一个 iSCSI 目标（给个名字：recovery），并与刚才的克隆 LUN -1关联上。

为了方便后续挂载，新建iSCSI Target 中的“多重联机”可以开启。
- 注意：并确保LUN 策略中放行了 ESXi 宿主机的 IQN。

三、灾难发生的第 2小时：安全访问克隆数据

这是最惊险的一步，选错选项可能导致克隆卷的数据结构被清空。

1. 扫描与识别

进入 vCenter -> 主机配置 -> 存储适配器，选择你的 iSCSI 适配器点击 “重新扫描存储”。此时在“设备”列表中应能看到那个克隆出来容量一致的新磁盘。状态是未挂载。

2. 挂载数据存储（关键！）

点击“新建数据存储”，选择 VMFS 类型，选中那个克隆出来的 LUN。此时向导会弹出 “解析选项”，请屏住呼吸选择：

❌ 保留现有签名 (Keep Existing Signature)
- 不选理由：这会保留原始的 UUID。vSphere 会识别出这是一个已有的 VMFS 卷，会覆盖现有挂载。
- 误选后果：导致其他未受影响的虚拟机数据，一并还原至前一天的状态。——这不是我们希望的。
✅ 分配新签名 (Assign a new signature)：这通常用于想同时挂载原始和快照卷的情况，会导致虚拟机路径变化，不推荐。
- 选择理由：当前环境，不希望停止正在运行的虚拟机，只希望把克隆盘中，昨天这台虚拟机中 OpenClaw 的应用数据导出来就行。
❌ 格式化磁盘 (Format the disk)：点下去你就彻底告别数据了。

成功挂在后，可以看到一个新的“数据存储”，点击存储中“文件”可以看到前一天整个虚拟机的数据。

四、虚拟机内部：抢救数据

挂载成功后，浏览数据存储，你会看到“死而复生”的 .vmx 和 .vmdk 文件。到这一步可以说：已经成功一半了。

注册虚拟机：右键点击恢复出来的 .vmx 文件 -> 注册虚拟机。
启动：
- 启动恢复的虚机：此时可能会提示“I Moved It”或“I Copied It”，选择 “I Copied It” 以新运行一台昨天状态的机器。
- 断网/改 IP：进系统后，第一时间修改主机 IP 地址，防止与生产环境冲突。
  
  因为这里是Linux主机，我就直接用到 nmtui命令快速修改新机器的IP 地址了。
数据导出与回填：
- 因为应用是在 1Panel 下运行的 Docker 服务。
- 只需登录进新主机的1Panel管理界面，备份现有应用的应用数据即可。
- 随后，下载刚才打包好的备份数据。
- 返回登录数据丢失的主机：在 1Panel 中保持 Docker 应用名一致 的情况下，重新导入刚才这个备份数据——
服务启动：
- 随后，服务重新启动。此时除了服务Tokens 和之前的不一样以外，其他的配置文件，本地记录文件，飞书客户端对接地址。。。都是一样的。
至此，应用就成功恢复了。

数据还原成功后，克隆虚拟机和克隆卷也就不用了，可以相反的操作回到之前的状态：

选择“删除虚拟机” –> “删除数据存储“ –> 删除iSCSI target –> 删除克隆Lun 即可。

五、最后的复盘

快照就是生命线：如果你还没在 NAS 上开启定期快照，现在就去点开它。哪怕每天一个快照也行。
1Panel 的优越性：在这种场景下，Docker 应用的备份、还原比直接恢复整台虚机要快得多，也更灵活。
冷静是第一生产力：NAS 和 VMware 都是多重保护的，只要不误点“格式化”或“保留原有标签”，数据总能找回来。

IT on 达蒙西的囚笼

Gitea 私有代码仓库快速部署

前情提要

一、Gitea 基础配置

1.1 Gitea 应用创建

1.2 追加反代配置

1.3 完成应用初始化

1.4 同步代码至仓库

二、1Panel MCP Server 部署（从 Gitea 拉取）

2.1 场景

2.2 正确启动命令

2.3 注意事项

三、补充 ：使用ssh方式同步代码

3.1 SSH Key 生成

3.2 修改git remote 配置

3.3 HTTP 与 SSH 的分工

四、mcp server 排错速查

五、Principle（经验规则）

手把手初始化GCP云主机并快速完成MCP Server的配置

前情提要

步骤概要

Step0 强化防火墙策略

1. 创建iptabls 策略脚本

2. 创建 protect-ssh 服务，设置开机运行

3. 效果展示

Step1 ddns-go 组件安装

1. 下载ddns-go 源码，创建应用目录

2. 导入配置文件

3. 创建ddns-go 服务，设置开机运行

4. 效果展示

Step2 1panel 安全配置优化

1. 加固ssh 登录

2. 申请 ACME 证书

3. 1panel 管理页面加固

Step3 启用 MCP server

1. MCP server 初始配置

2. 绑定网站

3. 创建第一个MCP 服务

4. 运行自己的MCP 源码

Step4 反向代理服务配置

1. 自动创建的反代服务

2. ddns-go 的反代配置

3. OpenClaw 的反代配置

Step5 一键安装“龙虾”

1. 管理模型

2. 创建配置

3. 下载官方通信插件

4. 血泪史

生产环境“删库”救命指南：NAS + vSphere 下的虚拟机数据恢复实操记录

一、 场景回溯：灾难发生的第 0 小时

二、 灾难发生的第 1小时：召回“丢失的世界”

三、 灾难发生的第 2小时：安全访问克隆数据

1. 扫描与识别

2. 挂载数据存储（关键！）

四、 虚拟机内部：抢救数据

五、 最后的复盘

三、补充：使用ssh方式同步代码

一、场景回溯：灾难发生的第 0 小时

二、灾难发生的第 1小时：召回“丢失的世界”

三、灾难发生的第 2小时：安全访问克隆数据

四、虚拟机内部：抢救数据

五、最后的复盘