我们团队在内网部署了 Gitea 作为私有 Git 托管服务，跑在一台 Ubuntu 服务器上。代码不出内网，安全边界清晰，日常开发也没问题。

但随着远程办公和跨地域协作增多，痛点逐渐暴露出来：

1. 居家 / 出差时无法访问：人离开办公网后，Gitea 网页打不开，git 命令也连不上。想看看 PR 审批到哪了、最近提交改了什么，都得等到回公司再说。
2. 临时人员接入成本高：外包、短期项目同学，为了看一眼代码就要申请 VPN 权限，运维那边审批流程长，配置也麻烦。
3. 安全与效率的矛盾：直接把 Gitea 3000 端口映射到公网？肯定不行。代码仓库暴露公网，每天扫描器、撞库攻击不断，万一 Token 泄露就是整库风险。全员 VPN 呢？权限粒度太粗，运维负担也重。

试过几种方案，最后落地的是 MCP Server + 内网穿透 的组合，用了一段时间挺稳，分享出来供大家参考。二、方案选型与思路

2.1 核心思路转换

之前的思路是 "让人进内网"，所以要装 VPN、开权限。

后来

换了个方向： 不让人进内网，只把查询结果递出来。

具体来说，就是在内网服务器上跑一个 MCP 服务，它通过 Gitea API 去查仓库信息。然后通过内网穿透，给这个 MCP 服务开一个公网 HTTPS 入口。

外面的人只能通过这个入口做 API 级别的查询操作，碰不到 Gitea 服务本身，也直接 clone 不了仓库。

2.2 为什么选 MCP？

MCP（Model Context Protocol）是最近比较火的一种协议，主要是让 AI 工具（Cursor、Claude Code 这些）能够连接外部数据源。

Gitea 官方提供了 gitea-mcp Server，它的特点是：

• 走 REST API 层，不是直接暴露 Git 协议
• 攻击面小：即使入口暴露了，也只能做 API 级查询，不能直接拖库
• 配合 AI 工具，可以用自然语言查询仓库信息，效率高
• 轻量，部署简单

和直接暴露 Git 服务比，MCP 方案的暴露面小很多。毕竟你开放的是一个 "查询接口"，而不是整个代码仓库服务。

2.3 整体架构

外网开发机（Cursor）
    ↓ HTTPS / SSE
ZeroNews公网端点（带安全策略）
    ↓ 加密隧道
内网MCP Server（127.0.0.1:8004）
    ↓ 本地回环调用
内网Gitea API（127.0.0.1:3000）

几个关键设计点：

1. Gitea 不绑公网网卡：Gitea 只监听内网回环或内网网卡，不对公网开放
2. MCP 也只监听本机：mcp-proxy 绑的是 127.0.0.1，外部直接访问不了
3. 所有公网流量都走隧道：中间有 ZeroNews 的安全策略过滤
4. 全链路 HTTPS：公网传输加密

三、详细部署过程

3.1 环境说明

• 服务器：Ubuntu 22.04 LTS，内网环境
• Gitea 版本：1.21.x，已经在内网跑着了
• 内网穿透：ZeroNews 企业版
• 客户端：Cursor 编辑器

3.2 安装 ZeroNews 客户端

在 Gitea 所在的服务器上，安装 ZeroNews Linux 客户端：

curl
 -SLk https://download.zeronews.cc/linux/zeronews-install.sh 
| 
sudo 
sh
 -s 
install 
<
你的AuthToken
>

再以系统服务方式后台启动：

sudo zeronews service start

装完去控制台看一眼，客户端状态显示在线就 OK 了。

3.3 Gitea 生成访问令牌

登录 Gitea，进 设置 → 应用 → 生成新令牌。

权限这块要注意，遵循最小原则：

• 勾选 repository 的读权限
• 勾选 issue、 pull_request 的读权限
• 不需要写权限的话就别给，降低风险

生成后把 Token 复制下来，后面要用。

3.4 部署  Gitea  MCP Server

在 Ubuntu 上依次安装 Node.js（mcp-proxy）和 gitea-mcp 二进制：

sudo 
apt-get
 update


sudo 
apt-get 
install
 -y ca-certificates 
curl 
tar


 


# 1. Node.js 20.x


 


curl
 -fsSL https://deb.nodesource.com/setup_20.x 
| 
sudo
 -E 
bash
 -


sudo 
apt-get 
install
 -y nodejs


node -v 
&&
 npx -v


npx -y mcp-proxy --help


 


# 2. 官方 gitea-mcp


curl
 -fsSL -o /tmp/gitea-mcp.tgz 
\

 
"https://gitea.com/gitea/gitea-mcp/releases/download/v1.8.0/gitea-mcp_Linux_x86_64.tar.gz"


sudo 
tar
 -xzf /tmp/gitea-mcp.tgz -C /usr/local/bin gitea-mcp


sudo 
chmod
 +x /usr/local/bin/gitea-mcp


gitea-mcp --help

配置 Token 并以 HTTP（SSE）启动

安装完成后， 通过系统变量配置 Gitea Token 。

export 
GITEA_ACCESS_TOKEN
=
'你的只读Token'

利用 npx 启动 gitea-mcp ， gitea-mcp 通过 Gitea REST API 查询仓库、提交、分支、PR、Issue 等； mcp-proxy 在前端监听 8004 。

# 在 8004 端口暴露 gitea-mcp


npx -y mcp-proxy --host 
127.0
.0.1 --port 
8004
 -- 
\


  gitea-mcp -transport stdio -host http://127.0.0.1:3000

mcp-proxy 的 8004 都只监听本机：127.0.0.1。gitea-mcp 经回环地址调 Gitea API；Gitea 不必对公网或办公网其他网段开放 3000。

3.5 ZeroNews 配置隧道

登录 ZeroNews 控制台：

第一步：加自定义域名

在「自定义域名」页面加一个，比如 giteamcp.你的域名.com。

第二步：新建 HTTPS 隧道

在「隧道管理」里加一条隧道，参数大概是：

表格

隧道添加完成后，可通过 https:// giteamcp .hn.takin.cc/sse 连接 Gitea MCP。不要为看代码再单独映 Gitea Web 或 SSH。

3.6 安全策略配置

这步很重要，公网暴露一个入口，就得有防护。ZeroNews 自带了几层策略，建议都加上：

1. Basic 认证

开启隧道的 Basic Auth，设个用户名密码。所有连接都要先过这层验证。

2. IP 白名单

把公司出口 IP、员工常用的固定 IP 加进白名单。其他来源的 IP 直接拒掉。

这一步能挡掉绝大部分扫描器，因为大部分自动化扫描都是乱序 IP 来的。

3. 区域访问控制

如果员工 IP 经常变动，不好加白名单，可以开区域控制，只允许中国境内的 IP 访问。海外的直接挡掉，能过滤掉九成以上的无效流量。

3.7 Cursor 客户端配置

打开 Cursor，进 Settings → MCPs → New MCP Server，填配置：

{
  "mcpServers": {
    "giteamcp": {
      "url": "https://giteamcp.你的域名.com/sse",
      "type": "sse"
    }
  }
}

保存之后，看 MCP 列表里 giteamcp 是不是绿的，绿了就说明连上了。

四、实际使用效果

配好之后，日常查询就不用开 Gitea 网页了。直接在 Cursor 的 Agent 对话框里说就行：

• "列一下所有仓库"

• "order-service 的 main 分支最近 10 次提交，都是谁改的"

• "现在有多少个 open 的 PR"

• "基于 develop 分支建个 release-2.0.0 分支"

AI 会自动调 MCP 接口去查，然后把结果整理好给你。

对于只是看个提交、审个 PR 这种轻量场景，效率比开网页高多了。而且不用连 VPN，在家就能用。

五、踩过的几个坑

分享几个部署过程中遇到的问题，给大家提个醒：

1. MCP 服务一定要绑 127.0.0.1

一开始图省事，绑了 0.0.0.0，结果安全扫描直接扫到了 8004 端口。后来改成只监听回环地址，只走隧道，就没这个问题了。

2. Token 权限别给太大

一开始图方便，给了全权限。后来想想没必要，只读场景给读权限就够了。最小权限原则，降低泄露后的影响面。

3. IP 白名单要定期更新

员工家里 IP 变了、公司出口 IP 换了，都要及时更新白名单。不然用户连不上，还要来问。

4. 这方案不适合重操作

MCP 走的是 API，适合查询、轻量操作。你要是想 clone 整个仓库、大批量 push 代码，那还是得走内网或者正经的 Git 通道。这个方案就是解决 "轻量查询" 场景的，别指望它干所有事。

六、方案总结

最后总结一下，这套方案的优缺点：

优点：

• Gitea 本体不暴露公网，安全风险小
• 部署简单，半小时就能搞定
• 运维成本低，不需要维护 VPN 体系
• 用户体验好，自然语言查询，不用开网页

缺点：

• 只适合轻量查询场景，不适合重型 Git 操作
• 需要配合支持 MCP 的 AI 工具使用
• 公网入口还是要做好安全防护

适合的场景：

• 中小团队，没有专职运维搞 VPN
• 远程办公 / 居家协作需求多
• 外包 / 临时项目多，需要精细控制权限
• 对代码安全要求高，不想 Git 仓库暴露公网

整体用下来，对于我们这种小团队来说，这套方案在安全和效率之间平衡得还不错。至少解决了 "人在外网想看个代码状态" 的痛点，又没把 Gitea 直接扔公网上。

如果大家有类似的需求，可以参考这个思路。有问题欢迎评论区交流。