本页目录

故障排查

先找到失败的环节，再检查该环节的对象与日志。记录发生时间、对象名称和最近一次修改，每次只调整一个条件。

页面访问异常

在部署主机访问 http://localhost:6200。能打开 Watchdog 时，先看仪表盘中的 TGateway 运行状态和最近错误；未运行则转到服务启动异常。
在同一主机访问 http://localhost:6100。本机可访问、远程不可访问时，核对远程浏览器使用的主机 IP、实际端口、监听地址、防火墙及反向代理。容器部署还需核对端口映射。
页面打开但登录失败时，确认登录的是 TGateway、Watchdog 还是 Studio，再核对该组件的账号。三者的凭据独立管理，修改一处不会同步其他组件。

端口已修改时使用实际地址。恢复后，在本机和需要访问的远程浏览器分别登录，确认进入的是预期工程。账号与工作区检查见启动与首次登录。

先查看 Watchdog“日志查看”、Logs/Watchdog/ 和系统服务日志。网关已启动后又退出时，同时查看 GatewayApp/Logs/XTrace/；路径以现场日志配置为准。容器使用 docker logs。

错误或现象	检查与处理
提示缺少 `.NET` 或要求安装运行时	用 `dotnet --list-runtimes` 核对 .NET 10 Runtime，并确认运行包与运行时架构一致。
`Exec format error`	运行包架构与主机不匹配，重新选择 x64 或 ARM64 等对应包。
`Access is denied` / `Permission denied`	按错误中指出的文件或设备检查权限；以实际服务账号为准。Linux 同时检查可执行文件的执行位。
端口已占用	核对是否同时运行前台实例和系统服务，以及是否与其他程序共用端口。确认进程归属后再处理。
Watchdog 正常，TGateway 反复退出	核对完整 `GatewayApp`、当前工程、Web 端口及网关启动错误，优先处理第一条错误。

系统服务仍无法定位原因时，先停止该服务并确认进程退出，再用同一运行账号前台启动。具体命令见 Windows 部署、Linux 部署或 Docker 运行检查。

恢复后确认系统服务或容器保持运行、Watchdog 不再连续增加启动失败次数，且 TGateway 可登录。重启只用于验证修正结果，不代替定位错误。

在“开发配置 → 采集配置”选择故障设备，检查“详细信息”、通道日志和设备日志。

现象	判断与下一步
同一通道下多个设备同时异常	先检查共同的连接、串口占用、源端服务和网络。
无响应或读取超时	核对 IP、端口或串口参数，再检查站号、协议及源端是否接收请求。
连接成功，但单个地址报错	用同设备一个已知可读地址比较，核对功能区、偏移、类型、长度和协议异常码。
TLS 握手失败	核对证书信任、主机名、有效期及设备的 TLS 配置。

按分层诊断继续定位；连接方向、串口与超时参数见通道传输。恢复后观察原设备的新请求、响应、变量质量和采集时间，不能只看 TCP 已连接。

用一个已知值核对，恢复原配置后至少观察两个连续采样窗口。首次配置可参考采集第一个点，完整参数见通道、设备与变量。

在“开发配置 → 数据转发”选择目标，按以下顺序检查：

范围、触发和调试见转发运行与恢复。缓存持续积压时，查看缓存出站状态，区分待发送、重试和容量不足。

恢复后主动改变一个测试值，在接收端核对新值、变量身份和时间；启用补传时，按完整补传验证检查旧记录与新记录。

现象	判断与下一步
只能看到最新值，没有历史过程	检查是否使用实时数据目标；实时表覆盖更新，需要连续记录时使用历史数据目标。
数据库已有记录，页面查不到	核对选择的目标、变量、数值/字符串分类及时间范围，再检查查询错误。
数据库也没有记录	从转发组范围、触发和目标日志排查写入，再检查数据库权限、表名和剩余空间。
时间相差八小时	核对目标时区、UTC 标记及数据库模型，不要重复叠加偏移。
曲线有断点或没有曲线	对照采集质量与周期；自定义 SQL 目标不提供普通历史目标的同样趋势图。

存储目标选择见数据模型对照，页面查询与导出见数据查询。恢复后让测试变量产生新值，同时核对物理存储记录与页面查询结果。

进入系统监控，记录同一观察时段的设备数、变量数、采集周期、脚本、转发和存储负载。

修正后用相同负载和观察窗口比较趋势，确认新采样正常、接收端持续收到数据、积压按预期减少。不要把一次低负载快照当成现场容量结论。

整理版本、操作系统与架构、复现步骤、发生时间及相关日志；隐藏密码、Token 和完整连接凭据。通过联系与支持提供必要信息。