简短回答
在家时，AmazHA（一款面向 Amazfit 手表的 Home Assistant 应用）只需要你的本地地址，例如 http://192.168.1.50:8123，不需要从外部能访问任何东西。离家时，你的手机需要一个它能访问的远程地址：Home Assistant Cloud、Tailscale 或 WireGuard 之类的 VPN，或者带 HTTPS 的自有域名。两个都填上，AmazHA 会自动选择能用的那一个。
在家时不需要任何额外的东西
在你的家庭网络中，AmazHA 唯一需要的地址，就是你平时在家用浏览器打开 Home Assistant 时用的那个。它就是 AmazHA 设置中的本地 URL (LAN) 字段，单凭它就够了：无需订阅、无需 VPN、无需域名，也无需在路由器上开放端口。
AmazHA 的设置中有两个地址字段：本地 URL (LAN) 和远程 URL。任意一个都可以留空。如果你只在家里使用手表，填写本地地址，远程地址留空，就完成了。哪天你想在办公室或度假时也能用手表，再加上远程地址即可，其他一切都不用动。
这些字段位于 Zepp 应用中的我的 › 你的手表 › 应用 › AmazHA › 设置 › Home Assistant。解锁完整版之后它们才会出现（一次性解锁，无订阅）：免费版是使用示例数据的实时演示，不会连接服务器。连接 Home Assistant 教程用视频演示了填写本地地址这一步。
典型的本地地址看起来像下面这样（仅为示例，请使用你自己的）：
http://192.168.1.50:8123
http://homeassistant.local:8123
如果你在本地 URL (LAN) 中填写的地址没有 http:// 或 https://，AmazHA 会在前面加上 http://，因为本地服务器通常使用普通的 http。
为什么必须由手机来访问 Home Assistant
手表本身从不直接与 Home Assistant 通信。它通过 Bluetooth 与你的手机通信，而 AmazHA 运行在手机上 Zepp 应用里的那一部分，是唯一向你的服务器发送请求的部分。所以“我的手表能访问 Home Assistant 吗？”这个问题，其实是“我的手机此刻、在它所在的地方，能访问 Home Assistant 吗？”
这带来几个实际的后果：
- 手表不需要 Wi-Fi。 为了 AmazHA，它从不加入任何网络。只有 Bluetooth 的手表也一样能用。
- 手机必须在附近，开启 Bluetooth，并让 Zepp 应用保持运行。否则手表会显示离线 · 手机没有响应，这和地址填错是两回事（见故障排除第 2 步）。
- 手机所连的网络决定了哪个地址能用。 在你家的 Wi-Fi 上，本地地址能用。在移动数据、朋友家或酒店的 Wi-Fi 上，只有远程地址可能能用，而且前提是手机从那里能访问它。
- VPN 必须在手机上连接，而不是在手表上。手表对它一无所知。
- 你的令牌留在手机上。 你只需在 AmazHA 设置中粘贴一次长期访问令牌。手表通过它与手机之间已有的 Bluetooth 连接，只接收它要显示的内容；令牌永远不会被发送到手表。
这也解释了一个让人困惑的现象：设置显示已连接，手表却显示离线。设置测试的只是手机通往 Home Assistant 的路径；手表还需要通往手机的 Bluetooth 路径。
AmazHA 如何选择地址
AmazHA 会自己选择地址：先本地，后远程。出门时没有开关要拨，你也从来不需要手动在两个字段之间做选择。
只有一个地址时
只填了一个字段时，AmazHA 就直接用它。不做探测，也不做切换。只有本地地址的设置在家能用，离家时显示离线横幅；只有远程地址的设置，在手机能访问该地址的任何地方都能用。
两个地址都有时
两个字段都填写后，手机会同时询问两个地址 Home Assistant 是否有响应，时限很短，只有 1.5 秒。如果本地地址有响应，AmazHA 就用它；如果只有远程地址有响应，就用远程地址。胜出的地址会被记住，之后的请求直接发往它，不再重新询问。
这项检查比“有东西响应了”更严格。只有当地址以 Home Assistant API 的身份响应时，才算数。这在别人的网络上很重要：在酒店的 Wi-Fi 上，192.168.1.50 可能是一台打印机、一个路由器页面，或者一个返回网页的认证门户。AmazHA 不会把它误认成你的服务器，所以当真正该用的是远程地址时，它不会卡在你的本地地址上。
离家与回家
记住的地址会一直保留，直到发往它的某个请求失败。当你离开家、手机断开你的 Wi-Fi 时，下一个发往本地地址的请求会失败，AmazHA 就会忘掉它，接下来的尝试会重新询问两个地址，然后落到远程地址上。AmazHA 应用打开期间，手表每 8 秒刷新一次，所以实际上，切换后的第一次刷新可能会失败并短暂显示离线横幅，下一次刷新就会恢复。
回家时的过程正好相反，而且更安静：如果你的远程地址在家庭网络内部也能用，AmazHA 会继续使用它，直到某个请求失败，或者你再次点按连接。这种情况下并没有任何问题；只是远程地址仍然好用而已。
填写地址
填写这些字段时，有几个细节值得了解：
- 服务器地址后面不要加任何内容。 填
http://192.168.1.50:8123，而不是http://192.168.1.50:8123/lovelace。远程地址也一样：填https://xxxxx.ui.nabu.casa，而不是https://xxxxx.ui.nabu.casa/lovelace。留着路径的话，地址虽然有响应，但不是以 Home Assistant API 的身份响应。 - 协议。 没有写协议时，本地 URL (LAN) 会被加上
http://，远程 URL 会被加上https://。如果某个远程地址确实是普通的 http（例如 VPN 地址），请自己写上http://。 - 端口。 如果你的地址需要端口，请保留它，例如
:8123。没有端口时，https://意味着 443。 - 一个令牌用于两者。 只需在长期访问令牌中粘贴一次；它同时适用于本地地址和远程地址。两个地址必须通往同一个 Home Assistant。
连接 Home Assistant 教程讲解了填写远程地址这一步，第 8 步讲解了随后的测试。
远程访问方案对比
只要手机能在它所在的地方打开某个远程地址，并且该地址以 Home Assistant API 的身份响应，它就能与 AmazHA 配合使用。选择哪一种，是 Home Assistant 层面的决定，而不是 AmazHA 层面的。下面把常见的几种放在一起对比。
| 方案 | 远程 URL 里填什么 | 家里需要开放的端口 | HTTPS 与证书 | 费用 | 手机需要 |
|---|---|---|---|---|---|
| Nabu Casa 的 Home Assistant Cloud（将于 2026 年 12 月 2 日更名为 Home Assistant Link） | 它为你生成的远程地址，https://xxxxx.ui.nabu.casa |
无 | 已包含 | 订阅 | 无需额外操作 |
| VPN，例如 Tailscale 或 WireGuard | Home Assistant 在 VPN 内的地址 | Tailscale 无需；自建 WireGuard 服务器需要一个 | 隧道已加密；只有你自己配置了才有 https | 有免费方案 | 连接 VPN |
| 通过隧道使用自有域名，例如 Cloudflare Tunnel | https://ha.example.com |
无 | 由隧道提供 | 通常需要一个域名 | 无需额外操作 |
| 通过反向代理使用自有域名 | https://ha.example.com |
一个（通常是 443） | 由你自己配置，例如 Let’s Encrypt | 一个域名或免费的动态 DNS 名称 | 无需额外操作 |
| 直接端口转发到 Home Assistant | https://yourname.duckdns.org:8123 |
一个 | 由你自己配置 | 有免费的动态 DNS | 无需额外操作 |
Home Assistant Cloud（即将更名为 Home Assistant Link）
Home Assistant Cloud 是由 Nabu Casa 运营的订阅服务；它的订阅收入资助着 Home Assistant 的全职开发。Home Assistant 自己的文档称它是对大多数人来说最简单的方案：不需要在路由器上开放端口，流量经过加密，还会为你生成一个唯一的远程 URL。
对 AmazHA 来说，你只需要这个远程 URL：照着 Home Assistant 显示的样子，把它复制到远程 URL 中，后面不要加任何内容。你的长期访问令牌经由它和经由本地地址一样有效，因为两者通往同一台服务器。
2026 年 10 月 2 日，Nabu Casa 宣布，Home Assistant Cloud 将于 2026 年 12 月 2 日更名为 Home Assistant Link。公告称这是同一项订阅换了新名字，无需任何操作。它没有提到任何地址变更，所以目前在 AmazHA 中无需改动任何东西。
VPN：Tailscale、WireGuard 等
无论手机身在何处，VPN 都能把它虚拟地接入你的家庭网络。Home Assistant 的文档把 Tailscale、ZeroTier One 等 VPN 服务列为一种安全的接入方式，同时指出了其中的限制：必须先连接 VPN，外部才能访问 Home Assistant。对 AmazHA 来说，这意味着 VPN 必须在手机上保持连接。如果 VPN 断开，手表会显示离线 · 无法连接 Home Assistant，直到它恢复连接。
远程 URL 里要填的，是 VPN 开启时你的手机访问 Home Assistant 所用的地址：服务器在 VPN 内的地址，或者 VPN 为它解析的名称。有两个细节：
- 如果你的服务器在那里使用普通的 http 响应，请在地址前写上
http://。没有写协议时，AmazHA 会给远程地址加上https://，那样就不会有响应。 - 在某些 VPN 配置下，你的家庭地址本身，也就是
192.168.1.50，可以通过隧道访问。这时只要 VPN 开着，本地地址在哪里都能用，远程字段则作为 VPN 未开启时的备用。
VPN 是暴露面最小的方案：你的服务器没有任何部分向互联网开放。代价是，每一台需要访问 Home Assistant 的设备（包括手机）都必须运行 VPN 客户端。
带 HTTPS 的自有域名：反向代理或隧道
有了自有域名，https://ha.example.com 就能从任何地方通往你的 Home Assistant。常见的实现方式有两种：
- 反向代理（Nginx、Caddy、Traefik 等）部署在家里，在 443 端口接收请求、处理证书，再把请求转交给 Home Assistant。它需要在路由器上做端口转发。
- 隧道，例如 Cloudflare Tunnel，会在你的网络内运行一个小型连接器，保持一条通往服务提供方的出站连接，因此路由器上什么都不用开放。服务提供方会用有效证书来提供你的域名。
在这两种情况下，都有某个东西位于 Home Assistant 前面并向它转发请求，而 Home Assistant 必须被告知要信任它。Home Assistant 的文档写得很明确：除非你开启 Trust X-Forwarded-For（信任 X-Forwarded-For）并把代理添加到 Trusted proxies（受信任的代理）中，否则来自反向代理的请求会被拦截。如果你跳过这一步，经过代理的每个请求都会得到 400 Bad Request（下文详述）。
单纯的端口转发
把路由器的端口直接转发到 Home Assistant，是最直接的方式，也是 Home Assistant 的远程访问文档最为谨慎的一种：仅仅开放端口并不安全，流量必须加密，在暴露任何东西之前，你都应该过一遍它的安全检查清单。文档还指出了两个实际的陷阱：许多互联网服务提供商给你的是动态 IP 地址，所以它建议使用 DuckDNS 之类的动态 DNS 名称；还有些提供商会让你处于 CG-NAT 之后，外部的连接根本无法到达你这里。
如果你走这条路，远程地址就是你的动态 DNS 名称，加上 https 和你转发的端口，例如 https://yourname.duckdns.org:8123。把它原样填进远程 URL。
离家时的 HTTPS 与证书
离家时，故障排除教程中的规则很简短：地址需要带有效证书的 https。原因有两个。
第一是安全。你的长期访问令牌会随手机发出的每个请求一起发送。在开放的互联网上使用普通的 http，路径上的任何人都能读到它，从而控制你的家。
第二是手机会拒绝它不信任的证书。自签名证书是在你自己的服务器上生成的，没有经过手机默认信任的机构签名，所以连接还没到达 Home Assistant 就被拒绝了。在手表上，这看起来和任何其他无法访问的服务器一样。简单的解决办法是使用手机本来就信任的证书：
- Home Assistant Cloud 和 Cloudflare Tunnel 之类的隧道会替你提供证书。
- 如果使用自有域名或动态 DNS 名称，Let’s Encrypt 证书免费，而且受手机信任。
有两个陷阱，专门困扰那些在 Home Assistant 本身（而不是它前面的代理）上配置 HTTPS 的人：
- 本地地址也会跟着变。 一旦 Home Assistant 在它的端口上提供 HTTPS，普通的
http://192.168.1.50:8123在该端口上就不再响应了。 - IP 地址与证书不匹配。 为
ha.example.com签发的证书对https://192.168.1.50:8123无效，所以这个本地地址无法通过证书检查。远程一侧使用反向代理或隧道，家里的 Home Assistant 本身保持普通的 http，就能同时避开这两个问题。
在家使用本地地址时，普通的 http 很常见，也没有问题。在隧道本身已加密的 VPN 内，http 也可以接受；在开放的互联网上，请使用 https。
常见错误，以及手表上的提示
出问题时，手表会告诉你是哪一段连接失败了。下表列出与地址有关的提示，以及一条看起来相似、实际无关的提示。
| 在手表上 | 含义 | 解决方法 |
|---|---|---|
| 离线 · 无法连接 Home Assistant · 每 8 秒重试 | 手机无法通过你填写的任何地址访问 Home Assistant | 在手机所在的地方用手机浏览器打开该地址；离家时需要带有效证书的 https |
| 地址不对 · 它有响应，但不是 Home Assistant 的 API | 有东西响应了，但不是 Home Assistant API：通常是地址后面多了 /lovelace 之类的路径 |
只保留服务器地址，后面不要加任何内容 |
| 离线 · 手机没有响应 | 手表连不上手机；与地址无关 | 手机放在附近，开启 Bluetooth，Zepp 应用保持运行 |
| 需要管理员令牌 | 地址没问题，但令牌属于一个没有管理员权限的用户 | 以管理员身份创建长期访问令牌 |
离线 · 无法连接 Home Assistant
横幅先显示离线，然后是无法连接 Home Assistant · 每 8 秒重试，下方还有一行简短的代码，能让技术支持准确知道是哪里出了问题。常见原因有：你离家了，却只有本地地址；手机上的 VPN 没有连接；远程地址在家能用，在外面却不行；手机不信任证书；或者 Home Assistant 本身宕机或正在重启。解决的第一步永远一样：如下文所述，用手机的浏览器打开该地址。故障排除教程的第 3 步在视频中展示了这条提示。
地址不对
地址不对的意思是：地址有响应，但返回的是一个网页，而不是 Home Assistant API。几乎总是因为地址带了路径，通常是从浏览器地址栏复制来的：https://ha.example.com/lovelace/0，而不是 https://ha.example.com。删除服务器地址（及其端口）后面的所有内容即可。在 AmazHA 设置中，连接测试会用自己的话说明同一件事：该地址有响应，但并非 Home Assistant 的 API，并以带和不带 /lovelace 的 Home Assistant Cloud 地址为例。见故障排除第 4 步。较少见的情况是，地址完全通往别的东西，例如路由器的管理页面。
反向代理后面的 400 Bad Request
如果你的远程地址经过反向代理或隧道，而每个请求都返回 400 Bad Request，那就是 Home Assistant 在拒绝这个代理。当它没有被告知要信任反向代理，或者代理的地址不在它的受信任列表中时，它的 HTTP 集成会拒绝任何带有转发标头（forwarded-for）的请求，两种情况的回应都是 400。Home Assistant 的日志会写明请求来自哪个地址；第二种情况下，日志内容是“Received X-Forwarded-For header from an untrusted proxy”，后面跟着那个地址。
在 AmazHA 中，只填一个地址时，连接会显示错误 400；两个都填时，远程旁边会显示红点。
解决方法在 Home Assistant 一侧。在新版本中，HTTP 服务器设置位于用户界面中：设置 › 系统 › 网络，开启 Trust X-Forwarded-For，并在 Trusted proxies 下添加代理的地址或网段。旧版本则在 configuration.yaml 中使用 YAML（下面的地址仅为示例，请换成你的代理的地址）：
http:
use_x_forwarded_for: true
trusted_proxies:
- 192.168.1.10
Home Assistant 的 HTTP 集成文档有各个版本的详细说明。如果你的版本需要，重启 Home Assistant，然后再点按一次连接。
离线 · 手机没有响应
这一条与地址完全无关。手表无法通过 Bluetooth 连接到手机，所以手机根本没有机会去尝试 Home Assistant。请让手机留在附近，开启 Bluetooth，并保持 Zepp 应用运行（故障排除第 2 步）。更改地址解决不了这个问题。
Home Assistant 自己的外部 URL 设置
Home Assistant 有自己的 Home Assistant URL（Home Assistant 网址）设置，位于设置 › 系统 › 网络下，包含 Internet（互联网）和 Local network（本地网络）两个字段。它们告诉 Home Assistant 及其自家应用它位于何处。AmazHA 不会读取它们：它只使用填写在它自己设置中的两个地址。如果你在 Home Assistant 中更改了外部 URL，而手表没有跟着变，原因就在这里。把新地址复制到远程 URL 中即可。
先用手机的浏览器测试
在 AmazHA 中更改任何东西之前，先在同一部手机、同一个地方的浏览器中打开这个地址。这是最快的测试，因为它走的是和 AmazHA 相同的路径：手机、它当前的网络、你的地址。
- 如果你在家测试远程地址，先关闭手机的 Wi-Fi，让请求真的经由移动数据发出。如果远程地址需要 VPN，就打开 VPN。
- 输入你在 AmazHA 中填写的完全相同的地址，例如
https://ha.example.com。 - 查看结果。
| 浏览器显示 | 说明了什么 |
|---|---|
| Home Assistant 的登录页面 | 地址和证书都没问题：问题在别处（路径、令牌、Bluetooth） |
| 证书警告 | 手机不信任该证书；按现状，AmazHA 无法使用这个地址 |
| 什么都没有，或者“无法访问此页面” | 手机从这个网络无法访问该地址 |
| 400 Bad Request | 一个 Home Assistant 尚未信任的反向代理 |
| 另一个页面（路由器、服务提供商、代理的默认页） | 该地址通往别的地方 |
对于本地地址，在家打开 Wi-Fi，同样测试一遍。如果浏览器能打开登录页面，而 AmazHA 仍然失败，请检查字段中是否只有服务器地址、后面没有任何内容，并且协议与浏览器所用的相同。
你也可以在浏览器中给地址加上 /api/。由于浏览器没有发送令牌，Home Assistant 会返回一个关于身份验证的错误：这证明该地址通往的是 Home Assistant API，而不是别的什么页面。在 AmazHA 中填写地址时，不要加 /api/。
AmazHA 中的连接测试：解读 LAN 和远程
AmazHA 设置中的连接会在手机上测试这些地址，并告诉你它发现了什么。点按之后，几秒钟内就会出现结果：
- 只有一个地址时： Home Assistant 有响应时显示已连接 ✓；没有任何响应时显示无法访问；有东西以 HTTP 错误响应时，显示错误加一个数字（例如错误 400或错误 401）；地址以不是 API 的东西响应时，显示有响应，但不是 Home Assistant。
- 两个地址都有时： 每个地址一个结果，即 LAN 和远程，各带一个彩色圆点：Home Assistant 在那里有响应时为绿色，有东西响应但不是 Home Assistant 时为橙色，失败时为红色。
解读时要考虑手机所处的位置。在家时，红色的远程可能是正常的（一个不能在家庭网络内部回环的域名、一个关着的 VPN），也可能是真有问题，所以请关闭 Wi-Fi 再测一次。离家时，红色的 LAN 是意料之中的；那里只有远程才重要。在家测一次、用移动数据再测一次，两次都是绿色，这样的设置走到哪里都能用。连接 Home Assistant 教程的第 8 步展示了这个界面。
如果地址没问题，但令牌来自一个没有管理员权限的用户，连接会在结果下方说明这一点。那是令牌的问题，不是地址的问题：地址测试能通过，但在令牌换成管理员的之前，手表无法加载你的房间。
四种设置，逐一拆解
同样的两个字段，能适应非常不同的家。下面是四个例子，所用地址均为示例：
一套公寓，只在家使用。 本地 URL (LAN)：http://192.168.1.50:8123。远程 URL：留空。手表在家里的 Wi-Fi 上能用；在外面会显示离线 · 无法连接 Home Assistant，这是意料之中的。在家时，连接显示已连接 ✓。
Home Assistant Cloud。 本地 URL (LAN)：http://192.168.1.50:8123。远程 URL：https://xxxxx.ui.nabu.casa。在家时 AmazHA 使用本地地址；使用移动数据时，它会自动切换到 Home Assistant Cloud 地址。连接会显示 LAN 和远程，在家时两者都是绿色，因为云地址在内部也能用。
手机上的 VPN。 本地 URL (LAN)：http://192.168.1.50:8123。远程 URL：服务器在 VPN 内的地址，如果服务器在那里以普通 http 响应，就在前面写上 http://。在家时本地地址胜出。离家时，VPN 连接着，远程地址胜出；VPN 关闭时，手表会显示离线横幅，直到 VPN 重新打开。
反向代理后面的自有域名。 本地 URL (LAN)：http://192.168.1.50:8123。远程 URL：https://ha.example.com。要让它工作，Home Assistant 必须信任这个代理（Trust X-Forwarded-For、Trusted proxies），否则每个远程请求都会得到 400。请关闭 Wi-Fi 测试远程地址：有些路由器不会把你自己的域名路由回内部，所以在家时红色的远程并不总是意味着在外面也会失败。
出门前的检查清单
在家花五分钟，以后就不用对着手表一脸困惑：
- 本地 URL (LAN) 中只有服务器地址，也就是你在家时浏览器用的那个。
- 远程 URL 中只有远程地址：不要
/lovelace，需要端口时带上端口，经由互联网时用https://。 - 手机的浏览器在关闭 Wi-Fi 时能打开远程地址，并显示 Home Assistant 登录页面，没有证书警告。
- 如果用的是 VPN：VPN 已设置为在手机上保持连接。
- 如果用的是反向代理或隧道：Home Assistant 信任它，所以不会出现 400。
- 连接显示 LAN 和远程均为绿色，或者只有一个地址时显示已连接 ✓。
- 令牌来自管理员，并且两个地址用的是同一个令牌。
做完这些，手表在家时会使用本地地址，在其他任何地方使用远程地址，你什么都不用做。如果哪天它显示离线，第二行会告诉你该查哪一边：手机没有响应是 Bluetooth 的问题，无法连接 Home Assistant 是地址的问题。