Pleskウェブサーバ

サーバーサイドに含まれるもの：SSIホスティングとウェブサーバー設定

SSIホスティング は、サーバサイドインクルードを静的 HTML ファイルに直接統合し、クライアントサイドに依存することなく完成した HTML コードを提供します。SSI を有効にする方法、典型的なディレクティブの使い方、そして ウェブサーバー設定 をアパッチにクリーンインストールする。.

中心点

エスエスアイ ウェブサーバーが正しく設定されていれば、繰り返されるページパーツのメンテナンスが可能になり、配信速度も速くなる。.

含まれるもの ヘッダー、フッター、ナビゲーションをひとまとめに。.
htaccess .htmlと.shtmlの解析が可能になる。.
セキュリティ 制限的権利とNOEXECを通じて。.
パフォーマンス キャッシングとNVMeのメリット.
互換性 Apacheと共有ホスティングで。.

いくつかのディレクティブを使うだけで、CMSを使うことなく、モジュール化されたページを構築し、メンテナンス作業を大幅に減らすことができます。このガイドでは、わかりやすい例と確かな練習信頼性の高いコンフィギュレーションにより、迅速な結果が得られます。.

サーバーサイドインクルード（SSI）とは？

サーバーに含まれるもの は、ウェブサーバーが配信前に解釈するHTML内の指示です。コードは次のようなコメントになっています。 。 で、ブラウザでは完成したマークアップとして表示されます。これにより、繰り返されるブロックのためのJavaScriptロジックを節約し、クリーンでインデックス可能なコンテンツを得ることができます。構文は常に <!, は小文字を使い、パーサーが正しく動作するためにはカンマを反転させる必要がある。オーバーヘッドが少なくなるように、コマンドは最小限にしている。 メンテナンス は明確だ。.

要件とウェブサーバーの設定

アパッチ モジュール mod_include がアクティブでなければならない。多くのホストは .shtml; 適切な htaccess の解析も有効にする。 .html. .また、お荷物が オーバーライドを許可する を指定しないと、そのファイルは動作しない。正しいスタックを選択するために、以下の項目を参考にしてほしい。 Apache、NginxまたはLiteSpeed, というのも、SSIはサーバー側でApacheをベースにしているからだ。私は構成常にセキュリティ、パフォーマンス、将来的な拡張性を備えている。.

.htaccessを使わないApacheの詳細設定

ベストプラクティス を自分のサーバ環境で使用することができます：vHostで一元的にSSIを有効にするか、ApacheのコンフィギュレーションでSSIを有効にします。 AllowOverride なし を使います。これで htaccess そして、許可されたオプションのコントロールを保持する。.

<バーチャルホスト *:80
  サーバー名 example.org
  ドキュメントルート /var/www/example/public_html

  
    オプション +IncludesNOEXEC
    AllowOverride なし
    すべて許可する
    AddOutputFilter INCLUDES .html
    # オプション: 選択されたファイルのみを解析する
    <FilesMatch " \.(inc|partial)．
      オプション +IncludesNOEXEC
      AddOutputFilter INCLUDES .html
    </ファイルマッチ
  </ディレクトリ

  # 代替、選択起動：XBitHack (下記参照)
  # XBitHack 完全版
</仮想ホスト

共有ホスティング環境では htaccess, しかし、私は設定をvHostにバンドルしておくことを好む。.

ステップ・バイ・ステップ

準備文書マスターで始まる。 公開_html. .ディレクトリを作成する /インクルード を記入してください。 ヘッダー.html そして フッター を作成し、ディレクティブで絶対パスを使用する。それから htaccess をルートに置き、ApacheがSSIでHTMLファイルを解析するように、以下の行を入力する：

AddType text/html .html
AddOutputFilter INCLUDES .html
オプション
AddHandler サーバー解析された .html

ブロックを任意のページに統合できるようになりました。. 。. .そして、変更を安全に保存するために、常にブラウザのキャッシュとサーバーサイドのキャッシュをクリアする。 チェック.

インクルード・バーチャルとインクルード・ファイルの使い分け

チョイス バリアントは柔軟性とアクセス保護を決定する：

仮想を含む はURLパス（例えば. /includes/header.htmlそのため、リライトやアクセスルールを実行し、絶対パスをきれいに解決することができます。フラグメントがウェブ上で見える可能性がある場合や、意図的にURL空間を介して作業する場合に適しています。.
インクルードファイル はファイルシステムから直接読み込み 相対的 を現在のファイルに追加する（先頭にスラッシュは付けない）。これはURLの書き換えを無視するので、次のような場合に理想的である。内部直接アクセスすべきでないフラグメント。以下のようなユニークなファイル名を使用する。 header.inc.html を作成し、ページのサブディレクトリに置く。 includes_priv/.

プライベート・フラグメントの典型的なパターン：

# プロジェクトの/includes_priv/サブフォルダ内：
# .htaccess (外部からのアクセスをブロック)
すべての拒否を要求する


。
。

ブラウザはファイルを取得できないが、SSIはローカルでファイルを読み続ける。ネストしたパスを避けて ファイル-参考文献は、プロジェクトが明確になるよう、できるだけ平坦なものにする。.

SSIのセキュリティと認証

セキュリティ は権利から始まる：ファイルを 644 とフォルダー 755, 偶発的な放出を避ける。避けること #exec 実行権は侵入への扉を開くからだ。共有環境では オプション +IncludesNOEXEC, を使用してスクリプト呼び出しを除外します。のような機密性の高いファイル 環境 またはコンフィギュレーションは、追加の htaccess ディレクトリの中にある。これによりリスクが大幅に軽減され コントロール 統合されたコンテンツを介して。.

ハードニング：スコープ、ヘッダー、クリーン・バウンダリー

スコープ タイトに保つ：必要なところだけSSIを許可する。大きなプロジェクトでは、私は ファイルマッチ 特定のパターン、例えば. *.inc.html 或いは *.shtml. .さらに、私はセキュリティ・ヘッダをグローバルに設定している：

にある
  ヘッダセット X-Content-Type-Options "nosniff"
  ヘッダセット X-Frame-Options "SAMEORIGIN"
  ヘッダセット Referrer-Policy "strict-origin-when-cross-origin"
  ヘッダーセット Content-Security-Policy "default-src 'self'"
</IfModule

私は、一般にアクセス可能な断片（フッターなど）と内部要素（変数ファイルなど）をきれいに分けることで、ルールを明確に保ち、監査を迅速に行えるようにしている。.

プロジェクトのための実践的なSSIの例

例 1: グローバルヘッダー場所 /includes/header.html でバインドする。 。 を全ページに表示します。例2：著作権表示のあるフッター。 。. .例 3: 上記の日付スタンプ 。 をサイドバーに表示します。例4: ファイルへの最後の変更 。 を使用することで、透明性のある最新情報を得ることができる。異なるディレクトリの深さでの統合が信頼できるように、パスは一貫して絶対パスにしている。 機能する.

変数、フォーマット、単純なロジック（XSSI）

指令好む セット, エコー, コンフィグ そして もし は、アプリケーション・ロジックに入り込むことなく、多くの場合において十分である。.

<!-- Ausgabeformat für Datum/Größen setzen -->
<!--#config timefmt="%d.%m.%Y, %H:%M" sizefmt="abbrev" -->

<!-- Eigene Variablen definieren und ausgeben -->
<!--#set var="site_env" value="production" -->
<!--#set var="build_date" value="2026-03-10 12:30" -->
ビルド <!--#echo var="build_date" --> (環境 <!--#echo var="site_env" -->)

<!-- Einfache Bedingungen -->
<!--#if expr="$site_env = /production/" -->
  <p><strong>ライブのヒント</strong> 生産的な環境</p>
<!--#else -->
  <p>ステージング/テスト</p>
<!--#endif -->

<!-- Umgebungsvariablen inspizieren (Debug) -->
<pre><!--#printenv --></pre>

私はロジックをフラットに保ち、入れ子を避け、変数を一箇所にまとめて文書化する（例えば. includes_priv/vars.inc.html)を通じて受け取った。 ファイル すべてのページに。.

SSIによるパフォーマンス、キャッシュ、CDN

パフォーマンス サーバーが完成したHTMLコードを出力するため、ブラウザの負担が減るからだ。私はこれを mod_deflate 或いは mod_brotli, そうすることで、転送量を小さく保つことができる。プロキシやアプリ・アクセラレータ・レベルのサーバーサイド・キャッシングは、さらにHTMLの結果をバッファリングすることができる。CDNはグローバルな配信に役立ちますが、SSIの解析はオリジンサーバーで引き続き行われます。正しい順序が重要であることに変わりはない：最初にレンダーがインクルードされ、次に完成したマークアップがキャッシュされる。 ホールド.

キャッシュヘッダ、ETag、ターゲット解析

ヘッダー ブラウザとプロキシがどのように結果を再利用するかを決定する。動的なフラグメントには、適度なmax-age値を使い、staleキャッシュを許可します：

にある
  ヘッダ set Cache-Control "public, max-age=600, stale-while-revalidate=30"
  ヘッダは Pragma を設定しない
</IfModule
# 矛盾を避けるためにETagsを標準化または無効化する
FileETag MTime Size

をすべて持っていない場合 .html を解析し、特定のファイルだけを解析すれば、リソースを節約できる。つの方法が証明されている：

FilesMatchのアプローチ： のみ *.inc.html で、これらのフラグメントを バーチャル 或いは ファイル 組み込む。.
XBitHack： と一緒に XBitHackフル 実行ビットが設定されたファイルだけが解析されます。さらに、Apache は 最終更新日-ヘッダはファイルのタイムスタンプに基づく。.

# XBitHackによる選択的解析
XBitHackフル
# chmod +xでファイルを「マーク」する
# chmod +x index.html

変更を加えた後、私はいつも 最終更新日 とキャッシュの動作が期待通りになるため、ユーザーはハード・リロードなしで新しいコンテンツを見ることができる。.

SSIとPHPおよびCMSの比較

比較このようになる：SSIは、モジュール化された静的なページに、動的な要素を少し加えるのに適している。PHPはアプリケーションロジック、フォーム、データベースアクセスをカバーしますが、メンテナンスが必要です。CMSは編集機能を提供するが、リソースがかかり、定期的な更新が必要だ。ランディングページ、ドキュメンテーション、定期的なモジュールのある小規模なウェブサイトの場合、私はSSIが無駄のないソリューションだと考えています。決断を下す前に、私はコンテンツとその組み合わせをチェックする。静的ページと動的ページ, アーキテクチャがターゲットにマッチするように、そして、簡単にできるように。 スケーラブル が残っている。

マイグレーション・パスとハイブリッド・アプローチ

実用的 switch: インクルードとしてヘッダー／フッターから始め、ナビゲーションと定期的なティーザーを追加し、特別なロジックはPHPかCMSに任せる。こうすることで、編集プロセスを中断することなく、テンプレートの重複を徐々に減らすことができます。完全に静的な領域（例えばドキュメント）については、SSIファーストで、独立したエンドポイント経由で動的な島（フォーム、検索）を埋め込むことができます。私は、各レイヤーがそのために構築されたものを正確に実行するように、カットを明確にしています。.

SSIプロジェクトのホスティング選定

セレクション はApacheの可用性に依存する、, mod_include, オーバーライドを許可する そして高速NVMeストレージ。私は無料の htaccess-を使用する。 .html を作動させることができる。CPUクロックが十分なプランでは、レスポンスタイムが短く、SSIの魅力がさらに高まります。マイグレーションなしでオプションを切り替えられるので、プロジェクトが大きくなってもアップグレードが簡単です。次の表は、SSIが得意とするプランの典型的な特徴を示しています。 サポート.

料金表	価格/月	メモリ	ワードプレスのページ	SSI対応
スターター	10 €	10 GB NVMe	1	はい（アパッチ）
プロ	47,60 €	75 GB NVMe	5	はい（アパッチ）
事業内容	95,20 €	150 GB NVMe	10	はい（アパッチ）

私は、キャッシュが機能し、予備が残るように、リソースをあまり厳しく計画していません。後からPHPやCMSを追加する場合、キャッシュに負荷をかけることなく、RAMやCPUに余裕を持たせることができます。 安定性 リスクに対して。.

故障診断とトラブルシューティング

問題点 多くの場合、HTMLソースコードに „生の “SSIコメントとして表示される。この場合、サーバはファイルを解析せず、通常 AddOutputFilter INCLUDES .html またはMIMEタイプが正しくない。また、ファイルが text/html とエディターの逆カンマが邪魔をしない。絶対パスでは ../-参照しても何も出てこない。というのも、サーバーのログを最後に見ることにしているからだ。原因リードします。

高度なトラブルシューティング：典型的な落とし穴

500 Internal Server Error への オプション に於いて htaccess を示すことが多い。 オーバーライドを許可する-制限をかける。解決策：サーバー側でオプションを設定するか、ホスティング業者に承認を求めてください。. 403禁 に於いて 仮想を含む はターゲットディレクトリのアクセス制限を示す。 インクルードファイル を作成し、ソース・ディレクトリへのHTTPアクセスをブロックする。. 文字セットまたはBOMの問題 (ファイル先頭の不可視文字)は奇妙な出力につながる可能性があります - BOMなしでUTF-8としてフラグメントを保存してください。ミニファイされたコードに異常な空白がある場合は、ビルドプロセスでコメント/SSIディレクティブが削除されているか確認してください。デバッグセッションのために、私は一時的に 。, ヘッダーと変数を検査するために使用し、その後再び無効にする。.

リバースプロキシと最新のセットアップ

建築をNginxやTraefikのようなアップストリームプロキシと組み合わせることで、Apacheがバックグラウンドでレンダリングできるようになります。プロキシはTLS、キャッシュ、圧縮を行い、Apacheはインクルードを解析し、完成したHTMLを配信します。これにより、低遅延とSSIの柔軟性を組み合わせることができます。の概要を読むリバースプロキシの設定, ルーティングを計画する前に。私はシンプルなチェーンから始めて、段階を追って拡張していくのが好きです。 パフォーマンス 的な方法で。.

互換性と動作モード

互換性Apacheは、ここで説明するSSIの使用法の対象システムです。一般的なSSI構文は通常サポートされています。Nginxは異なる構文で独自のSSI機能を持っています。混合環境では、Nginxは通常プロキシタスクを実行し、ApacheはSSI解析を処理します。Apache MPMでは イベント PHP-FPMと組み合わせて）静的/SSIを多用するサイトでは、接続をより効率的に保つことができるからだ。Preforkを使うのは、レガシーモジュールが必要な場合だけです。.

デプロイメント、バージョン管理、品質保証

プロセス クリーンに保つ：フラグメントと変数ファイルはバージョン管理に属する。私は標準を定義している。 .inc.html, ディレクトリ構造 /インクルード そして /includes_priv/)、includeが解決できるかどうかをコミットごとにチェックする。小さなCIステップで、ステージングビルドをアップロードし、キャッシュをクリアし、テストインクルードを含むヘルスページを取得することができます。最小限のテストはすぐにビルドされる：

<!-- test.shtml -->
<!--#config timefmt="%Y-%m-%d %H:%M:%S" -->
サーバー時間： <!--#echo var="DATE_LOCAL" --><br>
URI： <!--#echo var="DOCUMENT_URI" --><br>
含む： <!--#include virtual="/includes/header.html" -->

このページが失敗する場合、ほとんどの場合、基本的なコンフィギュレーション（解析、権利、パス）に問題がある。数分でロールバックできるように、小さなチェックリストを用意しています。.

クリーンなSSIのためのコンパクトなチップ

パス私は絶対にそうする /includes/header.html 相対参照の代わりに、サブフォルダー内のバインディングが安定するように。変数の使用は控えめにし、名前を明確にする。 site_env 或いは 構築日. .私はステージング環境で変更をテストし、ダウンタイムを避けるために、その変更だけを本番環境にコピーする。を変更する前に htaccess 必要に応じてすぐに元に戻せるように、現在のバージョンを保存しておきます。デプロイ後は、ブラウザとサーバーのキャッシュをクリアして、ユーザーが古い成果物なしで新しいバージョンを使えるようにします。参照.

SSIの拡張機能をターゲットに使用

エックスエスアイ は単純な条件と可変ロジックをもたらしますが、パースを軽量に保つために意図的に制限されたままです。典型的なケースは、ディレクトリごとに異なるバナーや、言語バージョンごとに1つのヒントです。条件はで閉じる。 <!. .計算ロジックの場合は、PHPに切り替えるか、あらかじめビルドプロセスに出力を組み込んでおく方がよいでしょう。ページが読みやすくなるように、また デバッグ 素早く。.

プレーンテキストでの要約

結論として SSIは、送信前に繰り返されるコンテンツをマージすることで、高速で保守性の高いページを提供します。のほんの数行で htaccess のパージングを有効にする。 .html で、プロジェクトの構造をスリムに保つことができます。セキュリティは、制限付き権限と #exec; 共有環境での保護 NOEXECを含む. .NVMeストレージ、クリーンキャッシュ、そして必要であればアップストリームプロキシがスピードを保証する。モジュール方式で構築し、オーバーヘッドを排除したい場合は、SSIホスティングに頼り、ウェブサーバーの設定をクリーンで安全なものにし、それを何年も維持する。 シンプル.