127.0.0.1:49342: ローカルホストのIPアドレス、ポート、およびデバッグガイド
何かをクリックしたのかもしれません。ターミナルウィンドウがスクロールしたのかもしれません。ログファイルが目に留まったのかもしれません。いずれにせよ、画面に「127.0.0.1:49342」という文字列が表示されました。ブラウザはインターネット上に存在しないページにジャンプしました。開発者ツールがそれを検知しました。ログインポップアップが一瞬表示され、すぐに消えました。目に見える不具合は何もありませんでした。しかし、何かが少しおかしいと感じました。
ご安心ください、何も壊れていません。あの短い文字列は、実はコンピュータを使う際に最もよく目にするものの1つで、その2つの部分を理解すれば、今後「127.0.0.1:」という文字列は普通の文章のように読めるでしょう。左側のIPアドレスは、どのマシンでも共通するユニバーサルループバックです。右側のポートは、オペレーティングシステムがローカルサービス、Webアプリケーション、またはネットワークサービスに割り当てた特定のポートで、自分のハードウェア上で実行されているプログラム間の短い通信に使用されます。外部ネットワークには一切接続されません。すべて目の前の1台のマシン内に留まります。
では、計画はこうです。解説とトラブルシューティングガイドを1つずつ組み合わせました。アドレスの由来、ポート番号が実際に何を表しているのか、なぜ49342が特に特別なものではないのか、WindowsユーザーとLinuxまたはmacOSユーザーでどのように異なるのか、2026年のセキュリティ状況は具体的にどのようなものなのか、暗号通貨開発者がHardhat、Anvil、Ganache、Bitcoin CoreといったWeb3開発環境で同じパターンをどのように使用しているのか、といった点について解説します。最初から最後まで読むことも、検索のきっかけとなった内容に合致するセクションに直接ジャンプすることもできます。
127.0.0.1とは何か：ループバックアドレスの説明
まずIPアドレスの部分から見ていきましょう。127.0.0.1は、今日オンラインで使われているアドレスのほとんどよりも古いものです。商用ウェブがまだ存在していなかった1989年10月、IETFはRFC 1122を廃止しました。そのセクション3.2.1.3には、ネットワークに関する最も厳しい規則の一つが記されていました。「この形式のアドレスはホストの外に表示してはならない」。現在、スマートフォンのOSはこの規則を強制しています。自宅のルーターも同様です。それ以降に出荷されたすべてのOSは、この規則を静かに守り続けています。
規模が人々を混乱させる。そのルールは 16,777,216 のアドレスに適用される。すべてだ。1600 万のアドレスが予備として確保されているので、そのうちの 127.0.0.1 は地球上のどこにいても「このマシン、ここ」を確実に意味できる。少し無駄だろうか? そうだ、何十年も前から不満の声は大きい。IANA のグローバル IPv4 プールは 2011 年 2 月 3 日にゼロになった。ARIN は 2015 年 9 月 24 日にゼロになった。RIPE NCC は 2019 年 11 月 25 日に最後の /22 ブロックを配布した。`draft-schoen-intarea-unicast-127` と呼ばれる IETF ドラフトが、127 スペースの大部分を実際にユニキャストに再利用できると示唆している。誰もそれを触りたくない。既存のソフトウェアの多くは、127 が決して変わらないことを前提としている。
初めて使う人が必ず驚くポイントの一つは、パケットが物理的なネットワークカードに文字通り到達しないことです。それどころか、全く到達しません。127.xxx の宛先宛てのパケットは、OS の TCP/IP スタックのレイヤー 3 で捕捉され、仮想インターフェース (Linux と macOS では `lo` と呼ばれます) を介して送信されます。カーネルは、TCP セグメントの構築、チェックサムの計算、受信パスの走査など、実際の処理を実行します。オーバーヘッドはゼロではありません。しかし、LAN 上のスイッチも、ルーターも、インターネットのバックボーンも、そのトラフィックを一切認識しません。
「localhost」という単語は、今すぐにでも開けるプレーンテキストファイルにマッピングされた、人間にとって分かりやすいエイリアスにすぎません。Linux と macOS では `/etc/hosts`、Windows では `C:\Windows\System32\drivers\etc\hosts` です。リゾルバは、DNS サーバーに問い合わせる前にこのファイルにアクセスするため、Wi-Fi がオフになっている飛行機内で `localhost` は正常に解決されます。IPv6 には、2006 年 2 月に RFC 4291 で定義された独自のバージョン `::1/128` があります。金曜日の定番の頭痛の種は、最新のブラウザが `localhost` を最初に `::1` として解決するのに対し、Python アプリケーションは 127.0.0.1 にしかバインドしていないことです。ソケットが異なるため、交差がなく、サイレントエラーが発生します。毎週どこかで誰かの作業の流れを中断させています。
ポート49342が表示される理由：一時的なポートとIANAの範囲
さて、後半です。ポート番号はIPアドレスよりも人々を混乱させますが、それにはもっともな理由があります。IANAのサービス名とトランスポートプロトコルのポートレジストリは、16ビットの空間全体（0から65535まで）を3つのバケットに分割しており、49342がどのバケットに属するかがすべてを物語っています。
| 範囲 | 数字 | 目的 |
|---|---|---|
| システム（よく知られている） | 0～1023 | 標準サービス（HTTP 80、HTTPS 443、SSH 22、SMTP 25）。バインドするには管理者権限が必要です。 |
| ユーザー（登録済み） | 1024–49151 | ベンダーに割り当てられたサービス（PostgreSQL 5432、MySQL 3306、RDP 3389） |
| 動的／プライベート／一時的 | 49152–65535 | 短期間の割り当て。サービス予約は不可。 |
ポート49342は動的範囲内にあります。このポートには何も「登録」されておらず、今後も登録されることはありません。なぜなら、IANAはこの範囲内のサービスを割り当てることを拒否しており、まさにオペレーティングシステムが一時的な使用のためにこの範囲のポート番号を自由に割り当てられるようにするためです。一時ポートとは、アプリケーションが特定のポート番号を要求しなかった動的に割り当てられるポートです。アプリケーションはOSに対して「空いているポートをください。このセッションの間だけ必要です」と要求します。OSは49342を返し、アプリケーションはリスニングソケットをバインドし、短期間のアドレスとポートの組み合わせを必要とするフローはそれを受け取ります。ポート49342は、このようなアドホックなバインディングを使用する一時的なローカルサーバーによく使用されます。
デフォルトの一時ファイル範囲は、実際にはオペレーティングシステムによって異なります。
| OS | デフォルトの一時的な範囲 | ソース |
|---|---|---|
| Linux | 32768–60999 | `/proc/sys/net/ipv4/ip_local_port_range`、カーネルドキュメント |
| Windows（Vista / Server 2008以降） | 49152–65535 | Microsoft Learn |
| macOS (Darwin / BSD) | 49152–65535 | `sysctl net.inet.ip.portrange.first/hifirst` |
| FreeBSD | 49152–65535 | sysctl デフォルト |
Windows や macOS では、49342 はデフォルトの範囲内に収まっています。OS のアロケータがほぼ間違いなく割り当てたのでしょう。Linux では話が違います。49342 はデフォルトの 32768 ～ 60999 の範囲を超えているため、カーネルに `bind(('127.0.0.1', 0))` を要求し、空いているポートを取得したアプリケーションによって選択されました。2011 年 1 月に IETF から発行された RFC 6056 では、セキュリティ上の理由から、スタックに対して一時ポートの選択を 1024 ～ 65535 の範囲全体でランダム化するように指示しています。予測可能なポートは、フローのハイジャックを容易にします。そのため、同じ開発サーバーが今日は 49342、明日は 54871、明後日は 33200 を使用する可能性があります。
お使いのコンピューターに127.0.0.1:49342が表示される場所
では、これは通常どのような場面で発生するのでしょうか？ポート49342で動作するローカルサーバーは、開発者がローカルループバックソケットに対してアプリケーションをテストする、開発者向けツールの長いリストにあるような、ほぼあらゆるものになり得ます。以下の表は、49342のようなポートが実際に使用される日常的なケースを網羅しており、サービスが毎回指定されたポートで実行され、接続を受け入れます。
| ソフトウェア | 典型的な港 | あなたが見るもの |
|---|---|---|
| OAuth CLIサインイン（gh、aws、gcloud） | ランダムで一時的な | ブラウザが127.0.0.1を開き、確認し、閉じる |
| ジュピターノートブック | 8888、その後は一時的 | カーネルソケットは49152番台のランダムなポートを使用する |
| Vite開発サーバー | 5173 | フロントエンドのホットリロード |
| React / webpack-dev-server | 3000 | 同じ家族 |
| VS Code / JetBrains デバッグ | ランダムで一時的な | デバッグアダプタがローカルサーバーにバインドします |
| Electronアプリ（Slack、Discord、Spotify） | ランダムで一時的な | 内部IPCブリッジ |
| ヘルメットノード | 8545 | イーサリアムJSON-RPC |
| アンビル（鋳造所） | 8545 | イーサリアムJSON-RPC |
| ガナッシュGUI | 7545 | イーサリアムのテストチェーン |
| Bitcoin Core regtest | 18443 | バージョン0.16以降のRPC |
ブラウザのアドレスバーに文字通り `127.0.0.1:49342` が表示される唯一のケースは？ほとんどの場合、OAuth です。IETF の RFC 8252「ネイティブ アプリ向け OAuth 2.0」は 2017 年 10 月に公開され、ネイティブ アプリにループバック リダイレクト フローを使用するように指示しています。ただし、認証サーバーは「任意のポート番号を許可しなければならない」というルールが一つだけ明確に定められています。`gh auth login` または `gcloud auth login` を実行してください。CLI はランダムな一時ポートで小さな HTTP サーバーを起動し、ID プロバイダーにブラウザを送信し、そのループバック アドレスでコールバックをキャッチして、自身をシャットダウンします。127.0.0.1:49342 のような localhost アドレスが 2 秒ほど点滅してから消えるのが見えます。バグではありません。トラッカーでもありません。詐欺でもありません。非常に短いハンドシェイクで、完全にローカルで行われ、外部ネットワークに到達することはありません。
127.0.0.1:49342 のエラーとポートの競合に関するトラブルシューティング
私の経験上、localhostで発生するトラブルは大きく5種類に分けられます。夜11時に検索を余儀なくされるような問題は、どれも何らかの形でこれらのどれかに当てはまります。
ポートが既に使用されています。Node.jsは `EADDRINUSE` とエラーを出力します。Python は `OSError: [Errno 98] Address already in use` という、いかにも不気味なエラーを返します。Windows は `WinSock 10048` と表示して終了するだけです。いずれの場合も根本的な原因は同じです。マシン上の別のプロセスが先に 49342 番ポートを取得してしまったのです。あなたの仕事は、そのプロセスを見つけて終了させ、ポートを解放することです。
- Linuxでは、`ss -tulpn | grep :49342`を実行するか、昔ながらの`sudo lsof -i :49342`を実行してください。
- Macの場合：`lsof -nP -iTCP:49342 -sTCP:LISTEN`
- WindowsのPowerShellでは、`netstat -ano | findstr :49342`を実行し、次に`tasklist /fi "PID eq "`を実行して、そのPIDをプログラム名に変換します。
サーバーは稼働していますが、何も接続できません。この問題は、あなたが思っている以上に頻繁に発生しています。IPv4とIPv6が密かに混在していたことが原因です。サーバーは127.0.0.1にバインドされていました。ブラウザは、何の理由もなく`localhost`を`::1`として解決していました。これらは2つの異なるソケットであるため、当然何も接続できません。両方のファミリーを同時にバインドすることで解決できます（`::`でリッスンすると、ほとんどのスタックでIPv4マップドアドレスも捕捉される傾向があります）。または、URLに127.0.0.1を直接記述することもできます。
VPN がループバックを食い尽くしています。中でも Cloudflare WARP が圧倒的に問題です。Cloudflare 自身も既知の制限事項に関するドキュメント ページでこれを認めています。特に macOS では、WARP を切断すると 127.0.0.1 ルートが完全に削除される可能性があります。VPN を切り替えた直後に localhost がダウンした場合、ほぼ間違いなくこれが原因です。WARP を再接続するか、`sudo ifconfig lo0 127.0.0.1 alias` を使用して手動でルートを復元してください。Proton VPN、Mullvad、NordVPN は基本的にこのような問題は発生しません。エンタープライズ向けアンチウイルスおよび EDR 製品は別です。これらの製品の中には、ループバック トラフィックを傍受してプロキシするものがあります。その方法はすぐに奇妙なものになります。
HSTS が、あなたが忘れていた HTTPS テストを記憶しています。数か月前に、`localhost` で自己署名証明書をテストしました。Chrome は Chrome らしく、HSTS ヘッダーをキャッシュしました。そのため、通常の `http://localhost` リクエストはすべて、黙って https に書き換えられます。デバッグは非常に面倒です。2 分で解決できます。`chrome://net-internals/#hsts` を開いて、エントリを削除してください。
ファイアウォールルール。ループバックは、デフォルトではほとんどのファイアウォールを通過します。ほとんどの。一部の企業向けラップトップイメージは、マルウェア対策の一環として意図的にlocalhostをフィルタリングしており、長い木曜日の終わりにそれに気づくことがあります。確認すべき場所は、Windows Defenderファイアウォールの詳細受信ルールです。Linuxでは、`sudo ufw status verbose`を実行します。本当に何かを開く必要がある場合は、問題となっている特定のポートのみを許可し、ファイアウォール全体を無効にしないでください。
しかし、いつも私を救ってくれる習慣が一つあります。ファイアウォールのルールやルートを一つも変更する前に、必ず`lsof`または`netstat`を実行します。半分くらいの確率で、原因は今日の早い時間にクラッシュした開発実行時にポートを占有し続けているゾンビプロセスであることが判明します。そのPIDに対して`kill -9`を実行すれば、問題は数秒で解決します。
開発環境におけるローカルホストの設定とサーバー構成
デバッグではなくビルド？サーバー設定の習慣をいくつか身につければ、午後の時間をかなり節約できます。どれも特別なことではありません。私たちが目指しているのは、1台のノートパソコン上で複数のネットワークサービスや異なるサービスにわたって、信頼性の高いテストとデバッグを実現するという、ごくシンプルなことです。
ルールその1、退屈なルール：`0.0.0.0`ではなく`127.0.0.1`にバインドしてください。`0.0.0.0`でリッスンすると、小さな開発用Webサーバーが突然、所有するすべてのネットワークインターフェースに自身を宣伝してしまいます。つまり、カフェのWi-Fiで隣のテーブルにいる見知らぬ人がそれを見つけてしまうということです。127.0.0.1にバインドすれば、マシンに既に存在するものだけがアクセスできるようになります。Pythonの`http.server`、Nodeの`express.listen()`、Goの`http.ListenAndServe`はすべて、IPアドレスをそのまま受け入れます。そのまま入力してください。
ルール２：ポート番号を本当に気にしない場合は、選択しないでください。リスナーにポート0を渡します（Node.jsでは`server.listen(0)`、Pythonでは`bind(('127.0.0.1', 0))`）。カーネルはそのミリ秒時点で空いているポートをそのまま返します。その後、`getsockname()`を呼び出して実際に取得したポート番号を確認し、URLを必要とするコンポーネントに渡します。基本的に、これまで触れたすべてのOAuth CLIとデバッグアダプタは、まさにこの処理を行っています。
ルール３：ポート番号はハードコードせず、環境変数を使用する。`PORT`は環境変数から取得し、存在しない場合は適切なデフォルト値を使用する。同じバイナリを、開発環境では127.0.0.1:5173で、本番環境ではリバースプロキシ経由で443番ポートで実行する。データベース文字列、APIキーなど、すべてに同じパターンを適用する。Twelve-Factor Appのドキュメントは、同僚の何人かよりも古いが、今でもシステム停止を回避する最も安価な方法である。
ルール4：localhostでのHTTPSはもはや面倒ではありません。ChromeとFirefoxはどちらも、実際の証明書がなくても、ほとんどの機能で`localhost`と`127.0.0.1`のセキュアコンテキストステータスを付与します。自己署名証明書を拒否する気難しいライブラリがある場合は、依然として最も煩わしくないローカルCAである`mkcert`を使用してください。Pythonの`http.server`やNodeの`net`モジュールなどの組み込みツールにより、ローカル開発中に約5行でローカルサーバーをセットアップできるため、開発者はループバック経由で通信するサービスのみが必要な統合テストで同じスクリプトを再利用することで、現実的な負荷の下でWebアプリケーションをテストできます。
最後のルール、そして実は最も重要なルールです。本番環境はローカルではありません。以上です。ローカルマシンは信頼の境界ですが、本番コンテナはそうではありません。デバッグエンドポイントを本番コンテナ内の 127.0.0.1 で実行したままにしないでください。同じコンテナ内の他のプロセスが初日からそれらにアクセスし、ランタイムのバグが発生すると攻撃者も簡単に侵入できてしまいます。localhost トラフィックは、開発環境など、本来使用すべき場所でのみ使用し、それ以外の場所では使用しないでください。また、そのポートを使用する内部 API が共有環境または本番環境に移行する日には、すぐにその前に実際の認証を導入してください。「リリース後に修正します」などと言ってはいけません。それは以前の会社のやり方です。
ポート49342を安全に使用する：ループバックアドレスのセキュリティ
localhostはプライベートな空間のように感じられる。そして実際、ほとんどの場合はそうなのだが、突然そうではなくなる。
誰もが最終的に直面する落とし穴はここにあります。外部の攻撃者が127.0.0.1に直接ダイヤルすることはできないのは確かです。しかし、外部の攻撃者は、あなたのブラウザや、あなたが既に信頼しているマシン上のアプリケーションをだまして、攻撃者の代わりにその呼び出しを行わせることは間違いなく可能です。この種の攻撃はDNSリバインディングと呼ばれ、この記事を読んでいるほとんどの人がプログラミングを始める前から、ローカルホストサービスを脅かしてきました。
仮想通貨関係者が今でも引き合いに出す例としては、2018年4月24日のMyEtherWalletの事件が挙げられます。攻撃者はAmazonのRoute 53に対してBGPハイジャックを仕掛け、myetherwallet.comのDNSをリダイレクトし、フィッシングクローンサイトを配信しました。このサイトは、The Registerとインターネットソサエティの報道によると、タイムスタンプによって約215ETH（約15万2000ドルから16万ドル）を盗み出すのに十分な時間だけ稼働していました。厳密にはローカルホストのハッキングではないことは承知しています。しかし、この事件は、仮想通貨コミュニティがブラウザのオリジンモデルを真のセキュリティ境界として認識しなくなった転換点となりました。ループバックポートで静かに待機していたすべてのローカルウォレットブリッジが、突然危険にさらされているように感じられたのです。
Chrome の対応策は、当初ドラフト段階で CORS-RFC1918 と呼ばれていたプライベート ネットワーク アクセスです。2024 年 3 月以降、ブラウザは、パブリック Web サイトがプライベート アドレスまたはループバック アドレスにアクセスする前に、`Access-Control-Request-Private-Network: true` を含む CORS プリフライト リクエストを発行するようになりました。ローカル サービスが、このリクエストを通過するために `Access-Control-Allow-Private-Network: true` で応答する必要があります。この完全な適用は、Chrome リリース 123 から 130 で実施されます。したがって、統合テスト中にパブリック ページがアクセスすることを想定して 127.0.0.1:49342 で開発サーバーを出荷する場合は、このヘッダーを設定してください。そうしないと、リクエストはサイレントに破棄されます。
2025年のElectronのCVEのうち2つについて、ここで触れておきましょう。CVE-2025-10585はV8の型混同バグで、2025年9月23日にCISAの既知の悪用された脆弱性カタログに追加されました。CVE-2025-55305はV8ヒープスナップショットを改ざんするコード整合性バイパスで、ほぼ同時期に公開されました。ElectronはChromiumをラップしており、あなたのノートパソコンにはElectronアプリが山ほど入っています（Slack、VS Code、Discord、Notion、Teamsなど、おそらく他にも）。それらの多くはループバックでローカルサービスを公開しています。速やかにパッチを適用してください。また、127.0.0.1に認証トークンなしでRPCエンドポイントをセットアップしないでください。そのエンドポイントが鍵を読み取ったり、トランザクションに署名したり、お金に触れたりする可能性がある場合は特に注意が必要です。
暗号通貨開発者はHardhat、Anvil、Ganacheでどのようにlocalhostを使用しているか
Web3 開発は基本的に 127.0.0.1 ネットワーク アドレスの参照が延々と続くようなものです。契約の展開、プロトコルのファジング、あるいはローカル チェーンに対する日常的な Web 開発など、対象が何であれ同じです。現在、ラップトップの localhost 上では、ローカル ノードの小さなクラスターが稼働しています (たとえその半分を忘れていても)。それぞれに独自のサーバー オン ポート ルールがあります。それぞれが、クライアントがダイヤルインするための固有の IP アドレスとポートの組み合わせを公開しており、通常はツールがデフォルトで設定した特定のポートを使用します。
簡単なチートシート。Nomic Foundation の Hardhat Network は、デフォルトでチェーン ID 31337 の `http://127.0.0.1:8545` を選択します。Foundry の Anvil も同じアドレスとポートを主張しており、2 つのテスト スイートを開いて競合している場合に `--port` で設定できます。Ganache GUI はネットワーク ID 5777 の `127.0.0.1:7545` を取得しますが、CLI 版は Hardhat と同じ 8545 を共有しています。一方、Bitcoin Core の regtest モードは、`127.0.0.1:18443` で JSON-RPC を実行します。これは、テストネットの 18332 との競合が指摘された後、プル リクエスト #10825 を通じて v0.16 に実際に取り込まれた変更です。
MetaMask は、それらのどれにも接続できます。ローカル RPC URL でカスタム ネットワークを追加すれば接続できます。IP 127.0.0.1 は、ブラウザ ベースのウォレット UI と、その時点でラップトップ上で動作しているシミュレートされたブロックチェーンとの間の薄いブリッジとして機能します。Web3 スタック トレースで `127.0.0.1:` を見つけた場合、ほとんどの場合、次の 2 つのいずれかです。IDE のデバッグ アダプタがノードを操作しているか、ノード自体が固定 RPC のすぐ隣のランダムなポートで WebSocket エンドポイントを起動しているかのいずれかです。
決済統合でもこのパターンが繰り返されます。Plisio を利用した暗号通貨決済を構築する場合、ローカルで SDK を `127.0.0.1:3000/plisio/callback` 上の小さな Flask または Express リスナーに対して実行します。ゲートウェイの Webhook はパブリック インターネットから直接ラップトップにアクセスできないため、ローカル テストではトンネル (ngrok、Cloudflare Tunnel、Tailscale Funnel) を使用してポートを公開します。これは、販売者であるあなたが選択して制御する特定のポート番号の特定のポートです。Plisio の PHP、Python、Laravel、および Node.js SDK にはそれぞれ、ショップの秘密鍵に対してペイロードの HMAC-SHA1 を再計算する `verifyCallbackData` ヘルパーが付属しています。このチェックは、コールバックがローカル リスナーに到達するたびに実行されます。同じループバック アドレス、同じジョブ、実際の署名が添付されます。
少し視野を広げてみましょう。実はこのパターンは至るところに見られます。決済、OAuth、開発で使用されるWeb3ネットワークサービスなど、内部構造はすべて同じです。ポート49342またはその他の動的ポートで動作するサーバー、指定されたポートでの実際の接続、そして常にlocalhost上で動作しているのです。
あらゆるオペレーティングシステムに対応した、迅速なローカルホストとポートのチェック
簡単なチートシートです。ターミナルのタブで開いたままにしておきましょう。思っている以上に頻繁に使うことになるはずです。
Linux マシンを想像してみてください。どのディストリビューションでも構いません。`sudo ss -tulpn | grep :49342` は、「49342 番ポートを使用しているのは誰か」という質問に答えてくれます。grep を削除すれば、マシンが開いているすべてのリスニング ソケットを取得できます。カーネルの動的ポート上限が気になる場合は、`cat /proc/sys/net/ipv4/ip_local_port_range` を実行してください。ループバック自体がアクティブであることを証明したいだけであれば、`ip addr show lo` を実行すれば確認できます。そして、出力から `lo` が消えている場合は、ポートの問題よりもはるかに大きな問題が発生している可能性があります。
Mac も同様に動作しますが、BSD の世界に存在するためツールが異なります。`lsof -nP -iTCP:49342 -sTCP:LISTEN` は、ポートで待機しているプロセスを表示します。コロンと番号を削除すると、すべてのリスナーが表示されます。他のユーザーのソケットを表示する必要がある場合は、sudo をプレフィックスとして使用します。一時的な範囲は `sysctl net.inet.ip.portrange.first net.inet.ip.portrange.hifirst` にあります。ループバックはここでは `lo0` (`lo` ではありません) と呼ばれており、このちょっとした命名規則の癖は、人々がそれを永久に内面化する前に一度だけ人々を驚かせます。`ifconfig lo0` で検査します。
Windows では方言が完全に反転します。管理者として PowerShell を起動します。`netstat -ano | findstr :49342` を実行すると PID が出力されます。それを `tasklist /fi "PID eq "` に渡すと、その番号がアプリケーション名に変換されます。動的範囲は `netsh int ipv4 show dynamicport tcp` で確認できます。頑固なレガシー アプリケーションが下限値を要求するため範囲を下げる必要がある場合は、`netsh int ipv4 set dynamic tcp start=49152 num=16384` で移動できます。
これらを体に染み込ませれば、ローカルホストのトラブルは5分以内、場合によってはそれよりも短い時間で解決できるでしょう。一度試してみてください。作業用ラップトップで`lsof -nP -iTCP -sTCP:LISTEN | grep 127.0.0.1`を実行してみてください。スクロールリストは、いつも予想以上に長くなります。ブラウザのバックグラウンドタブ。エディタの言語サーバーがいくつか（多くの場合複数）。Dockerの内部DNS。Slack、Discord、Linearなど、実行しているものからのElectron IPCブリッジ。存在すら知らなかったOSのテレメトリデーモン。さらに、今朝起動していて、シャットダウンし忘れた6つか7つの開発サーバー。このノイズフロアは正常です。これは、動作中の開発環境の裏側で聞こえる音なのです。
