丸一日溶かしたNature Remo mini「登録中です」問題の原因は「0」と「1」の1文字だった

TL;DR

• NURO光 10G開通後、Nature Remo miniのセットアップが「登録中です」「ダウンロード中 0%」で止まった
• Wi‑Fi設定、ケーブル、アプリ、ネットワーク構成まで一通り疑い、PerplexityやClaudeにも相談しながら丸一日トラブルシューティングした
• 最終的な結論は「ONUとの相性問題、市販ルーターを買え」だった
• 実際の原因は、ONUのDHCPで配布するDNSサーバが 192.168.1.1 のままだったこと。LAN側は 192.168.0.1 に変更済みだった
• 間違っていたのは 0 と 1 の1文字だけ

環境

役割	機器
回線	NURO光 10G
ONU	ZTE F2886Q
スイッチ	Allied Telesis x510-28GTX
AP	Buffalo WSR300HR（APモード、2.4GHz）
対象	Nature Remo mini（NR5W1、2.4GHzのみ）
スマホ	iPhone 17 Pro Max（iOS 27.0）

ZTE F2886Q → x510-28GTX → WSR300HR → Nature Remo mini

既存のホームラボが 192.168.0.0/24 で動いていたため、NURO開通時にONUのLAN側IPを初期値の 192.168.1.1 から 192.168.0.1 に変更していた。これが伏線。

症状

Nature Homeアプリでセットアップすると、次の状態で止まる。

• 「登録中です」のまま5分以上進まない
• 「ダウンロード中 0%」から進まない
• 最終的に「接続エラー、応答がありません」

試したこと（全部効かなかった）

本体

• リセットボタン長押しでの初期化（5秒、10〜15秒）
• USBケーブルの抜き差し（10秒、30秒、1分以上放置）

アプリ・iPhone

• アプリの再起動、削除して再インストール
• iPhoneの再起動
• ローカルネットワーク権限の確認

ONU（ZTE F2886Q）のWi‑Fi

• 帯域幅を「自動」から20MHz固定に
• セキュリティを「WPA/WPA2 (TKIP/AES)」からWPA2-PSK (AES)に
• チャネルを「自動」から1/6/11固定に
• AP分離がオフであることを確認
• iPhoneが6GHzで繋がっていないか確認

Buffalo AP

• APモード、2.4GHzのみ、20MHz、WPA2-PSK (AES) を確認

ネットワーク構成

• x510をバイパスして、ONUとAPを直結
• ファイアウォールレベルを低に、フィルター類はすべて無効

どれも結果は同じ「登録中です」だった。

唯一の手がかり：テザリングだと通る

iPhoneのテザリングに繋ぐと、セットアップは普通に通った。

さらに、ONUの管理画面にはRemo（espressif のMACアドレス）が 192.168.0.2 で載っていた。つまり、

• Wi‑Fiへの接続：OK
• DHCPでのIP取得：OK
• iPhoneとRemoのローカル通信：OK
• クラウドへの到達：NG

という状態だった。

ここでAIと一緒に出した結論は「ZTE F2886QのNAT、ファイアウォール、DNSのどこかがNature Remoと相性が悪い」。対策は「市販Wi‑Fiルーターをルーターモードで挟む」。要するに機材を買えだった。

原因

買う前にONUの設定をもう一度見直したら、あった。

項目	値
LAN側IPアドレス	192.168.0.1
DHCPで配布するプライマリDNS	192.168.1.1

LAN側のIPは変えたのに、DHCPで配布するDNSが 192.168.1.1 のままだった。192.168.0.1 に直したら、一発でセットアップが通った。

LANのIPアドレスを変えても、DHCPで配布するDNSが自動で追従するとは限らない。

何が起きていたのか

1. RemoはDHCPで次の情報を受け取る
   • IP：192.168.0.2
   • ゲートウェイ：192.168.0.1
   • DNS：192.168.1.1
2. Remoは 192.168.1.1 に名前解決を問い合わせる。しかしこのアドレスには誰もいない。サブネット外なのでゲートウェイ経由で外に出ていき、返事は来ない
3. 名前解決ができないので、Natureのクラウドに接続できない
4. その結果、「登録中です」で止まる

Remoのセットアップは、大まかに次の2段階で進む。

1. iPhoneからRemoへ、Wi‑Fi情報をローカルで渡す
2. Remoがクラウドに登録し、ファームウェアを取得する

1段目はDNSを使わないので成功する。これが「ローカルは通っているのにクラウドだけダメ」という、いかにも相性問題っぽい症状を作っていた。

テザリングで通ったのは、iPhoneのテザリングが配るDNS（iPhone自身）が正しく動いていたから。ONUを経由しなかったから通ったわけではない。

なぜiPhoneやPCは普通に使えていたのか

ここが気づくのを一番遅らせた点。同じONUに繋いでいるiPhoneでは、Webも普通に見られていた。

おそらく、iPhoneはIPv6側のDNSやiCloudプライベートリレー（暗号化DNS）で名前解決できていた。IPv4側のDNSが壊れていても、スマホやPCは別の経路で名前解決を済ませてしまう。

一方、ESP32ベースのRemo miniは、IPv4とDHCPで配られたDNSにしか頼れない。スマホは生きているのにIoT機器だけ死ぬという状況は、IPv4のDNS設定を疑う価値がある。

教訓

• LANのIPを変えたら、DHCPの設定（ゲートウェイ、DNS、プール範囲）をセットで見直す
• 「スマホは使えるのにIoT機器だけダメ」なら、IPv4側のDNSを疑う
• 「テザリングなら通る」は、ONUとの相性の証拠ではない。DHCPで配られる設定が違うという手がかりでもある
• AIに相談すると、症状の説明に筋の通った仮説（相性問題）がどんどん積み上がる。前提となる設定値そのものを疑うのは、結局自分の仕事だった
• 高度な切り分けに入る前に、管理画面の値を1行ずつ読む

丸一日かけて、Wi‑Fiの帯域幅からスイッチのバイパスまで試した。結局、間違っていたのは 0 か 1 かだけだった。