---
title: "ネットワークのよくある質問"
description: "IPv6、クライアントアドレス、DNS、ルーティング、証明書の問題を調べます。"
---

> Documentation Index
> Fetch the complete documentation index at: https://cdelivery.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# ネットワークのよくある質問

以下の IPv6 の確認手順は、Pingress を実行する Linux サーバーが対象です。

## Pingress がゲートウェイのアドレスを記録するのはなぜですか？

IPv4 のみの `docker_gwbridge` は IPv6 接続を変換することがあり、ホストが IPv6 に対応していても、元のクライアントアドレスが失われます。前段に CDN や別のプロキシがある場合も、直接の接続元が変わります。Pingress はその接続元のアドレスを記録し、`X-Real-IP` と `X-Forwarded-For` に設定します。

## インストーラーは IPv6 を自動で有効にしますか？

新規インストール時や参加時に、スクリプトはホストの IPv6 を検出し、デュアルスタックのゲートウェイの準備を試みます。選択を求められた場合は、**1** で IPv4 のみで続行し、**2** で終了して問題を解決します。既定は終了で、対話端末がない場合も同様です。

`--no-ipv6` はゲートウェイの準備をスキップします。既存のデュアルスタックのゲートウェイで IPv6 を無効にするものではありません。macOS のネットワークは Docker の実行環境が管理します。

## 正常に動作しているか確認するには？

Pingress を実行するサーバーで、次を実行します。

```sh
ip -6 address show scope global
ip -6 route show default
docker network inspect docker_gwbridge --format '{{.EnableIPv6}}'
```

最後のコマンドは `true` を返す必要があります。ただし、これは設定の確認であり、接続できることを示すものではありません。外部に公開する場合は、ドメインの AAAA レコードを、IPv6 経由で Pingress にアクセスできるアドレスに向けてください。

IPv6 に対応した別のマシンから、両方のプロトコルをテストします。例のドメインは実際のドメインに置き換えてください。

```sh
curl -4 --noproxy '*' -I https://app.example.com
curl -6 --noproxy '*' -I https://app.example.com
```

Pingress の `client_ip`、またはアプリケーションが受け取る転送ヘッダーが、接続元のクライアントアドレスと一致するか確認します。アプリケーションのソケットの接続相手は Pingress であり、元のクライアントではありません。

## インストール後に IPv6 を有効にするには？

まず、ホストで IPv6 が使えるようにします。ゲートウェイがすでに `true` を返す場合は、接続と DNS を確認してください。まだ参加していないサーバーでは、[インストールコマンド](/docs/ja/getting-started/installation/)またはサーバー一覧で取得した参加コマンドを、`--no-ipv6` を付けずに実行します。

**既存のインストールを再実行しても、ゲートウェイは更新されません。** 稼働中のサーバーでゲートウェイが IPv4 のみの場合は、メンテナンスが必要です。

1. ローカルデータをバックアップし、ノード ID、ロール、すべてのノードラベル、ゲートウェイの設定、そのノードに固定されたアプリケーション、Pingress、Insight を記録します。
2. ワークロードを停止または移動します。マネージャーノードを離脱させる前に、過半数のマネージャーが正常に稼働し、別のノードで CDelivery のダッシュボードが使えることを確認してから、対象ノードを降格します。唯一のマネージャーをそのまま離脱させてはいけません。先に安全な引き継ぎ、またはバックアップと復旧の計画を用意してください。操作の詳細は [Docker のノードメンテナンス手順](https://docs.docker.com/engine/swarm/manage-nodes/)を参照してください。
3. ノードが離脱し、ゲートウェイを参照するコンテナがなくなったら、稼働中のダッシュボードから**元のロールでの新しい参加コマンド**を取得します。`--no-ipv6` を付けずに実行すると、参加前にスクリプトが既定のゲートウェイを準備します。独自に設定したゲートウェイでは、元のサブネットとオプションを保持して、別途[デュアルスタックのゲートウェイを準備](https://docs.docker.com/engine/swarm/networking/#customize-the-docker_gwbridge)してください。招待の有効期限は 30 分で、CDelivery が再起動または移動した場合も無効になります。
4. 再参加すると新しいノード ID が作成されます。ボリュームの説明を含むすべてのラベルを復元し、古い ID に固定されたサービスの設定を修正します。ローカルボリュームを使うアプリケーションやローカルストレージを使う Insight は、画面でノードを切り替えるだけでは移せません。管理者による配置制約の修正が必要です。データは元のホストに残ります。
5. サービスを復旧し、必要に応じて DNS を更新して、上記の IPv4、IPv6 接続とクライアントアドレスを再確認します。

別の方法として、IPv6 に対応したサーバーを追加し、そこで Pingress を実行して、DNS をそのサーバーに向けることもできます。

## IPv6 のルーティングやファイアウォールに問題がある場合は？

転送を有効にすると、`accept_ra=1` のインターフェースがルーター広告（RA）を受信しなくなり、デフォルトルートが失われることがあります。インターフェースを管理するネットワークマネージャーで、RA の設定を永続化してください。ifupdown では `accept_ra 2`、ifupdown-ng では `ipv6-accept-ra 2` を使います。ネットワークマネージャー自身が RA を処理するインターフェースでは、`accept_ra=0` を安易に上書きしないでください。インターフェースやホストの再起動後に、ルートを再確認します。

Docker の IPv6 ファイアウォール管理を有効に保ち（`ip6tables` を `false` にしないでください）、ホストとクラウドのファイアウォールで Pingress の HTTP/HTTPS ポートを許可します。ゲートウェイが `true` を返すだけでは、これらのルールや外部からの接続が正常であるとは確認できません。

## その他のアクセス障害

DNS やルーティングの問題は[ドメインとルーティング](/docs/ja/guides/networking/routing/)に沿って確認してください。証明書の欠落、有効期限切れ、発行失敗は[自動証明書と更新](/docs/ja/guides/networking/automatic-certificates/)を参照します。[アクセスログ](/docs/ja/guides/observability/logs/access/)で、リクエストが入口に到達したか、アプリケーションに一致したか、上流から応答があったかを確認できます。

Source: https://cdelivery.dev/docs/ja/guides/networking/faq/index.mdx