広告が嫌いですか? 行く広告なし今日 

Apache httpd Config Formatter

開発者ネットワーキング

広告削除する？

入力

自動処理

出力

クライアント側

広告削除する？

ガイド

Apache httpd Config Formatter

Paste a messy Apache httpd.conf, apache2.conf、または sites-available/*.conf snippet and get back a properly indented, normalized configuration. The formatter walks <VirtualHost>, <Directory>, <Location>, <IfModule>, and other container tags to compute correct nesting depth, preserves your comments and blank lines, and can canonicalize directive case so that servername, SERVERNAMEと、 ServerName all become consistent. The structure view summarizes each virtual host at a glance, and the validator flags mismatched or unclosed block tags before you reload Apache.

使用方法

Paste your Apache configuration into the input box — a full httpd.conf, a single <VirtualHost> block, or any snippet.
Pick an indent style (2 spaces, 4 spaces, or tab) and a directive case mode (preserve, PascalCase canonical, or lowercase).
トグル Normalize comments to ensure a space after #, 複数の空白行を結合と、 ディレクティブ値を配置 if you want columns padded inside each block.
Copy the formatted output, or download it as httpd.conf. Use the structure view to confirm your virtual-host layout and the validator to catch mismatched or unclosed block tags.

機能

Block-aware indentation – Tracks nesting through <VirtualHost>, <Directory>, <Location>, <Files>, <FilesMatch>, <IfModule>, <Limit>, <RequireAll>, and other container tags.
Directive case normalization – Optionally rewrite directives to canonical PascalCase (ServerName, DocumentRoot, RewriteEngine) or fold them to lowercase.
Continuation-line aware – Joins lines ending with \ so wrapped RewriteRule または SSLCipherSuite directives stay on one logical line.
Comment & blank-line preservation – Keeps your # ... comments in place, optionally normalizes spacing after the hash, and collapses runs of blank lines.
Structure view – A nested outline of every block with key details (ServerName, DocumentRoot, Listen, ProxyPass) extracted for quick scanning.
検証 – Flags mismatched openers and closers (e.g. <Directory> closed with </Location>), unclosed blocks, stray closing tags, and duplicate ServerName values.
Snippet library – Drop-in templates for HTTP/HTTPS virtual hosts, HTTPS redirects, reverse proxies, PHP-FPM handlers, mod_rewrite force-HTTPS, mod_deflate compression, browser caching, security headers, and Basic Auth.
Directive reference – At-a-glance reference for the most common directives and container tags.
プライバシー – Runs entirely in your browser. Configurations are never uploaded.

 よくある質問

What is the difference between httpd.conf and a .htaccess file?

httpd.conf (and the per-site files under sites-available/) is the main server configuration, parsed once when Apache starts. .htaccess files are per-directory overrides that Apache re-reads on every request when AllowOverride permits it. Both use the same directive syntax, but .htaccess can only contain directives whose context allows directory scope, and using it has a measurable performance cost compared to putting the same rules in a <Directory> block in the main config.
Are Apache directive names case-sensitive?

No. Directive names like ServerName, servername, and SERVERNAME are all valid and equivalent. Apache documentation uses PascalCase as the canonical form, which is what most style guides and config linters expect. Directive arguments, however, are often case-sensitive (filesystem paths on Linux, regular expressions, environment variable names, and so on).
How does Apache decide which VirtualHost serves a request?

Apache first matches by IP address and port from the <VirtualHost> tag (e.g. *:443). Among virtual hosts that match the same address and port, it then matches the request's Host header against ServerName and ServerAlias. If nothing matches, the first VirtualHost listed for that address:port becomes the default. This is why ServerName must be explicit and unique on a real production server.
What is the order of evaluation between Directory, Location, and Files blocks?

Apache merges sections in a defined order: <Directory> and .htaccess first, then <Files> and <FilesMatch>, then <Location> and <LocationMatch>. Within each group, non-regex sections are processed first, in shortest-to-longest path order, then regex variants in source order. <Location> runs last, which is why a Location block can override directives set in a Directory block above it.
Why do block tags use ... instead of curly braces like Nginx?

Apache's configuration grammar predates Nginx by about a decade and was modeled on SGML/HTML, where container scopes are written with paired open/close tags. Nginx chose a C-like brace style for compactness. Both grammars express the same idea — a directive that scopes a child set of directives — but Apache's tag pairs make mismatched closers easy to spot since the closing tag must name the block being closed.