反向代理与 Tunnel

Nginx 示例

假设 Lite 只在本机 127.0.0.1:27777 提供 HTTP：

server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate     /etc/nginx/certs/fullchain.pem;
    ssl_certificate_key /etc/nginx/certs/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:27777;
        proxy_set_header Host $http_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_set_header Origin $http_origin;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_read_timeout 3600s;
        proxy_send_timeout 3600s;
        proxy_buffering off;
        client_max_body_size 50M;
    }

    location ^~ /api/rpc2 {
        proxy_pass http://127.0.0.1:27777;
        proxy_set_header Host $http_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_set_header Origin $http_origin;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_read_timeout 3600s;
        proxy_send_timeout 3600s;
        proxy_buffering off;
        client_max_body_size 50M;
    }
}

/api/rpc2 使用独立的代理配置，单独设置 WebSocket 转发、3600 秒读写超时和关闭缓冲，便于维护 RPC 长连接。location / 负责其他页面与接口，并保留 Agent、远程终端和实时状态所需的 WebSocket 设置。

两个 location 都需要各自配置转发头，不能依赖另一个配置段。请保留请求原有的 Origin，不要在代理中改成固定站点地址，以免掩盖来源校验错误。普通请求（包括 HEAD）也应交给 Lite 处理。

备份恢复和主题上传会按约 5 MiB 分段传输。client_max_body_size 需要覆盖单个分段，不必按完整备份包体积放大。下载完整备份仍受代理读取超时和最大响应限制影响。

Docker + 本机反代

容器端口可只绑定回环地址：

ports:
  - "127.0.0.1:27777:27777"

Nginx 位于宿主机时反代 127.0.0.1:27777。Nginx 位于另一个容器时，不能使用它自己的 127.0.0.1，应使用 Docker 网络中的 lite 服务名和容器端口。

Cloudflare Tunnel

Cloudflare Tunnel 管理位于“反向代理”下的独立页签。可在后台保存 Tunnel Token 并启动 cloudflared。Token 在服务端加密保存，前端只读取“是否已保存”，不会取回明文。

Lite 的 Docker 镜像不再内置 cloudflared。使用后台 Tunnel 管理前，需要让 Lite 进程能够访问 cloudflared 可执行文件。

Linux 直装

复制并执行下面一条命令。它会自动识别 amd64 或 arm64，从 cloudflared 官方 Release 下载到 /usr/local/bin，设置执行权限并显示版本：

ARCH="$(uname -m)"; case "$ARCH" in x86_64|amd64) CF_ARCH=amd64 ;; aarch64|arm64) CF_ARCH=arm64 ;; *) echo "不支持的架构: $ARCH" >&2; exit 1 ;; esac; curl -fL "https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-${CF_ARCH}" -o /tmp/cloudflared && sudo install -m 0755 /tmp/cloudflared /usr/local/bin/cloudflared && rm -f /tmp/cloudflared && /usr/local/bin/cloudflared --version

安装到 /usr/local/bin/cloudflared 后，Lite 可以直接找到它，无需另设路径。返回后台“反向代理 → Cloudflare Tunnel”，保存 Tunnel Token 并启动即可。此方式由 Lite 管理 cloudflared 进程，不需要再执行 cloudflared service install。

安装到其他位置时，先把下方第一段路径改成实际位置，再整段复制执行。官方脚本安装的 Lite 服务名为 lite；使用自定义服务名时，把命令中的 lite 一并替换：

CLOUDFLARED_BIN=/完整路径/cloudflared; sudo test -x "$CLOUDFLARED_BIN" && sudo mkdir -p /etc/systemd/system/lite.service.d && printf '[Service]\nEnvironment="LITE_CLOUDFLARED_BIN=%s"\n' "$CLOUDFLARED_BIN" | sudo tee /etc/systemd/system/lite.service.d/cloudflared.conf >/dev/null && sudo systemctl daemon-reload && sudo systemctl restart lite && sudo systemctl status lite --no-pager

这条命令会先检查文件是否可执行，再创建 systemd 覆盖配置并重启 Lite。之后可以用 sudo systemctl cat lite 查看已经生效的 LITE_CLOUDFLARED_BIN 配置。

Docker：由 Lite 后台管理

在 Lite 的 Compose 文件所在目录复制并执行下面一条命令，下载与主机架构匹配的 Linux 版二进制：

ARCH="$(uname -m)"; case "$ARCH" in x86_64|amd64) CF_ARCH=amd64 ;; aarch64|arm64) CF_ARCH=arm64 ;; *) echo "不支持的架构: $ARCH" >&2; exit 1 ;; esac; curl -fL "https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-${CF_ARCH}" -o cloudflared && chmod 755 cloudflared && ./cloudflared --version

在原 Lite 服务中增加只读挂载和环境变量，其他端口、数据目录及现有环境变量保持原样：

services:
  lite:
    volumes:
      - ./data:/app/data
      - ./cloudflared:/usr/local/bin/cloudflared:ro
    environment:
      LITE_CLOUDFLARED_BIN: /usr/local/bin/cloudflared

执行 docker compose up -d --force-recreate 重建 Lite 容器，再到后台保存 Token 并启动 Tunnel。使用 docker run 时，同样在原命令中加入：

-v "$(pwd)/cloudflared:/usr/local/bin/cloudflared:ro" \
-e LITE_CLOUDFLARED_BIN=/usr/local/bin/cloudflared

Docker：独立 cloudflared 容器

也可以让官方 cloudflared 容器独立运行。将它加入 Lite 所在的 Docker 网络，并在 Compose 项目使用的 .env 文件中填写 TUNNEL_TOKEN：

services:
  cloudflared:
    image: cloudflare/cloudflared:latest
    restart: unless-stopped
    environment:
      TUNNEL_TOKEN: ${TUNNEL_TOKEN}
    command: tunnel --no-autoupdate run

Cloudflare 中的源站服务地址应填写同一 Docker 网络内的 Lite 服务名和端口，例如 http://lite:27777，不能填写 cloudflared 容器自己的 127.0.0.1。这种方式由 Docker 管理 cloudflared，不要再从 Lite 后台启动或停止 Tunnel；查看状态和日志时使用 docker compose ps cloudflared 与 docker compose logs cloudflared。

如果正在通过该 Tunnel 访问后台，停止 Tunnel 会立即断开当前页面，因此停止操作需要额外确认。

Cloudflare Access

为 Web 页面启用 Access 后，浏览器、Agent 与 MCP 客户端需要分别满足各自的访问策略。Lite 2.3.7 使用以下连接路径：

用途	路径	Access 配置
浏览器远程终端与文件	/api/admin/client/remote 及其子路径	允许已通过 Access 登录的浏览器访问，并支持 WebSocket
Agent 上报与任务	/api/clients/v2/rpc	使用 Service Auth，允许 Agent 的 Service Token
Agent 远程连接	/api/clients/remote	使用与 Agent 上报相同的 Service Auth 凭据
公开大屏实时状态与 RPC	/api/clients、/api/rpc2	按该站点面向访客或登录用户的访问策略配置
MCP 服务与授权发现	/mcp、/.well-known/oauth-protected-resource、/.well-known/oauth-protected-resource/mcp、/.well-known/oauth-authorization-server	允许 MCP 客户端访问并保留 Authorization 请求头，不缓存响应
MCP 客户端注册与授权	/oauth/register、/oauth/authorize、/oauth/token、/oauth/revoke	同时满足客户端请求和浏览器授权跳转，不能只放行后台网页

Agent 中需同时配置 Client ID 和 Client Secret，见 Agent 的 Cloudflare Access 配置。浏览器终端应沿用正常的 Access 登录策略，不需要为了排查而把整段管理接口设为 Bypass；Lite 自身的登录、重新验证和远程权限检查仍然生效。

MCP 客户端通常不共享浏览器的 Access 登录 Cookie；即使浏览器能够进入授权页，客户端请求仍可能被 Access 登录页或挑战拦截。请根据客户端是否支持额外请求头配置对应策略，保留 Lite 自身的授权检查。MCP 服务及 OAuth 路径需要转发到同一个 Lite 实例，使用与后台一致的外部地址和协议。

不要只放行首页

只允许 / 和静态资源时，页面可能正常显示，但 API 或 WebSocket 仍会被拦截。/api/clients 是实时状态入口，仅放行它不能解决浏览器终端 /api/admin/client/remote 或 Agent /api/clients/remote 的 403。

常见错误

• 502：代理无法连接 Lite，常见于端口写错或容器网络地址错误。
• 403 WebSocket：Origin、登录会话或 Cloudflare Access 拒绝连接。
• 页面一直加载：HTML 可以访问，但静态资源、API 或 WebSocket 被缓存或拦截。
• HTTPS 页面跳回 HTTP：代理没有正确传递 X-Forwarded-Proto，或该请求来自不受信任的代理地址。