企業プロキシの背後で

多くの工場ネットワークや企業ネットワークでは、企業の HTTP プロキシ（例：ポート 3128 の Squid プロキシ）経由でしかインターネットに到達できません。IronFlock アプライアンスはこの構成でも問題なくインストール・動作します — インストールコマンドでプロキシを指定すれば、それ以外の設定はすべて ironflock appliance install が行います。

このページでは、アプライアンスホストにプロキシ環境変数が一切設定されていないことを前提とします — プロキシは明示的に指定してください。インストールが自動的に処理する内容と、TLS を傍受するプロキシで必要となる 1 つの追加手順について説明します。

これは、アプライアンスガイドのファイアウォールの設定セクションのプロキシ版コンパニオンです。到達可能でなければならない IronFlock エンドポイントは同じです — 違いは、ここではそれらにプロキシ経由で到達するという点です。

プロキシに注意が必要な理由

IronFlock プラットフォームのイメージは Docker デーモンによってプルされます — これはシェルとは別の、独自のネットワーク設定を持つバックグラウンドサービスです。プロキシ経由でインターネットに到達できるホスト上であっても、明示的に伝えない限り、デーモンはプロキシの存在を知りません。設定しないままだと、デーモンは直接接続を試み、ネットワークがそれをブロックし、インストールはタイムアウトとともにログインのステップで停止します。


Error response from daemon: Get "https://instance-registry.ironflock.com/v2/":
net/http: request canceled while waiting for connection (Client.Timeout exceeded)

インストールが自動的に処理する内容

インストールコマンドでプロキシを指定すると、ironflock appliance install が Docker デーモンとホストのデバイスエージェントを設定します — プロキシ設定を root だけが読める /etc/ironflock/proxy.env に保存し、Docker とエージェントをそのファイルに向け、IronFlock レジストリに到達できるよう Docker を再起動します。このステップは以下の特徴を持ちます。

手間いらず — プロキシを一度指定するだけで（下記参照）、インストールが設定を書き込み、Docker を再起動してくれます。手動でのデーモン設定は不要です。
完全にスキップ — プロキシが指定されない場合は何も行いません。インターネットに直接接続するインストールには影響しません。

インストールはさらに、アプライアンス自身のクラウドへの接続もプロキシ経由にルーティングします — ライセンス検証と、ironflock.com からインスタンスに到達できるようにするリモート管理アップリンクです。プロキシはアプライアンスの中央設定ファイル /opt/ironflock/.env に記録され、プラットフォームはそれを自動的に使用します。以降のすべてのアップデートでも、この設定は保たれます（後からプロキシを変更または削除するを参照）。アプライアンスをオンラインにするために別途の設定は必要ありません。

プロキシの背後でインストールを実行する

プロキシは 2 か所で必要になります：インストールスクリプトが ironflock をダウンロードするために必要であり、ironflock appliance install が Docker を設定するために必要です。プロキシ URL を一度設定し、curl には --proxy で、インストールスクリプトには環境変数として渡し、続いて ironflock appliance install には --http-proxy / --https-proxy で渡します。


# 御社の企業プロキシ — この行を編集してください
PROXY="http://proxy.your-company.com:3128"
 
curl -fsSL --proxy "$PROXY" https://instance-registry.ironflock.com/dl/cli/install.sh \
  | sudo env HTTP_PROXY="$PROXY" HTTPS_PROXY="$PROXY" bash
 
sudo ironflock appliance install --license-file license.txt \
  --http-proxy "$PROXY" --https-proxy "$PROXY"

プロキシ URL をご自身のものに、license.txt を Instance Key を含むファイルに置き換えてください（インストールを参照）。プロキシがログインを必要とする場合は、プロキシ認証を参照してください。パスワードは URL に含めません。

ironflock appliance install のプロキシフラグ：

フラグ	用途
`--http-proxy <url>`	Docker、エージェント、アプライアンスのプレーン HTTP トラフィック用プロキシ。`""` で削除します。
`--https-proxy <url>`	HTTPS トラフィック用プロキシ（イメージのプルで重要となるのはこちら）。`""` で削除します。
`--no-proxy <list>`	プロキシをバイパスすべき追加のホスト（カンマ区切り）。
`--proxy-password-file <file>`	プロキシ URL に記載したユーザーのパスワードを 1 行で含むファイルまたはパイプ（`/dev/stdin`）。

sudo はシェルのプロキシ変数を ironflock に引き継がないため、プロキシはフラグで指定してください。コマンドのそのほかのフラグは ironflock appliance install で説明しています。

ローカルトラフィックは常にプロキシをバイパスします

NO_PROXY を手動で管理する必要はありません。インストールは常に localhost、127.0.0.1、およびアプライアンス自身のホストアドレスをプロキシ対象外に保ちます（--no-proxy で渡したものは保持され、マージされます）。これにより、アプライアンスのローカルアプリストアとレジストリには企業プロキシ経由でルーティングされることなく、直接到達されます。

プロキシ認証

プロキシがログインを必要とする場合は、個人のアカウントではなく、アプライアンス専用のサービスアカウントを割り当ててください。そうすれば、アプライアンスのトラフィックはネットワークチームが管理する名前でプロキシのログに記録されます。ネットワークチームは、そのアカウントがアクセスできる範囲を制限したり、誰かの個人ログインに影響を与えることなく無効化やパスワードのローテーションを行ったりできます。これは IronFlock ホストのネットワーク ID のプロキシ側にあたる設定です。

サポート対象：Basic 認証。 プロキシ URL にはユーザーを記載し、パスワードは --proxy-password-file（パスワードを 1 行で含むファイル、または /dev/stdin）で渡します。ホストのすべてのユーザーがコマンドラインを読めるため、ironflock はパスワードを含むプロキシ URL を拒否します。アプライアンスはパスワードを root だけが読めるファイルに保存するため、その後ファイルは削除してかまいません：
```
sudo ironflock appliance install --license-file license.txt \
  --https-proxy "http://[email protected]:3128" \
  --proxy-password-file proxy-password.txt
```
現時点では未サポート：Windows 統合認証（Kerberos、NTLM）。プロキシがそれ以外の方式を受け付けない場合は、サービスアカウントに Basic 認証を許可するか、アプライアンスのアドレスを名前付きホストとして認証なしで許可するよう、ネットワークチームに依頼してください。

トラフィックについては、ネットワークチームに次のように伝えてください。

通信先はファイアウォールの設定に列挙されたエンドポイントのみで、ポート 443 の HTTPS を使用します。ポート 2525 のメールリレーがプロキシを経由することはありません。
cbw.ironflock.com へのリモート管理接続は、数秒ごとにキープアライブ通信を行う長時間維持される WebSocket です。プロキシが一定時間後に長時間接続を切断する場合、アプライアンスは数秒以内に自動的に再接続しますが、リモートユーザーはそのたびに短い中断に気づくことがあります — 可能であれば、この接続を接続時間の制限対象から除外してください。

後からプロキシを変更または削除する

プロキシはアプライアンスの中央設定ファイル /opt/ironflock/.env に記録されており、すべてのアップデートで保たれます。インストール済みのアプライアンスでプロキシを変更するには、ironflock appliance configure を使います。このコマンドは設定を Docker デーモン、プラットフォームサービス、デバイスエージェントに適用し、何かが変わった場合にだけアプライアンスを再起動します。


# 別のプロキシに切り替える
sudo ironflock appliance configure --https-proxy "http://proxy2.your-company.com:3128"
 
# プロキシをバイパスするホストを変更する
sudo ironflock appliance configure --no-proxy "buildserver.corp.example.com"

各設定は独立しています：指定しなかった設定はアプライアンスの現在の値を保つため、--https-proxy だけを渡しても、既存の NO_PROXY リストはそのまま保持されます。

プロキシを削除するには — たとえばアプライアンスをインターネットに直接接続できるネットワークへ移設した後など — 空のプロキシを渡します。


sudo ironflock appliance configure --http-proxy "" --https-proxy ""

プロキシ設定は Docker デーモンとデバイスエージェントから再び取り除かれ、アプライアンスは直接接続に戻ります。NO_PROXY リストは、後で再度有効化する場合に備えて保持されます。

ログインが必要なプロキシは、現時点では configure で設定できません： ironflock appliance configure はプロキシのパスワードを受け付けません。--proxy-password-file を受け付けるのは ironflock appliance install だけです。インストール済みのアプライアンスで実行すると、appliance install は指定したオプションにアプライアンスを合わせ、シークレットと設定は保ちます（再実行）。そのため、新しいプロキシをパスワードとともに設定できます。


sudo ironflock appliance install --version <version> \
  --https-proxy "http://[email protected]:3128" \
  --proxy-password-file proxy-password.txt

--version には、アプライアンスが実行しているバージョン（ironflock status で表示されます）を指定します。指定しないと、この実行はアプライアンスをそのチャネルの最新リリースにも更新します。インストール済みのアプライアンスは Instance Key を保持しているため、--license-file は不要です。

エッジデバイス

上記の内容はすべて、ironflock agent install で接続するエッジデバイスにも同様に当てはまります。このコマンドは同じプロキシフラグを受け取ります。実行時にプロキシを渡せば、ダウンロード（パッケージマネージャ、Docker のインストール、エージェントのダウンロード）、Docker デーモン、デバイスエージェントをプロキシ経由でルーティングしてくれます。


sudo ironflock agent install -c mydevice.flock \
  --http-proxy "$PROXY" --https-proxy "$PROXY"

ironflock をダウンロードするインストールスクリプトはそれより前に実行されるため、この手順にもプロキシを渡してください。sudo は既定ではシェルのプロキシ変数を引き継がないので、明示的に渡し、プロキシのフラグを ironflock agent install にも渡します。


curl -fsSL --proxy "$PROXY" https://instance-registry.ironflock.com/dl/cli/install.sh \
  | sudo env HTTP_PROXY="$PROXY" HTTPS_PROXY="$PROXY" bash -s -- agent install -c mydevice.flock \
      --http-proxy "$PROXY" --https-proxy "$PROXY"

デバイスがクラウドではなくローカルのアプライアンスアプリストアからアプリイメージをプルする場合は、そのレジストリのホストを --no-proxy で追加し、それらのプルがローカルネットワーク上にとどまるようにしてください。

プロキシにログインが必要な場合、 デバイスではパスワードをプロキシ URL に含めません。デバイスのすべてのユーザーがコマンドラインを読めるため、ironflock はパスワードを含む URL のプロキシフラグを拒否します。URL にはユーザーを記載し、パスワードは 1 行で記載したファイルに保存します：


sudo ironflock agent install -c mydevice.flock \
  --https-proxy "http://[email protected]:3128" \
  --proxy-password-file proxy-password.txt

デバイスはパスワードを root だけが読める /etc/ironflock/proxy.env に保存するため、パスワードのファイルは後で削除してかまいません。

Windows デバイスではエージェントは Windows サービスとして動作します。プロキシはサービスのインストーラーに渡してください — プラットフォームへの接続とエージェントの自動更新の両方に適用されます：


.\device-agent.exe service install -config .\myaccount_myproject_mydevice.flock -proxy "http://proxy.example.com:3128"

どのホストがプロキシを迂回するか

NO_PROXY が照合するのはクライアントが接続しようとするホスト名であり、その名前が解決されるアドレスではありません。デバイスが名前で到達するアプライアンス — つまりドメインモードのすべてのアプライアンス、アプリ UI と HTTPS を参照 — は、明示的に指定する必要があります。そうしないとエージェントはローカルのアプライアンスへの接続を社内プロキシ経由で送ってしまい、多くのプロキシは社内ネットワークへ折り返すルーティングを拒否するため、デバイスは決してオンラインになりません。

インストーラーはこれをデバイス自身の .flock から判断します。localhost と 127.0.0.1 に加えて、アプライアンスのドメインを — 先頭にドットのない形と付いた形の両方で — さらに TLS なしで接続するレジストリホストを追加します。クラウドデバイスにはループバックの 2 エントリ以外は追加されません。エンドポイントが公開されており、プロキシが実際に必要だからです。

サイト固有のその他のホストは、ironflock agent install の --no-proxy フラグに対応する -no-proxy で指定します：


.\device-agent.exe service install -config .\myaccount_myproject_mydevice.flock `
  -proxy "http://proxy.example.com:3128" `
  -no-proxy "buildserver.corp.example,10.0.0.0/8"

後から設定を変更する

結果は %ProgramData%\IronFlock\DeviceAgent\proxy.env に書き込まれ、それ以降はこのファイルが正となります：


HTTP_PROXY=http://proxy.example.com:3128
HTTPS_PROXY=http://proxy.example.com:3128
NO_PROXY=localhost,127.0.0.1,appliance.corp.example,.appliance.corp.example

編集したうえで .\device-agent.exe service install を再実行すると反映されます。以後のインストールがこのファイルを上書きすることはありません。また service uninstall はエージェントディレクトリを残すため、サービスの再インストールに必要なアンインストール／インストールのサイクルを経ても設定は保持されます。フラグの値でファイルを意図的に置き換えるには -force-proxy を使ってください。

エージェント 1.4.0 より前にインストールされた Windows デバイスでは、エージェントがデバイスを新しいレイアウトへ移行するまで、フォルダーは引き続き %ProgramData%\IronFlock\Reagent です。

このサイトがアプライアンスへプロキシ経由で到達する場合は、該当エントリを削除してください。 どちらの構成も実在します。同じ工場 LAN 上のアプライアンスには直接到達しますが、中央でホストされたアプライアンスには社内プロキシ経由でしか到達できないことがあります。インストーラーは両者を区別できないため、ホストをそのまま書き出します — ご自身のネットワークに当てはまらないものは削除してください。

Docker は別途設定します

Docker Desktop は proxy.env もサービス環境も読みません。イメージを取得するのは Docker デーモンで、Settings → Resources → Proxies に独自の設定と独自の除外リストを持ちます — そのリストにもアプライアンスのホストが必要です。エージェント側でプロキシを直しても docker pull は直りません。

Linux デバイス

ironflock agent install は --no-proxy を直接受け付けるため、セットアップ時にアプライアンスを指定できます：


sudo ironflock agent install -c mydevice.flock \
  --http-proxy "$PROXY" --https-proxy "$PROXY" \
  --no-proxy "appliance.corp.example.com"

localhost、127.0.0.1、::1 は常にプロキシを迂回します。デバイスの .flock ファイルに記載された更新サーバーも、IronFlock クラウドのホストでない場合はプロキシを迂回します。アプライアンスのデバイスがこれに当たります。

設定は、root だけが読める /etc/ironflock/proxy.env に保存されます。Docker とデバイスエージェントは、どちらもここから設定を読み込みます。後から変更するには、ironflock agent configure を使います。指定したフラグはそれぞれの設定を置き換え、それ以外の設定はそのまま残ります：


# プロキシを迂回するホストを変更する
sudo ironflock agent configure --no-proxy "appliance.corp.example.com,buildserver.corp.example"
 
# 別のプロキシに切り替える
sudo ironflock agent configure --https-proxy "http://proxy2.your-company.com:3128"
 
# デバイスのプロキシ設定を解除する
sudo ironflock agent configure --remove-proxy

このコマンドは、変更の前と後の設定を表示します。設定を反映するには Docker の再起動が必要で、その間デバイス上のアプリが一時的に停止するため、コマンドは先に質問します。独自の systemd ドロップイン（systemctl edit）にあるプロキシ変数は、設定ファイルが同じ変数を設定すると効かなくなります。コマンドは、そのようなドロップインがあると警告します。詳細は ironflock agent configure を参照してください。

ironflock より前にセットアップされたデバイスは、プロキシを http-proxy.conf という名前の systemd ドロップインに保持しています。このファイルは、パスワードを含めてデバイスのすべてのユーザーが読めます。ironflock agent configure を初めて実行すると、設定が /etc/ironflock/proxy.env に移されます。

2026 年 10 月より前にインストールされたデバイスでは、エージェントが新しい構成へ移行するまで、ユニットは引き続き reagent.service です（ドロップインのディレクトリは reagent.service.d）。

TLS 傍受型プロキシ（企業 CA）

一部の企業プロキシは、会社の認証局（CA）で再署名することで HTTPS トラフィックを検査します。これらの場合、プロキシの設定は必要ですが十分ではありません — アプライアンスホストもその CA を信頼していなければならず、そうでないとすべてのクラウド接続（イメージのプル、ライセンス検証、管理アップリンク）が拒否されます。

CA はホストのシステム信頼ストアに一度だけインストールしてください。アプライアンスはその信頼ストアをすべてのコンテナにマウントするため、Docker とすべての IronFlock サービスが CA を取得します — コンテナごと・サービスごとに設定するものは何もありません。コンテナは起動時にこれを読み込むため、CA を追加または変更した後はスタックを再起動してください（下記のステップ 3）。

1. 企業 CA を入手する

ネットワークチームに、プロキシの**「SSL 検査」/「TLS 傍受」ルート CA**（管理対象の社内マシンにすでに配布されているものと同じ証明書）を .crt ファイルとして依頼してください。これが最もクリーンな入手元です。

単一ホストの証明書ではなく、発行元の CA をインストールしてください。 よくある間違いは、1 つのホスト名（例：instance-registry.ironflock.com のみ）に対してプロキシが再署名した証明書を保存してしまうことです。これではそのホストだけが動作し、それ以外のすべてのクラウドホストは失敗したままになります。必要なのは、それらの証明書に署名する CA です。

ファイルを直接入手できないものの、プロキシがフルチェーンを提示する場合は、通信経路から CA を抽出できます — <PROXY_HOST>:<PROXY_PORT> をご自身のプロキシに置き換えてください。


# チェーンを取得します（証明書ごとに 1 つの PEM）。c1 はホストごとのリーフ証明書です（スキップしてください）。
# c2..cN が信頼すべき企業 CA チェーンです。
echo quit | openssl s_client -connect instance-registry.ironflock.com:443 \
  -proxy <PROXY_HOST>:<PROXY_PORT> -showcerts 2>/dev/null \
  | awk '/BEGIN CERTIFICATE/{n++; c=1} c{print > ("/tmp/proxy-c" n ".pem")} /END CERTIFICATE/{c=0}'
 
# 任意 — 返ってきた内容を確認します：
for f in /tmp/proxy-c*.pem; do echo "== $f =="; openssl x509 -in "$f" -noout -subject -issuer; done

2. インストールして信頼ストアを再構築する

IT チームから .crt を直接受け取った場合：


sudo cp corporate-root-ca.crt /usr/local/share/ca-certificates/corporate-proxy-ca.crt
sudo update-ca-certificates

上記のチェーンから抽出した場合は、リーフ証明書（c1）を除くすべての証明書を信頼します：


i=0; for f in $(ls -v /tmp/proxy-c*.pem | tail -n +2); do
  i=$((i+1)); sudo cp "$f" "/usr/local/share/ca-certificates/corporate-proxy-ca-$i.crt"
done
sudo update-ca-certificates

3. 検証する

これで、すべての IronFlock クラウドホストがプロキシ経由で検証できるはずです — TLS エラーではなく、HTTP ステータスが返ります。


for H in instance-registry.ironflock.com web.ironflock.com cbw.ironflock.com \
         registry.ironflock.com regauth.ironflock.com; do
  curl -x http://<PROXY_HOST>:<PROXY_PORT> -sS -o /dev/null -w "$H -> %{http_code}\n" "https://$H/"
done

5 つすべてで 200、401、404 のようなコードが返れば、CA は正しいです。その後、サービスが反映できるようアプライアンスを再起動します。インストールがログインのステップで止まっていた場合は、代わりに同じインストールコマンドをもう一度実行してください。止まったところから続行します。


sudo ironflock appliance restart

デバイスユーザーインターフェースへのリモートアクセス

IronFlock では、エッジデバイスやマシン上で動作するユーザーインターフェース — マシンの HMI、PLC ページ、デバイス上の設定画面やダッシュボード画面 — を、どこからでも IronFlock 内で直接開くことができます。これはリモートサービスおよびサポートを可能にする重要な機能です：エンジニアは現地に赴くことも、ローカルネットワークに接続することもなく、マシンのインターフェースに到達できます。アクセスは常に IronFlock の権限システムによって仲介・保護されるため、認可されたユーザーのみが特定のデバイスに到達できます。

このリモートアクセストンネルは、成熟し広く使われているオープンソース技術である **frp（Fast Reverse Proxy）**の上に構築されています。IronFlock はこれを、上記のデバイスインターフェースアクセスを提供する目的のみに使用します。

企業プロキシが妨げになり得る理由

frp は強力なネットワークトラバーサル機能を備えており、そのためアンチウイルスやプロキシのセキュリティ製品は、しばしばこれを一律にリスクウェアとしてフラグします — 長い実績を持つオープンソースコンポーネントとして安全であり、ここでは認可されたリモートアクセス機能のためだけに使われているにもかかわらず、です。これが起こると、プロキシは frp を含む IronFlock コンポーネントのダウンロードをブロックします。

これはアプライアンスを壊すものではありません：リモートアクセストンネルは任意の機能であるため、そのコンポーネントがブロックされても、プラットフォームは通常どおりインストール・動作し、単にデバイスインターフェースアクセスなしで稼働します。ダッシュボードでは、デバイスのリモートアクセス制御が、このアプライアンスではリモートアクセスが利用できない旨を表示します。

企業 IT が許可すべきこと

御社が IronFlock のリモートサービス機能を活用したい場合は、frp を含む IronFlock コンポーネントが企業プロキシ経由でダウンロードできるよう許可する必要があります。ネットワーク／セキュリティチームには、具体的に次の 2 点を依頼してください。

instance-registry.ironflock.com からのイメージダウンロードに対するスキャンの例外設定 — 一律のリスクウェア判定によってトンネルコンポーネントがブロックされないようにするためです。これは IronFlock のすべてのトラフィックを TLS 検査から除外するよりも範囲の狭い対応であり、アプライアンスのそれ以外のトラフィックは引き続き検査の対象にしておけます。
検出を既知の誤検知として記録すること。 frp は広く使われているオープンソースのリバースプロキシであり、IronFlock はこれを、上記で説明したアクセス制御付きのリモートアクセス機能のためだけに使用しています。

アプライアンス向けにすでに列挙されているものと同じ IronFlock エンドポイントが適用されます — ファイアウォールの設定を参照してください。ここでの話は、そのトラフィックを単にルーティングすることに加えて、それをスキャン／ブロックしないようにするという点です。

frp の通過が許可されたら、次のアップデートがダウンロードを再試行し、成功次第、他に何の変更もなく機能が有効になります。すぐに試すには、アプライアンスが実行しているバージョン（ironflock status で表示されます）を指定してインストールを再実行します。シークレットと設定は保たれます。


sudo ironflock appliance install --version <version>

リモートアクセスなしで実行する

デバイスインターフェースアクセスが不要な場合 — あるいはプロキシの例外設定を手配する間、クリーンなインストールを行いたい場合 — は、トンネルを明示的に無効化できます。それ以外はすべて通常どおりインストールされます。


# インストール時に
sudo ironflock appliance install --license-file license.txt --no-tunnel
 
# または、すでにインストール済みのアプライアンスで
sudo ironflock appliance configure --no-tunnel

この選択はアップデートをまたいで記憶されます。あとで（frp が許可されたら）--tunnel で再度有効化できます。


sudo ironflock appliance configure --tunnel

トラブルシューティング

インストールが Client.Timeout エラーとともに instance-registry.ironflock.com へのログインで停止する。 Docker デーモンがレジストリに到達できていません。ironflock appliance install を再実行し、上記のように --http-proxy / --https-proxy でプロキシを渡してください。

プロキシを設定してもログインが依然として失敗する。 プロキシが TLS を傍受している可能性が高いです。TLS 傍受型プロキシで説明したように企業 CA をインストールし、その後インストールコマンドを再実行してください。

Docker デーモンがプロキシを認識しているか確認します：


sudo docker info | grep -i proxy
sudo docker login instance-registry.ironflock.com

docker info は、Docker が使っているプロキシをパスワードを伏せて表示します。docker login 単体で成功すれば、アプライアンスのインストールは失敗していたステップを通過できます。

他はすべて問題なくインストールされるのに、単一のコンポーネントだけダウンロードに失敗する。 これは通常、frp ベースのリモートアクセスコンポーネントが、プロキシやアンチウイルスによってリスクウェアとしてブロックされているためです。インストール自体は完了します — デバイスインターフェースアクセスだけが利用できません。これを有効にするには、デバイスユーザーインターフェースへのリモートアクセスで説明したように、プロキシチームにそのトラフィックを許可してもらったうえで、アプライアンスが実行しているバージョンを指定して sudo ironflock appliance install --version <version> を実行してください。意図的にこれなしでインストールするには、--no-tunnel を渡してください。

アップデート

アプライアンスがプロキシの背後でインストールされると、そのプロキシ設定は /opt/ironflock/.env に記憶され、アップデートのたびに再適用されます。アプライアンスの UI からのアップデートも ironflock appliance update によるアップデートも、追加の操作なしにプロキシ経由で引き続き動作します — アプライアンスガイドのメンテナンスを参照してください。アプライアンスを別のプロキシに向ける場合 — あるいはプロキシを完全に外す場合 — は、後からプロキシを変更または削除するを参照してください。

デバイスインターフェースへのリモートアクセスがインストール時にブロックされていた場合、すべてのアップデートで自動的に再試行されます — そのため、プロキシが frp を許可すれば、次回のアップデートで追加の手順なしにこの機能が有効になります。