dsh の LAN アクセスとポート設定ガイド
デフォルトポート 3080、--port フラグ、0.0.0.0 が公式に拒否される理由、ファイアウォール開放、そして dsh-LAN プラグインで Web UI を同じネットワークのスマホや同僚に安全に開放するまで。
最終更新: 2026-10-02
dsh web は自分の PC では順調に動いているのに、同じ部屋の他のデバイスで http://<あなたのIP>:3080 を開いても反応がない——dsh を導入した後に誰もが最初にぶつかる質問です。このページではポートの基本、開かない理由となっているバインド境界、そして LAN アクセスを正しく開くプラグインのルートを解説します。
スコープの確認：このページは同じ Wi-Fi / 同じオフィスネットワーク内のデバイス間アクセスの話です。訪問者がネットワークの外（モバイル回線など）にいるならルーティングされず、公開トンネルが必要——それはリモートアクセスガイドの領域です： スマホからリモート操作
要点まとめ
- ▸dsh web の既定アドレスは http://127.0.0.1:3080——ポート 3080、ループバックのみ。起動時に URL が出力されます。
- ▸ポート変更は dsh web --port 8080。--port は web アプリ側のフラグで、ランチャーのものではありません。
- ▸公式 CLI は --host 0.0.0.0 を意図的に拒否します（使用方法エラーで終了）。今のところ LAN 開放は dsh-LAN プラグインかリバースプロキシで、信頼できるネットワークでのみ。
- ▸同じ Wi-Fi なら LAN IP で直接アクセス。別のネットワークならトンネルが必要——リモートアクセスガイドへ。
既定ポートとローカル確認
「dsh のポートは何番？」は、設定ファイルを開かずとも 3 ステップでその場で確認できます。
既定：127.0.0.1 のポート 3080
dsh web は既定で http://127.0.0.1:3080 に Web UI を立ち上げ、ブラウザーを開きます。--no-open を付けるとサーバーだけ起動。どちらでもコマンドは URL を出力するので、起動ログがポートの一次情報です。
プロセスが実際に待ち受けているポートを確認
既定以外のフラグで起動した、あるいは確証が欲しい場合はリッスン中のソケットを一覧表示：Windows は netstat、macOS / Linux は lsof。出力の PID から、ポートを占有しているプロセスも分かります——「ポートが使用中」の切り分けにそのまま使えます。
PC の LAN IP を調べる
他のデバイスが入力するのはこのアドレスです。Windows：ipconfig でアクティブなアダプターの IPv4 アドレスを確認。macOS：ipconfig getifaddr en0。Linux：ip a。192.168.x.x や 10.x.x.x は LAN アドレス、127.x.x.x はループバックで、そのマシン自身からしか届きません。
ポートを変える（--port）
3080 が埋まっている、単に別のポートを使いたい——フラグ 1 個で済みます。
--port を web アプリに渡す
ランチャーは認識しないフラグを起動したプロファイルへそのまま渡すので、--port は web アプリに届きます。下のショートハンド形式と明示プロファイル形式のどちらでも可。--port は web アプリ側のフラグで、ランチャー自身のフラグはそれより前に置きます。
ポートを変えたのに効かないとき
フラグが設定行に勝つのは、設定行が実行時にフラグを読んでいるからです。ところがユーザーパッチが config のブロック全体をリテラル値で置き換えると、この実行時読み取りが消え、フラグは黙って無視されます。--port が効かないときは、自分の cordis.patch.yml に webserver 設定をリテラルで上書きするパッチがないか確認し、直して dsh web を再起動しましょう。
バインド境界：なぜ LAN から繋がらないのか
ポートを間違えれば「接続拒否」。既定のバインドはさらに分かりにくく——ページは dsh を起動したマシンにしか存在しません。これは意図的な設計です。
dsh web は 127.0.0.1 のみをバインドし、0.0.0.0 は拒否
ループバックのみは出荷時の既定で、公式 CLI リファレンスは「CLI は --host 0.0.0.0 に意図的に非対応。使用方法エラーで終了する」と明記しています。Web UI はファイルを読み書きしコマンドを実行できるエージェントの操縦席——認証なしで全インターフェースに露出させることを、この制限は既定で防いでいるのです。
特権インターフェースの 403 フェンス
ポートがプロキシ経由で届くようになっても、設定・クレデンシャル・エージェントプリセット・モデル探索といった特権インターフェースは非ループバックからのリクエストに 403 を返します。これは DNS リバインディング防止のフェンスであって認証ではありません。ホスト名 / リバースプロキシ構成では、繰り返し指定できる --trusted-host <host> フラグでフェンスにアクセス名を登録できます。コミュニティの構築記録（公式ディスカッション #849）はこの 403 の壁を詳しく記録しています。
無理に迂回してはいけない理由
公式ディスカッション #130 のセキュリティ検証は完全な攻撃チェーンを実証しました：認証されていないネットワーククライアントがループバックの Host ヘッダーを偽装し、特権 RPC のゲートを通過し、LLM エンドポイントを書き換える——次のモデル呼び出しで API キーと会話内容が攻撃者のサーバーへ送られます。公式のリモート認証モデルが登場するまで、正当な LAN 開放の道は下記のプラグインとプロキシの 2 本で、信頼できるネットワークでのみ使うべきです。
上のカードは公式 CLI リファレンスの記述です。一方、下の画面は 2026 年 9 月の LAN 実録で、録画されたビルドでは dsh web --host 0.0.0.0 --port 3080 --no-open がそのまま起動に成功し、ローカルと LAN の 2 つの URL をトークン付きで 1 行に表示しています。0.0.0.0 をめぐって二つの情報源は食い違うため、自分のビルドの実際の起動出力を優先してください。どちらの動作でも、表示されたトークンを LAN 上で唯一の関門として扱い、信頼できるネットワークだけで行ってください。
ファイアウォール：受信の 3080 を開放
バインドの次の関門は OS のファイアウォールです。受信の 3080 を開けておかないと、スマホ側にはページではなくタイムアウトが届きます。
Windows
Windows Defender ファイアウォールはプライベート/パブリックネットワークの受信接続を既定でブロックします。管理者コマンド 1 つで TCP 3080 を許可できるほか、「Windows セキュリティ > ファイアウォールとネットワーク保護 > 詳細設定」から受信の規則を作ることもできます。
macOS
内蔵ファイアウォールは既定でオフ。有効にしている場合はアプリ単位でブロックする仕組みなので、「システム設定 > ネットワーク > ファイアウォール」で node（または dsh のランタイム）を許可します。初回のネットワークアクセス時に許可を求めるダイアログが出ることもあります。
Linux
使っているファイアウォール次第：ufw ならコマンド 1 つ、firewalld はポートを恒久的に追加して再読み込み、iptables は TCP 3080 の ACCEPT 規則を手動で追加します。後述の dsh-LAN プラグインはこれらの規則（Windows・firewalld・ufw・iptables）を自動で維持します。
スマホ / タブレットからのアクセス
最も典型的な LAN シーン：dsh はデスクトップで動いている、手元はスマホ——同じ Wi-Fi で、スマホ側には何もインストールしません。
ブラウザーで http://<LAN IP>:3080 を開く
同じネットワーク上の任意のデバイスで、手順 3 で調べた LAN IP をポート番号まで含めた完全なアドレスで入力します。バインドとファイアウォールが通っていれば、ホストと同じ Web UI が表示されます。サーバーは 1 つでセッション状態はすべてサーバー側にあるため、スマホとデスクトップは同じ会話をリアルタイムに共有します。
開けないときは順番に点検
上から順に：バインドがまだループバック（プラグイン/プロキシ未導入——この段階ではファイアウォールはまだ関係ありません）、ホストのファイアウォール、スマホとホストが本当に同じセグメントか——多くのルーターは AP 隔離が既定で有効で、同じ Wi-Fi でもデバイス同士が見えません。アドレスは http:// とポート番号まで省略せず入力を。スマホのブラウザーは補完で余計なことをしがちです。
インスタンスがネットワーク公開モードで起動していれば（起動行に LAN: の表記がある）、デバイスがアドレスを開いたとき最初に迎えるのはワークスペースではなく dsh ネイティブのトークンゲートです：
スマホでの使い勝手をさらに進めたい（サードパーティクライアント、コンパニオンアプリ）なら、リモート & モバイルコレクションをどうぞ： リモート・モバイルコレクション
dsh-LAN プラグイン：スイッチ 1 つの LAN 開放
MrMu666/dsh-LAN は dsh Web GUI 専用の LAN アクセスプラグイン——MIT ライセンス、2026-10-02 時点でスター 10。インストール 1 回でバインド・ファイアウォール・パスコードゲートを同時に解決します。
できること
導入後、Web GUI は既定で 0.0.0.0（全インターフェース）にバインドされ、ホストのファイアウォールは自動で開放されます（Windows は Defender の Domain + Private、Linux は firewalld → ufw → iptables の順で試行）。どのデバイスでも http://<PC のIP>:3080 を開くとまず全画面のパスコードゲートが表示され、スマホの縦画面では公式 UI にタッチ最適化（大きなタッチターゲット、16px の入力フォント、セーフエリア）が注入されます。なお README のサポート表明は DSH 0.1.2-rc.1 以降・検証は 0.1.5-rc.1 までで、現行の 0.2.0-rc.2 は未検証です。導入前にリポジトリで互換性を確認してください。
インストール
README 自身が示す「最も簡単なインストール方法」は、dsh に「dsh-LAN プラグインをインストールして」と頼むこと——エージェントが導入まで行います。スクリプト経路はリポジトリをクローンしてプラットフォームごとのスクリプトを 1 つ実行。パッチ経路のインストールで、実行中のプロファイルにホットリロードされ、再起動不要ですぐ効きます。bundle 経路は通常のプラグインと同じくローカルディレクトリから追加し、dsh web の再起動が必要です。
使い方
ホスト側で「設定 > General > LAN アクセス」カードを開く：スイッチを入れて、パスコード（4 文字以上）を設定し、ファイアウォールの状態行を確認。他のデバイスはゲートでパスコードを入力、「パスコードを記憶」にチェックすればその端末は次回から不要。上流でループバックに固定されている設定・クレデンシャル等の特権メソッドは、プラグインの /lanapi パスコードプロキシ経路を通じて使えるようになります。スイッチを切ればバインドは即座に 127.0.0.1 へ戻る——これが最も根本的な総スイッチです。
セキュリティ境界を正しく知る
README は明快です：ゲートは UI レベルの保護で、特権操作はサーバー側で強制検証される。ただし非特権 API（セッションの読み書き）は API レベルで LAN に開いたままです。自宅やオフィスの信頼できる intranet なら妥当なトレードオフで、共有ネットワークでは悪手——信頼できる Wi-Fi でのみ有効化し、離れるときは切る。真の認証の代わりにはなりません。
もうひとつのプラグイン経路：複数人で 1 台の dsh を共用
dsh-LAN のほかに、コミュニティには「複数人で 1 台の dsh を共用」するためのサードパーティ プラグインもあります：linyupark/dsh-multi-tenant（確認時は新規リポジトリ、Release 0.3.0）は、単一の dsh インスタンスに「プロジェクト + ユーザー」のマルチテナントを実装します。実際のワークスペース ディレクトリをプロジェクトとして割り当て、ユーザーごとにシンボリック リンク方式の独立ワークスペースを生成し、Web 画面をパスワード ログインで守ります。README の脅威モデルの節は率直で、これは「君子を防ぐ」ソフトな境界にすぎず、公開ネットワークでは dsh の手前に本物の境界（リバース プロキシ認証 / ngrok basic auth / VPN）を置くよう求めています。以下の 4 枚は同じ LAN 実録からで、ログインからユーザー別ワークスペースまでの流れを示します：
プラグイン導入の前提はプラグインのインストール方法を知っていること。dsh のプラグインコマンドに不慣れなら、まずプラグインインストールガイドへ： DeepSeek Harness 使い方：dsh プラグインの入れ方・インストール方法
残る 2 つの方法：リバースプロキシと SSH 転送
dsh 本体のバインドに触りたくないなら、この 2 つは dsh プロセスに一切手を入れません。
dsh-proxy：:3081 に Basic Auth の正面玄関を
smanx/dsh-proxy（スター 24）は HTTP + WebSocket のリバースプロキシプラグイン：web プロファイルに導入し、dsh web と一緒に起動・停止し、127.0.0.1:3080 へ転送しつつ手前にブラウザー Basic Auth を付けられます。導入と dsh web 再起動の後、http://<LAN IP>:3081 で認証ダイアログが出ます。パスワードログインはユーザー名とパスワードの両方を設定したときのみ有効。Host 書き換えと Origin 整合のおかげで、WebSocket が前述の 403 フェンスに引っかかりません。類似の GDWhisper/dsh-web-startup-auth（スター 50）は、作者のディスカッション投稿 (#3132) によれば認証モジュールで 0.0.0.0 での起動をブロックされなくするものです。
SSH ローカル転送：プラグイン不要、通信は暗号化
アクセスしたいデバイス側でローカルポートをホストのループバックへ転送します：下のコマンドをアクセス元のデバイスで実行し、そのデバイスで http://localhost:3080 を開いてください。dsh 側は一切変更せず、通信は暗号化されます——信頼できる同僚のノート PC に最適。スマホの SSH クライアントでも可能ですが、それはもうトンネルの領域です。ネットワークの外に出るなら、リモートアクセスガイドが正解。
よくあるエラーと正体
このトピックで実際に起きる 4 種類の失敗と、それぞれの原因。
起動に失敗する / ポートが使用中
3080 を別のプロセスが占有しています。最初のセクションの確認コマンドで PID を特定し、そのプロセスを止めるか、--port で空いているポートに変えて dsh web を起動しましょう。
LAN デバイスから設定/プリセットへアクセスすると 403
これは想定内の動作で、設定ミスではありません：/api の信頼フェンスは非ループバック発の特権メソッド呼び出し（設定・クレデンシャル・エージェントプリセット・モデル探索）を拒否します。dsh-LAN プラグインはパスコード経路でこれらを再公開し、プロキシ経路では未認証の LAN デバイスを公開ページに留めます。ソースのチェックを削除して迂回しないでください——理由は「バインド境界」の節に。
ポートを変えたのに旧ポートが応答する
定番の原因は 2 つ：設定パッチが webserver 設定をリテラルで書いてしまい --port の実行時読み取りが消えている（「ポートを変える」参照）、またはブラウザーのタブが古いキャッシュのまま。設定変更後は dsh web を再起動し、ブラウザーは強制リロードを。
スマホからどうしても繋がらない
「スマホ / タブレットからのアクセス」のチェックリストを上から：バインドがまだループバック（先にプラグイン/プロキシ）、ファイアウォールの受信規則、スマホとホストが同じセグメントか（AP 隔離）、アドレスにポートまで含めているか。全部確認しても繋がらないなら、トラブルシューティングガイドへ。
どれも自分の症状と合わない？トラブルシューティングガイドで続きを： トラブルシューティング・エラー百科
dsh LAN アクセス FAQ
ポートとバインドに関するよくある質問に、公式ドキュメントと公開ディスカッションに基づいて回答します。
dsh のデフォルトポートは？
3080 です。dsh web は既定で http://127.0.0.1:3080 に Web UI を提供し、起動時に URL を出力します。このアドレスはループバックのみにバインドされるため、dsh を起動したマシンからしか応答しません。ポート変更は dsh web --port <番号>。
スマホや他の PC から http://<自分のIP>:3080 が開けないのはなぜ？
dsh web は既定で 127.0.0.1 のみにバインドされ、公式 CLI は --host 0.0.0.0 を意図的に拒否する（使用方法エラーで終了）ためです。Web UI はファイルを読み書きしコマンドを実行できる Agent の操縦席であり、既定でネットワークに晒されない設計になっています。LAN 開放は dsh-LAN プラグインや dsh-proxy などのリバースプロキシで行い、信頼できるネットワークでのみ使ってください。
dsh web のポートを変えるには？
web アプリに --port を渡します：dsh web --port 8080、または dsh --profile web --port 8080。フラグが効いていないように見えるときは、config 全体をリテラルで置き換えるユーザーパッチがないか確認を——それがあると実行時読み取りが消えます。その後 dsh web を再起動。
LAN アクセスは安全ですか？API キーは漏れますか？
Web UI は普通のウェブサイトではなく制御面（コントロールプレーン）として扱ってください。公式ディスカッションには完全な攻撃チェーンの実証があります：未認証の LAN クライアントが偽装 Host ヘッダーで特権ゲートを通過し LLM エンドポイントを書き換えると、次のモデル呼び出しで API キーとプロンプトが外部に送られます。dsh-LAN のパスコードゲートは UI レベルの保護で、README 自身が非特権 API は LAN に開いたままと明記。実用ルール：信頼できる自宅/オフィスの Wi-Fi のみ、パスコード設定、使わないときはオフ、ポートの公開は絶対にしない。
dsh-LAN プラグインとは？インストール方法は？
LAN アクセス専用のコミュニティプラグイン（MrMu666/dsh-LAN、MIT ライセンス）です：Web GUI を全インターフェースにバインドし、ファイアウォールを自動開放、全画面パスコードゲートを追加、公式 UI にスマホのタッチ最適化を注入します。README によれば最も簡単な導入は dsh に「dsh-LAN プラグインをインストールして」と伝えること。スクリプト導入はリポジトリをクローンして install.ps1（Windows）または ./install.sh（macOS/Linux）を実行——ホットリロードのパッチインストールです。README の検証は DSH 0.1.5-rc.1 までなので、現行バージョンとの互換性を事前に確認してください。
LAN 直接アクセスとトンネル、どちらが必要？
同じ Wi-Fi やオフィスネットワークなら直接アクセス——デバイスはホストの LAN IP に到達できるのでトンネル不要で、このページの各セクションが設定一式です。ネットワークの外（モバイル回線など）からはルーティングされないため、ngrok のような公開トンネルが必須——そちらはリモートアクセスガイドの領域です。
関連ガイド
アクセス三部曲の残り 2 本と、このページが頼りにする入門ページ。
DSH Web UI 立ち上げからスマホまで
dsh web の1コマンドで Web UI を起動し、3080 ワークスペース・スラッシュスキル・モデル設定を押さえたら、dsh-web エコシステムでスマホからも操作——実録スクリーンショット 9 ステップ
ガイドを読むスマホからリモート操作
ngrok の無料トンネルで Web UI を公開 URL に。外出先のブラウザーから自宅のエージェントを操作、アプリ不要の全8ステップ。
ガイドを読むリモート・モバイルコレクション
dsh-web、dsh-pocket、Agents-Anywhere、dsh-mobile——厳選リモートクライアントをひとまとめ。
ガイドを読むDeepSeek Harness 使い方：dsh プラグインの入れ方・インストール方法
dsh でのプラグイン インストールの実際の仕組みと、サードパーティコードを見極めるチェックリスト。
ガイドを読むトラブルシューティング・エラー百科
症状 → 原因 → 対処法：インストール失敗、pnpm workspace allowlist エラー、cordis.patch.yml 競合、bundle 形式エラー、Profile が反映されない問題。
ガイドを読む画面の出典とクレジット
本ページのスクリーンショットはすべて、Bilibili の UP 主「是属鼠我」による dsh LAN アクセスの実録からのフレームで、各画像はタイムスタンプ付きで元動画へ深リンクしています。画面右下の UP 主のカメラ バブルと焼き込み字幕帯はクロップで除去済み。LAN URL のエコーとトークンゲートは dsh 本来の動作、マルチユーザー ログイン・プロジェクト ワークスペース・脅威モデルの画面はサードパーティ プラグイン linyupark/dsh-multi-tenant（新規リポジトリのため、引用時は成熟度にご注意）によるもの、専用 LAN プラグインの経路として MrMu666/dsh-LAN があります。いずれも GitHub README を根拠とし、文章の結論は当サイト独自のものです。