開発環境で立てたサーバー、本当に外から見えているか — 到達確認の手順と切り分け方

開発環境やステージング環境でサーバーを公開した後、「手元のブラウザーでは見えるのに外部からアクセスできない」状況はよくあります。ローカルの名前解決やキャッシュの影響で、手元では正常に見えていても外部からは到達できていないためです。この記事では、DNS の名前解決と HTTPS の接続確認を 2 段階で確かめる手順と、問題があった場合の切り分け方を解説します。自分でサーバーを立てる方を対象にしています。

外部から見えない原因はどこにあるか

「手元では見えるのに外からは見えない」問題には、いくつかの層が関わっています。

1. DNS レコードが外部のリゾルバーに登録されていない
2. IP アドレスは引けるが、ファイアウォールやセキュリティーグループがポートをブロックしている
3. ポートは開いているが、SSL 証明書が未設定で HTTPS 接続が失敗する
4. ローカル環境が NAT の内側にあり、ポートフォワーディングが設定されていない

どの層が原因なのかを特定するために、DNS → HTTPS の順番で外部からの到達確認を進めます。

DNS が外部から引けるか確認する

ドメイン名が外部のリゾルバーから正しい IP アドレスに解決されるかを確認します。手元の /etc/hosts や社内 DNS にだけ設定を入れている場合、ローカルでは名前解決できても外部からは引けません。

dig コマンドで確認する

dig は DNS レコードの確認でもっとも広く使われているツールです。staging.example.com の部分を自分のドメインに置き換えて実行してください。

dig A staging.example.com +short

203.0.113.10

この結果はローカルのリゾルバーを通した値です。社内 DNS を経由している場合や VPN を通している場合は、外部ユーザーが受け取る応答と一致しないことがあります。Google Public DNS（8.8.8.8）を指定して引き直すと、ローカルのリゾルバーとは別のキャッシュから値を取得できます。

dig A staging.example.com @8.8.8.8 +short

IP アドレスが返らない場合は、DNS レコードがまだ設定されていないか、ネームサーバーの委任が完了していません。dig で値が返ってきた場合でも、Google Public DNS 自体のキャッシュに古い値が残っていることがあるため、外部視点での確認手段と突き合わせると確実です。

Labee API で外部視点から確認する

Labee Dev Toolbox の DNS API は、DNS over HTTPS を使って外部のリゾルバーからレコードを取得します。ローカルのキャッシュや /etc/hosts の設定は一切影響しません。staging.example.com を自分のドメインに置き換えて実行してみてください。

curl "https://labee.dev/api/dns?domain=staging.example.com&type=A"

{
  "success": true,
  "data": {
    "domain": "staging.example.com",
    "records": {
      "A": [
        { "address": "203.0.113.10", "ttl": 300 }
      ]
    }
  },
  "error": null,
  "meta": { "responseTime": 50 }
}

records.A の address フィールドが、外部から見える IP アドレスです。dig の結果と見比べて値が一致していれば、外部からも同じレコードが見えている状態です。records.A が null の場合は、DNS レコードが外部から引けていません。レジストラーのネームサーバー設定とゾーンファイルの A レコードを確認してください。

HTTPS で外部から到達できるか確認する

DNS が正しく引けたら、次は HTTPS で実際に TCP 接続できるかを確認します。この段階で失敗する場合、ネットワーク経路のどこかでパケットがブロックされているか、SSL/TLS の設定に問題があります。

openssl コマンドで確認する

openssl s_client は、TLS ハンドシェイクを試行して接続の成否を確認するツールです。

openssl s_client -connect staging.example.com:443 -servername staging.example.com </dev/null 2>&1 | head -20

接続に成功すると、証明書のサブジェクトや有効期限が表示されます。connect:errno= やタイムアウトが出た場合は、ポート 443 への TCP 接続自体が失敗しています。verify error:num= が表示される場合は、TCP 接続はできているが証明書に問題がある状態です。

curl でも HTTP レベルの到達確認ができます。

curl -sI https://staging.example.com | head -5

HTTP/2 200
content-type: text/html; charset=utf-8

ステータスコードが返れば、DNS・TCP・TLS・HTTP のすべての層で到達できています。タイムアウトや接続拒否が返る場合は、後述のトラブルシューティングに進みます。

Labee API で外部視点から確認する

Labee Dev Toolbox の SSL 到達確認 API を使うと、外部ネットワークからの HTTPS 接続を確認できます。staging.example.com を自分のドメインに置き換えて実行してみてください。

curl "https://labee.dev/api/ssl-cert?hostname=staging.example.com"

到達可能な場合のレスポンスは以下のとおりです。

{
  "success": true,
  "data": {
    "hostname": "staging.example.com",
    "port": 443,
    "reachable": true,
    "status": 200
  },
  "error": null,
  "meta": { "responseTime": 200 }
}

reachable が true であれば、外部から HTTPS でサーバーに到達できています。status は HTTP レスポンスのステータスコードで、200 や 301 であれば正常です。

到達できない場合は以下のレスポンスが返ります。

{
  "success": false,
  "data": {
    "hostname": "staging.example.com",
    "port": 443,
    "reachable": false
  },
  "error": "Failed to check SSL certificate",
  "meta": { "responseTime": 0 }
}

到達不可時は success が false になり、error フィールドにエラーの内容が入ります。data に status フィールドは含まれません。この結果が返った場合は、以下のトラブルシューティングで原因を切り分けます。

到達できない場合のトラブルシューティング

openssl や Labee API で到達できなかった場合、原因は大きく 4 つに分かれます。上から順に確認していくと効率的です。

ファイアウォール・セキュリティーグループでポートが閉じている

クラウド環境（AWS、GCP など）では、セキュリティーグループやファイアウォールルールでポート 443 のインバウンドを許可する必要があります。サーバーのプロセスが起動していても、ネットワークレベルでブロックされていると外部からは到達できません。

AWS の場合はセキュリティーグループのインバウンドルールに 0.0.0.0/0 からのポート 443 TCP が含まれているか確認してください。GCP の場合は VPC のファイアウォールルールで tcp:443 の ingress が許可されているかを確認します。

サーバー側でも iptables や ufw がポートをブロックしていないか確認します。

sudo ufw status

443/tcp が ALLOW になっていない場合は、sudo ufw allow 443/tcp で開放します。

NAT の内側にいる

オフィスや自宅のルーターの内側にサーバーを立てている場合、NAT（ネットワークアドレス変換）を越えるためにポートフォワーディングが必要です。ルーターの外部 IP のポート 443 を、サーバーのプライベート IP（例: 192.168.1.100）のポート 443 に転送する設定を入れてください。

ルーターの外部 IP は以下で確認できます。

curl "https://labee.dev/api/ip"

{
  "success": true,
  "data": {
    "ip": "203.0.113.1",
    "type": "IPv4",
    "isPrivate": false,
    "ptr": null
  },
  "error": null,
  "meta": { "responseTime": 30 }
}

data.ip がルーターの外部 IP アドレスです。DNS に設定した IP アドレスとこの値が一致していない場合は、DNS レコードの向き先がルーターの外部 IP になっていません。

SSL 証明書が未設定または期限切れ

サーバーは起動していて TCP 接続もできるが、SSL 証明書がインストールされていない場合、HTTPS での接続は TLS ハンドシェイクの段階で失敗します。

HTTP（ポート 80）ではアクセスできるのに HTTPS（ポート 443）ではアクセスできない場合は、この原因の可能性が高いです。Let’s Encrypt を使っている場合は、証明書の取得と Web サーバーへの設定が完了しているか確認してください。

証明書の自動更新が失敗するパターンや CAA レコードによる拒否など、SSL 関連のトラブルは「SSL 証明書の期限切れを防ぐために知っておくべきこと」で詳しく解説しています。証明書の有効期限は openssl で確認できます。

openssl s_client -connect staging.example.com:443 -servername staging.example.com </dev/null 2>&1 | openssl x509 -noout -dates

notBefore=Apr  1 00:00:00 2026 GMT
notAfter=Jun 30 23:59:59 2026 GMT

notAfter が過去の日付になっていれば、証明書の期限が切れています。

DNS の IP アドレスが実際のサーバーと一致していない

DNS レコードを最近変更した場合、外部のリゾルバーにはまだ古い IP アドレスが残っていることがあります。最初のステップで確認した外部から見える IP アドレスが、実際にサーバーが動いている IP アドレスと一致しているかを確認してください。

クラウド環境でインスタンスを再作成すると IP が変わることがあります。Elastic IP や静的 IP を割り当てていない場合、インスタンス再起動のたびに DNS レコードの更新が必要です。

ステージング環境の公開前や DNS 切り替え直後には、dig → Labee DNS API → openssl → Labee SSL API の順に確認すると、原因の切り分けが効率的です。DNS レコードの設定確認から始める場合は「ドメインを取得したら最初にやる DNS チェック」も参考になります。ブラウザーから確認する場合は Labee Dev Toolbox の DNS チェック画面や SSL 到達確認画面にドメインを入力するだけで、外部視点の結果を GUI で確認できます。