sealtun

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Sealtun

First Decision

初步决策

Classify the request before answering or editing:

User operation: install, login, expose HTTPS or SSH, secure public HTTP traffic, bind a domain, inspect state, stop/start/resume, clean up, or use the dashboard. Read
```
references/cli.md
```
.
Declarative configuration:
```
sealtun.yaml
```
,
```
apply -f
```
,
```
diff -f
```
, multi-tunnel management, stable names,
```
ttl
```
, HTTPS access policies, or SSH tunnel declarations. Read
```
references/declarative.md
```
.
Troubleshooting: login/profile mismatch, daemon/session issues, local port failures, SSH direct TCP/NodePort problems, remote Kubernetes problems, DNS, Ingress, certificate, logs, metrics, or dashboard behavior. Read
```
references/troubleshooting.md
```
.
Maintainer release work: GitHub tag release, GoReleaser, GHCR Docker image, npm packages,
```
packages/
```
, or publish dry-runs. Read
```
references/release.md
```
.

If the request is inside the Sealtun repository, prefer the current source tree and README over these references when they conflict. Use

rg

to inspect Cobra commands, flags, Makefile targets, workflows, and tests before changing repo behavior.

在回答或编辑前先对请求进行分类：

用户操作：安装、登录、暴露HTTPS或SSH、保护公网HTTP流量、绑定域名、查看状态、停止/启动/恢复、清理，或使用仪表盘。请阅读
```
references/cli.md
```
。
声明式配置：
```
sealtun.yaml
```
、
```
apply -f
```
、
```
diff -f
```
、多隧道管理、稳定名称、
```
ttl
```
、HTTPS访问策略，或SSH隧道声明。请阅读
```
references/declarative.md
```
。
故障排查：登录/配置文件不匹配、守护进程/会话问题、本地端口故障、SSH直接TCP/NodePort问题、远程Kubernetes问题、DNS、Ingress、证书、日志、指标，或仪表盘异常。请阅读
```
references/troubleshooting.md
```
。
维护者发布工作：GitHub标签发布、GoReleaser、GHCR Docker镜像、npm包、
```
packages/
```
，或发布预演。请阅读
```
references/release.md
```
。

如果请求是在Sealtun仓库内，当这些参考文档与当前源码树和README冲突时，优先以当前源码树和README为准。在修改仓库行为前，使用

rg

检查Cobra命令、标志、Makefile目标、工作流和测试。

Required Execution Flow

必选执行流程

Follow this flow after the skill triggers:

Scope gate: verify the request is about making a local/dev service publicly reachable, operating a Sealtun tunnel, troubleshooting Sealtun, declarative Sealtun config, or Sealtun release/npm work. If it is only generic production deployment, buying a domain, or DNS-only configuration without local-service tunneling, do not force Sealtun into the answer.
Select one mode before acting:
- Guidance mode: user asks how to use Sealtun. Load the matching reference and give commands; do not run live tunnel/cloud/npm commands.
- Live operation mode: user explicitly asks to execute, create, apply, stop, clean up, bind a domain, or publish. Run preflight checks first, then the requested command, then verification.
- Repository change mode: user asks to modify Sealtun. Inspect source with
```
rg
```
  , edit narrowly, run focused tests, then summarize changed files and verification.
- Troubleshooting mode: user reports a problem. Run non-mutating diagnostics first, identify the likely layer, then propose or perform fixes only when the requested action is clear.
- Release mode: user asks to release or publish npm. Run tests and dry-runs first when available, wait for required GitHub release assets before npm publishing, and verify final package/release state.
Gather minimum context. Inside this repo, inspect current code/README before relying on references. Outside the repo, use the references as the command source. Prefer non-mutating checks such as
```
sealtun --version
```
,
```
sealtun status
```
,
```
sealtun profile current
```
,
```
sealtun region current
```
,
```
sealtun list
```
,
```
sealtun inspect
```
, and
```
sealtun doctor
```
.
Control mutations. Do not run
```
sealtun expose
```
,
```
sealtun apply
```
,
```
sealtun domain set/clear
```
,
```
sealtun stop
```
,
```
sealtun cleanup
```
,
```
sealtun logout
```
,
```
git tag
```
,
```
git push
```
, or
```
npm publish
```
unless the user explicitly asked for execution or release work in the current task. For declarative changes, prefer
```
apply --dry-run
```
and
```
diff
```
before real
```
apply
```
.
Verify completion. After live operations, inspect the resulting tunnel/session/domain/release/npm package state. After code changes, run tests relevant to the touched code. Report the exact command sequence and final state, without printing secrets.

技能触发后，请遵循以下流程：

范围校验：验证请求是否涉及将本地/开发服务暴露到公网、操作Sealtun隧道、排查Sealtun故障、Sealtun声明式配置，或Sealtun发布/npm相关工作。如果只是通用生产部署、购买域名，或不涉及本地服务隧道的纯DNS配置，请勿在答案中强行引入Sealtun。
执行前选择一种模式：
- 指导模式：用户询问如何使用Sealtun。加载匹配的参考文档并提供命令；请勿运行实时隧道/云/npm命令。
- 实时操作模式：用户明确要求执行、创建、应用、停止、清理、绑定域名或发布。先执行预检检查，再运行请求的命令，最后进行验证。
- 仓库修改模式：用户要求修改Sealtun。使用
```
rg
```
  检查源码，进行精准编辑，运行针对性测试，然后总结修改的文件和验证结果。
- 故障排查模式：用户反馈问题。先执行非破坏性诊断，确定可能的问题层级，仅当请求的操作明确时才提出或执行修复。
- 发布模式：用户要求发布或发布npm包。若可行，先运行测试和预演，等待所需的GitHub发布资产后再进行npm发布，并验证最终包/发布状态。
收集最少上下文信息。在本仓库内，依赖参考文档前先检查当前代码/README。在仓库外，以参考文档作为命令来源。优先使用非破坏性检查，例如
```
sealtun --version
```
、
```
sealtun status
```
、
```
sealtun profile current
```
、
```
sealtun region current
```
、
```
sealtun list
```
、
```
sealtun inspect
```
和
```
sealtun doctor
```
。
控制破坏性操作。除非用户在当前任务中明确要求执行或发布工作，否则请勿运行
```
sealtun expose
```
、
```
sealtun apply
```
、
```
sealtun domain set/clear
```
、
```
sealtun stop
```
、
```
sealtun cleanup
```
、
```
sealtun logout
```
、
```
git tag
```
、
```
git push
```
或
```
npm publish
```
。对于声明式变更，优先使用
```
apply --dry-run
```
和
```
diff
```
，再执行实际的
```
apply
```
。
验证完成情况。实时操作后，检查生成的隧道/会话/域名/发布/npm包状态。代码修改后，运行与修改代码相关的测试。报告精确的命令序列和最终状态，请勿打印机密信息。

Operating Rules

操作规则

Do not expose user secrets in final answers, logs, commits, or generated docs. Prefer
```
*Env
```
fields and environment variables for passwords and tokens unless the user explicitly wants a one-shot inline example.
Explain that Sealtun public access controls are enforced in the Sealtun server proxy layer, not by Ingress annotations. They protect HTTPS public business traffic, not the internal
```
/_sealtun/ws
```
control channel and not SSH direct TCP NodePort traffic.
For SSH exposure, prefer
```
sealtun expose 22 --protocol ssh
```
when the region supports public TCP NodePort. Use
```
sealtun ssh connect <tunnel-id>
```
only as a WebSocket ProxyCommand fallback.
For declarative work, run or recommend
```
sealtun apply -f sealtun.yaml --dry-run
```
and
```
sealtun diff -f sealtun.yaml
```
before a real apply when feasible.
For release or npm publishing, verify tests and dry-runs first when feasible. Release/GHCR publishing is tag-driven; master or PR CI builds and tests without publishing release or GHCR artifacts.
Treat
```
packages/
```
and
```
homepage/
```
as generated local directories in this project; they are ignored and should not be committed unless the repo policy changes.
Use exact command names and flags from the repository when modifying instructions. Supported tunnel protocols are
```
https
```
and the dedicated
```
ssh
```
mode; generic TCP/UDP/gRPC are not supported unless the repo adds them.

请勿在最终答案、日志、提交或生成的文档中暴露用户机密。优先使用
```
*Env
```
字段和环境变量存储密码和令牌，除非用户明确需要一次性内联示例。
需说明Sealtun公网访问控制是在Sealtun服务器代理层执行的，而非通过Ingress注解。这些控制保护HTTPS公网业务流量，但不保护内部
```
/_sealtun/ws
```
控制通道，也不保护SSH直接TCP NodePort流量。
对于SSH暴露，当区域支持公网TCP NodePort时，优先使用
```
sealtun expose 22 --protocol ssh
```
。仅在WebSocket ProxyCommand降级方案中使用
```
sealtun ssh connect <tunnel-id>
```
。
对于声明式工作，若可行，在执行实际apply前，运行或推荐
```
sealtun apply -f sealtun.yaml --dry-run
```
和
```
sealtun diff -f sealtun.yaml
```
。
对于发布或npm包发布，若可行，先验证测试和预演。发布/GHCR发布是由标签驱动的；master分支或PR的CI构建和测试不会发布版本或GHCR制品。
将
```
packages/
```
和
```
homepage/
```
视为项目中生成的本地目录；它们会被忽略，除非仓库政策变更，否则不应提交。
修改说明时，请使用仓库中的精确命令名称和标志。支持的隧道协议为
```
https
```
和专用
```
ssh
```
模式；通用TCP/UDP/gRPC不受支持，除非仓库添加了相关支持。

Response Shape

响应格式

For usage questions, give a short working command sequence and explain only the relevant gotchas. For repo changes, implement the change, run focused tests, then summarize changed files and verification. For troubleshooting, start with the lowest-cost local checks, then escalate to remote Kubernetes diagnostics.

对于使用问题，提供简短的可用命令序列，仅解释相关注意事项。对于仓库修改，先实现变更，运行针对性测试，然后总结修改的文件和验证结果。对于故障排查，先从成本最低的本地检查开始，再逐步升级到远程Kubernetes诊断。