ファイアウォール・ポート・プロキシ
Filemote が張るのは外向きの接続だけです。外からあなたのマシンへ呼びかけるものはないので、 ルーターで転送するものも、家庭用ファイアウォールで開けるものもありません。ネットワークが Filemote を止めているなら、止めているのは出口であって入口ではありません。
実際にある接続
| どこから | どこへ | ポート | 何のため |
|---|---|---|---|
| エージェント | api.filemote.com | 443 (HTTPS) | すべて：一覧、転送、AI の中継 |
| ブラウザー | filemote.com, api.filemote.com | 443 (HTTPS) | Web アプリ |
| AI サービス | 外へは出ない | —— | ローカルでのみ待ち受け |
AI サービスが使うのはそのマシン上のポート 8765 です。これはループバックのポートであって ネットワークのポートではありません。マシンの外からは届かず、ファイアウォールの規則も要りません。 問題になるのは、同じマシンの別の何かがすでにそのポートを取っているときだけで、それは AI が読み込まれないで扱います。
アドレスもポートもひとつ
Filemote はホスト型のサービスです。エージェントは最初から api.filemote.com のポート 443（あらゆる HTTPS サイトと同じポート）に接続するよう設定されているので、ポートを選ぶ必要も、誰かに確認する必要もありません。
試しにエージェントの設定でサーバーのアドレスを変えた場合は、元に戻してください。Filemote 以外のアドレスはオフラインのデバイスとまったく同じに見えます。実際にオフラインだからです。
エージェントが動いているマシンから試す
エージェントが動いているマシン自体から確認してください——手元のノート PC や、別のネットワークにいるスマートフォンからではありません：
curl -sS -o /dev/null -w '%{http_code}\n' https://api.filemote.com/health
ステータスコードが返れば出口は開いています。タイムアウトや接続エラーなら開いておらず、エージェント でも結果は同じです。
Windows では Test-NetConnection api.filemote.com -Port 443 が同じことを尋ねます。
企業ネットワーク
遮断が実際に起きるのはここです。ありがちな順に：
- ホスト名による送信フィルター。 ポート 443 はほぼどこでも開いていますが、承認済みのサイトにしか接続させないネットワークもあります。その場合は
api.filemote.comをリストに加えてもらう必要があります。 - 認証を要求するプロキシ。 エージェントは直接つなぎ、システムのプロキシ設定を読みません。 プロキシ経由のみ許すネットワークでは遮断されます。
- TLS の検査。 ネットワークによっては TLS をいったん終端し、自前の証明書で署名し直します。 うまくいくかどうかは、そのマシンがその証明書を信頼しているか次第です。
ネットワーク管理者への依頼は短く具体的です：このマシンから api.filemote.com への送信方向の HTTPS（TCP 443）を許可してください。受信ルールもポート転送も DMZ も不要です。
家庭のネットワーク
することはほぼありません。接続はエージェントの側から始まるので、ふつうのルーターの内側で手を加え ずに動きます。
例外が 2 つあります：
- セキュリティ製品の中には外向き接続を横取りし、初回に確認を出すものがあります。
FilemoteAgentを許可してください。 - 端末どうしを隔離するゲストネットワークでも、外向きのインターネットは通るのがふつうなので、 たいてい問題ありません。
決して必要でないもの
- ポート転送。
- エージェントを動かすマシンの固定 IP やダイナミック DNS。
- 受信方向のファイアウォール規則。
- 自分と自分のマシンのあいだの VPN。
Filemote のためにこれらを求める手引きがあれば、それは Filemote の話をしていません。
それでもつながらないとき
デバイスがオフラインと表示されるをたどって ください。ネットワークの問題はその 3 番目で、上の 2 つのほうがよくある原因です。
2026-10-16 に更新