Webサーバー on AIによる技術記事備忘録

CaddyのファイルサーバーにBasic認証を設定する方法とドメイン追加時のreload挙動

Fri, 04 Sep 2026 15:49:56 +0900

軽量でHTTPSの自動設定が強力なWebサーバー「Caddy」において、ファイルサーバー機能にBasic認証を付加する手順と、ドメイン追加時にサービス再起動が必要かどうかについてのまとめです。

Basic認証の設定手順

Caddyで静的ファイルを配信する file_server ディレクティブに対してBasic認証を設定する場合、平文のパスワードをそのままCaddyfileに記述することはできません。事前にパスワードのハッシュ値を生成し、それを設定ファイルに組み込む必要があります。

まず、サーバーのターミナル上で caddy hash-password コマンドを実行します。対話形式でパスワードの入力を求められるため、使用したいパスワードを入力すると、bcryptアルゴリズムによって暗号化されたハッシュ文字列が出力されます。

caddy hash-password
# 入力プロンプトにパスワードを入力すると、ハッシュ値が出力されます
# 出力例: $2a$14$Zkx19XLiW6VYouLHR5NmfOFU0z2GTNmpkT/5qqR78lmQ827KnFsEK

ハッシュ文字列が得られたら、Caddyfileのサイト定義内に basicauth ディレクティブを追記します。サイト全体を保護する場合は以下のようにルートに配置します。

example.com {
 root * /var/www/html

 # Basic認証の設定
 basicauth {
 # ユーザー名 ハッシュ化されたパスワード
 alice $2a$14$Zkx19XLiW6VYouLHR5NmfOFU0z2GTNmpkT/5qqR78lmQ827KnFsEK
 }

 file_server
}

特定のディレクトリ（例: /admin/ 以下）のみを認証の対象としたい場合は、ディレクティブの直後にパスの指定をマッチャーとして付与することで適用範囲を限定できます。

example.com {
 root * /var/www/html

 # /admin 以下のパスのみ認証を要求
 basicauth /admin/* {
 bob $2a$14$Zkx19XLiW6VYouLHR5NmfOFU0z2GTNmpkT/5qqR78lmQ827KnFsEK
 }

 file_server
}

ドメイン追加時の証明書発行とreloadの挙動

Caddyfileに新しいドメインを追加した際、Webサーバーのプロセスを restart させる必要はありません。Caddyは reloadコマンドのみで証明書の発行まで完結 します。サービスを停止して再起動をかける必要はありません。

設定変更後は、サーバー上で caddy reload または systemctl reload caddy を実行します。Caddyはゼロダウンタイムで新しい設定を読み込み、構成に追加された新しいドメインを検知すると、即座にバックグラウンドでACME（Let’s EncryptやZeroSSLなど）を通じたSSL/TLS証明書の自動取得と適用を開始します。

ただし、正常に証明書が発行されるためには、前提条件として以下の2点が整っている必要があります。

追加したドメインのDNSレコード（A/AAAA）が正しくサーバーのIPアドレスを向いていること
HTTP-01チャレンジなどの検証を通すため、外部から80番および443番ポートへの通信が疎通可能な状態であること

これらが満たされていれば、リロードを実行するだけで数秒から十数秒のうちにHTTPS通信が確立されます。

「サーバ」という言葉には3つの顔がある――初心者が最初につまずく理由と整理法

Thu, 27 Aug 2026 10:52:47 +0900

ITの学習や業務の中で、私たちはごく自然に「サーバ」という言葉を使っています。しかし、一口にサーバと言っても、話す人や文脈によって指している対象がまったく異なることがあります。その違いを大別すると、物理的なハードウェア、ソフトウェア、そして役割を表す概念の3つに分けられます。

このレイヤーのズレを意識しないまま会話を進めてしまうと、特に初学者の学習において大きな混乱の原因となります。本記事では、この3つの違いを論理的に整理し、なぜ初心者がつまずきやすいのかを備忘録としてまとめます。

3つのレイヤーで理解する「サーバ」の正体

サーバ（Server）という英単語の語源は、提供する・給仕するという意味を持つ serve に由来します。レストランにおける「給仕係（店員）」と「客（クライアント）」の関係をイメージすると、3つの違いが明確になります。

1つ目は、概念・役割としてのサーバです。これはクライアント・サーバモデルと呼ばれるアーキテクチャや関係性そのものを指します。要求（リクエスト）を出す側をクライアント、その要求を受け取ってサービスやデータを返す（レスポンス）側をサーバと呼びます。ここには物理的な機械や特定のプログラムという実体の制約はなく、あくまで「要求に応じる役割」という抽象的な関係性を意味しています。

2つ目は、ソフトウェアとしてのサーバです。これはクライアントからの要求を処理して応答を返す具体的なプログラムを指します。たとえば、Webページを配信する Apache や Nginx、データベースを管理する MySQL や PostgreSQL などがこれに該当します。手元のノートパソコンであっても、これらのソフトウェアをインストールして起動すれば、そのプログラムは立派なWebサーバやデータベースサーバとして機能します。

3つ目は、ハードウェアとしてのサーバです。これはサーバソフトウェアを安定して24時間365日動かし続けるために設計された物理的なコンピュータ機械を指します。データセンターのラックに収められているような、高い耐障害性や連続稼働用の冷却性能を備えた専用マシンです。

これらを整理すると、「1台の物理コンピュータ（ハードウェア）の中で、複数のサーバプログラム（ソフトウェア）が稼働し、それぞれが利用者の要求に応えてデータを提供する（概念・役割）」という多重構造になっていることがわかります。

なぜ初心者は「サーバ」という言葉でつまずくのか

この3つの意味が日常会話で無意識に使い分けられていることこそが、初心者が学習初期に感じる混乱の根本的な原因です。具体的には、次のような場面で思考のフリーズが発生します。

まず、 「自分のパソコンがサーバになる」という感覚が掴めないという問題があります。「サーバ＝データセンターにある巨大で特別な黒い箱」という先入観を持っていると、Web開発の入門時に「ローカル環境にWebサーバを立ち上げる」と指示された際、なぜ普通のノートPCが突然サーバになるのか理解できなくなります。自分のPC上で localhost や 127.0.0.1 に対してリクエストを送る行為は、同じマシン内でクライアント（ブラウザ）とサーバ（Webサーバソフト）が同時に動いている状態ですが、ハードウェアとソフトウェアを混同しているとこの構造が見えてきません。

次に、 「サーバが落ちた」というトラブルの解像度が低くなる点です。障害が発生した際、物理マシンの電源やネットワークが切断されたのか、Nginx などのプロセスが停止したのか、それともプログラム内部のバグで例外が発生したのかによって対処法は全く異なります。しかし、すべてを一括りに「サーバの問題」と捉えてしまうと、何が壊れているのかを正しく切り分けられなくなります。

さらに現代では、クラウドサービスや仮想化技術の普及により、物理と論理の境界がより曖昧になっています。AWSなどのクラウド上で仮想マシンを作成することを日常的に「サーバを立てる」と呼びますが、これはソフトウェアによって仮想的に作られたコンピュータであり、物理的な実体と1対1で結びついているわけではありません。

文脈のズレを意識して解像度を上げる

私たちが普段何気なく交わしている会話を振り返ると、主語のレイヤーが頻繁に入れ替わっていることに気づきます。

サーバを契約する・購入する（ハードウェアやインフラ設備の文脈）
サーバをインストールする・起動する（ソフトウェアやプロセスの文脈）
サーバにリクエストを送信する（概念やアーキテクチャの文脈）

相手にサーバの仕組みを説明するときや、自身が技術的なトラブルシューティングを行うときは、いまどのレイヤーの話をしているのかを意識することが大切です。ハードウェア、ソフトウェア、そして概念という3つの視点を持つだけで、ITシステム全体の構造を格段にクリアに見通せるようになります。

Webサーバー on AIによる技術記事 備忘録