文档中心

Appearance

代理与转发 ​

网站和 API 使用 访问服务，按域名及路径处理 HTTP/HTTPS 请求；其他 TCP/UDP 服务使用 端口转发，按入口端口转发流量。下列操作需要对应模块的管理权限。

首次配置网站时，可先按发布第一个 HTTPS 服务走通完整流程，再按本页增加路径或端口规则。

新建访问服务 ​

  1. 进入 访问服务 -> 添加访问服务
  2. 在 详细内容 中填写域名、选择入口协议、填写入口端口
  3. 在 路由规则 中，将根路径 / 的动作类型设为 转发，填写后端完整地址（如 http://192.168.8.223:8080）；按需添加其他路径规则
  4. 使用 HTTPS 时，在 证书配置 中选择覆盖该域名的有效证书，按需调整加密套件配置
  5. 保存后确认页面没有配置测试或加载错误，服务处于启用状态，再从客户端验证业务访问

域名与端口冲突

相同域名不能在相同入口端口上重复创建，已禁用但未删除的服务也占用该组合；不同入口端口可以使用同一域名。域名大小写和前后空格不能用来区分两个服务。

同一服务内不要同时填写匹配范围重叠的域名，例如 api.example.com 和 *.example.com。更换已有服务的证书后，需保存并检查实际部署结果，详见证书管理。

示例前提 ​

以下示例可独立使用，域名和 IP 请替换为实际值。其中 192.168.8.10 是 HiHTTPS 服务器，192.168.8.223 是后端服务器。

  • 将业务域名的 DNS 解析指向客户端可达的 HiHTTPS 地址
  • 确保 HiHTTPS 能访问后端服务，并根据业务访问范围放通入口端口的防火墙、安全组和 NAT；host 网络模式下不需要增加 Docker 端口映射
  • 使用 HTTPS 前，先在证书管理中申请或导入覆盖业务域名的有效证书及私钥

验证命令使用 curl --resolve 临时将域名指向 HiHTTPS，方便在 DNS 生效前测试；它仍保留域名用于 HTTP 请求和 TLS 证书校验。正式使用时仍需配置 DNS。

示例：HTTP 反向代理 ​

场景：通过 http://web.example.com 访问内网网站 http://192.168.8.223:8080，适合受控内网或临时联调。

配置位置配置项值
详细内容域名web.example.com
详细内容入口协议与端口HTTP，80
路由规则路径/（根路径）
路由规则动作类型转发
路由规则转发目标http://192.168.8.223:8080

保存后，从客户端验证：

bash
curl -i --resolve web.example.com:80:192.168.8.10 http://web.example.com/

应返回后端网站的页面或业务响应，而不是 HiHTTPS 管理页面。HTTP 不加密传输，面向公网或传输敏感信息时请使用 HTTPS。

示例：HTTPS 反向代理 ​

场景：后端提供 HTTP，通过 HiHTTPS 对外提供 https://app.example.com。

配置位置配置项值
详细内容域名app.example.com
详细内容入口协议与端口HTTPS，443
路由规则路径/（根路径）
路由规则动作类型转发
路由规则转发目标http://192.168.8.223:8080
证书配置TLS 证书覆盖 app.example.com 的有效证书

保存后，从客户端验证：

bash
curl -i --resolve app.example.com:443:192.168.8.10 https://app.example.com/

应通过证书校验并返回后端业务响应。使用私有 CA 签发的证书时，先在客户端信任该 CA，或通过 --cacert /path/to/ca.pem 指定 CA 证书，不要用 -k 代替证书验收。

入口协议与后端协议相互独立

本例由 HiHTTPS 终止 TLS，客户端到 HiHTTPS 使用 HTTPS，HiHTTPS 到后端仍使用 HTTP，应在受信内网中使用。若后端链路也需要加密，转发目标应填写后端实际提供的 HTTPS 地址和端口。

选择 HTTPS 只会监听该 HTTPS 入口，不会额外启用 HTTP 入口，也不会自动将 HTTP 请求跳转到 HTTPS。

示例：同域名按路径分流 ​

场景：通过 https://portal.example.com 访问网站，将 /api/ 下的请求转发到另一项 API 服务。

在 详细内容 中填写域名 portal.example.com，入口选择 HTTPS、端口 443；在 证书配置 中选择覆盖该域名的有效证书。在 路由规则 中添加 /api/ 规则，并保留根路径 / 作为兜底：

路径动作类型转发目标用途
/api/转发http://192.168.8.223:9000API 服务
/转发http://192.168.8.223:8080网站页面及其他请求

本例转发目标只填写协议、主机和端口，不附加路径，也不添加自定义重写配置，因此请求路径会保留：

  • https://portal.example.com/index.html → http://192.168.8.223:8080/index.html
  • https://portal.example.com/api/users → http://192.168.8.223:9000/api/users

保存后，分别验证网站和 API（将请求路径替换为后端实际存在的页面或接口）：

bash
curl -i --resolve portal.example.com:443:192.168.8.10 https://portal.example.com/index.html
curl -i --resolve portal.example.com:443:192.168.8.10 https://portal.example.com/api/users

路径规则不会自动去掉前缀

此配置要求 API 后端能处理 /api/users，不会自动改成 /users。如果后端接口没有 /api/ 前缀，需要另行配置路径重写，或改用独立域名。填写 /api/ 时请保留末尾的 /；本例验证地址也包含此前缀。

示例：自定义 HTTPS 端口 ​

场景：保留已有的 https://app.example.com 服务，使用 https://app.example.com:8443 发布另一项 Web 服务。

新增一个访问服务：

配置位置配置项值
详细内容域名app.example.com
详细内容入口协议与端口HTTPS，8443
路由规则路径/（根路径）
路由规则动作类型转发
路由规则转发目标http://192.168.8.223:9000
证书配置TLS 证书覆盖 app.example.com 的有效证书，可复用 443 服务的证书

两个服务的入口端口不同，可以使用同一域名。证书校验的是域名，不需要为 8443 单独申请证书。确认入口不存在 Stream、系统服务或其他进程的监听冲突，并在服务器及上游网络设备放通 8443/tcp 后验证：

bash
curl -i --resolve app.example.com:8443:192.168.8.10 https://app.example.com:8443/

应返回 9000 端口后端的业务响应。访问地址必须显式携带 :8443，省略端口会访问默认的 443 服务；不要使用管理端口 81 或系统内部保留端口，详见安装部署。

端口转发（Stream） ​

用于按端口转发 TCP/UDP 流量，例如 SSH 和游戏服务。本文示例为透传配置，不额外增加加密或身份认证。FTP 等使用独立控制连接和数据连接的协议，还需配置对应的数据端口与网络策略，不能只转发一个端口就认为完整可用。

配置项：

  • 入站端口：对外监听端口
  • 转发主机：后端主机
  • 转发端口：后端监听端口
  • TCP转发 / UDP转发（可同时启用）

使用步骤：

  1. 进入 访问服务 -> 端口转发 -> 添加端口转发
  2. 填写：
    • 入站端口：HiHTTPS 对外监听的端口，例如 9090
    • 转发主机：后端服务地址，可填写域名、IPv4 或 IPv6
    • 转发端口：后端服务实际监听端口，例如 8000
    • 按需勾选 TCP转发、UDP转发，至少启用一种
  3. 保存成功后确认规则已启用；若保存或配置测试失败，应按页面错误处理，不要把已提交表单当作已上线规则
  4. 应用使用 host 网络，不需要修改 Docker 端口映射；请在服务器防火墙放通该入口端口

示例：转发 TCP 服务 ​

场景：将 9090 转发到内网 192.168.8.223:8000。

配置项值
入站端口9090
转发主机192.168.8.223
转发端口8000
协议勾选 TCP转发

如果现场使用 UFW，并且只允许 192.168.8.0/24 网段访问，可按实际网段调整后执行：

bash
sudo ufw allow from 192.168.8.0/24 to any port 9090 proto tcp

从允许的客户端使用对应业务客户端连接 192.168.8.10:9090，确认请求到达后端。nc -vz 192.168.8.10 9090 可检查 TCP 连接，但不能替代应用协议验收。

示例：同时转发 TCP/UDP ​

某服务同一端口同时使用 TCP 和 UDP 时，同时勾选 TCP转发 与 UDP转发。例如入站端口为 9000、允许网段为 192.168.8.0/24，使用 UFW 时分别放行：

bash
sudo ufw allow from 192.168.8.0/24 to any port 9000 proto tcp
sudo ufw allow from 192.168.8.0/24 to any port 9000 proto udp

再分别使用支持 TCP 和 UDP 的业务客户端验证。UDP 没有 TCP 的连接握手，不能仅凭 TCP 探测成功判断 UDP 转发可用。不使用 UFW 的环境，在现有防火墙或安全组中配置等价规则，无需为本文示例安装 UFW。

端口转发与访问服务的选择

端口转发属于四层转发，不解析 HTTP 请求内容，也不按 HTTP 域名或路径分流。上面的透传示例可以转发 TCP 上的 HTTP 或 TLS 流量，但不会终止 TLS，证书仍由后端提供。若需要网站 / API 的反向代理、HTTPS 证书绑定、按域名或路径转发，请使用访问服务。

新增对外监听端口后，应同步维护服务器和上游网络设备的防火墙规则。

完成检查与日常变更 ​

  • 通过实际业务域名和入口端口访问，响应来自预期后端。
  • HTTPS 连接通过证书校验；配置了访问控制时，同时验证允许与拒绝的请求。
  • 端口转发按实际 TCP/UDP 协议验收，不把“端口看起来开放”当作业务正常。
  • 修改后端、协议、端口或证书前记录原配置，重要服务在维护窗口变更。
  • 停用或删除规则会影响业务访问；暂停使用时优先确认影响范围，不要用删除重建代替排查。

保存报错、返回 502、证书未更新或 Stream 不可达时，按常见问题逐项检查。