サーバーオプション

特記されていない限り、このセクションのオプションは開発環境にのみ適用されます。

server.host

型: string | boolean
デフォルト: 'localhost'

サーバーがリッスンする IP アドレスを指定します。LAN およびパブリックアドレスを含むすべての IP アドレスでリッスンするには、0.0.0.0 または true に設定します。

これは、CLI で --host 0.0.0.0 または --host を使用して設定できます。

注意

Vite 以外のサーバーが応答する場合もあります。

最初のケースは localhost が使われる場合です。Node.js v17 未満では、デフォルトで DNS 解決されたアドレスの結果が並べ替えられます。localhost にアクセスすると、ブラウザーは DNS を使ってアドレスを解決し、そのアドレスは Vite がリッスンしているアドレスと異なる場合があります。Vite は、アドレスが異なる場合に解決されたアドレスを出力します。

並べ替え動作を無効にするには、dns.setDefaultResultOrder('verbatim') を設定できます。Vite は、その場合、アドレスを localhost として出力します。

vite.config.js

import { defineConfig
 } from 'vite'
import dns
 from 'node:dns'

dns
.setDefaultResultOrder
('verbatim')

export default defineConfig
({
  // omit
})

2 番目のケースは、ワイルドカードホスト (例: 0.0.0.0) が使われる場合です。これは、ワイルドカードでないホストでリッスンしているサーバーが、ワイルドカードホストでリッスンしているサーバーよりも優先されるためです。

WSL2 上のサーバーに LAN からアクセスする

WSL2 で Vite を実行している場合、LAN からサーバーにアクセスするには host: true を設定するだけでは不十分です。詳細は WSL ドキュメントを参照してください。

server.allowedHosts

型: string[] | true
デフォルト: []

Vite が応答を許可するホスト名。localhost、.localhost ドメイン以下、およびすべての IP アドレスはデフォルトで許可されます。HTTPS を使用している場合、このチェックはスキップされます。

文字列が . で始まる場合、. なしのホスト名とそのホスト名以下のすべてのサブドメインが許可されます。たとえば、.example.com は example.com、foo.example.com、foo.bar.example.com を許可します。true に設定すると、サーバーは任意のホストからのリクエストに応答できます。

どのホストが安全に追加できますか？

IP アドレスを解決する権限をあなたが持っているホストは、許可されたホストのリストに安全に追加できます。

たとえば、あなたがドメイン vite.dev を所有している場合、vite.dev と .vite.dev をリストに追加できます。そのドメインを所有しておらず、そのドメインの所有者を信頼できない場合は、追加しないでください。

特に、.com のようなトップレベルドメインをリストに追加してはいけません。これは、誰でも example.com のようなドメインを購入し、それが解決される IP アドレスを制御できるためです。

危険

server.allowedHosts を true に設定すると、任意のウェブサイトが DNS リバインディング攻撃を介して開発サーバーにリクエストを送信し、ソースコードやコンテンツをダウンロードできるようになります。常に許可されたホストの明示的なリストを使用することをお勧めします。詳細は GHSA-vg6x-rcgg-rjx6 を参照してください。

環境変数による設定

環境変数 __VITE_ADDITIONAL_SERVER_ALLOWED_HOSTS を設定することで、追加の許可されたホストを追加できます。

server.port

型: number
デフォルト: 5173

サーバーポートを指定します。このポートが既に使用されている場合、Vite は自動的に次の利用可能なポートを試行するため、これがサーバーが最終的にリッスンする実際のポートではない可能性があることに注意してください。

server.strictPort

型: boolean

ポートがすでに使用されている場合、次の利用可能なポートを自動的に試行する代わりに終了するには true に設定します。

server.https

型: https.ServerOptions

TLS + HTTP/2 を有効にします。値は https.createServer() に渡されるオプションオブジェクトです。

これは、server.proxy オプションも使用されている場合にのみ TLS にダウングレードすることに注意してください。

有効な証明書が必要です。基本的な設定では、@vitejs/plugin-basic-ssl をプロジェクトプラグインに追加すると、自己署名証明書が自動的に作成されキャッシュされます。しかし、独自の証明書を作成することをお勧めします。

server.open

型: boolean | string

サーバー起動時にブラウザでアプリを自動的に開きます。値が文字列の場合、URL のパス名として使用されます。特定のブラウザでサーバーを開きたい場合は、環境変数 process.env.BROWSER (例: firefox) を設定できます。追加の引数を渡すには process.env.BROWSER_ARGS (例: --incognito) を設定することもできます。

BROWSER と BROWSER_ARGS は、.env ファイルで設定できる特殊な環境変数でもあります。詳細は open パッケージを参照してください。

例

export default defineConfig({
  server: {
    open: '/docs/index.html',
  },
})

server.proxy

型: Record<string, string | ProxyOptions>

開発サーバーのカスタムプロキシングルールを設定します。{ key: options } のペアのオブジェクトを期待します。リクエストパスがそのキーで始まるすべてのリクエストは、指定されたターゲットにプロキシされます。キーが ^ で始まる場合、それは RegExp として解釈されます。configure オプションを使用してプロキシインスタンスにアクセスできます。リクエストがいずれかの設定されたプロキシングルールに一致する場合、そのリクエストは Vite によって変換されません。

非相対的な base を使用している場合、各キーにその base をプレフィックスとして付ける必要があることに注意してください。

http-proxy を拡張します。追加のオプションはこちらにあります。

場合によっては、基盤となる開発サーバーを構成したい場合もあります（例：内部の connect アプリにカスタムミドルウェアを追加する場合）。そのためには、独自のプラグインを作成し、configureServer 関数を使用する必要があります。

例

export default defineConfig({
  server: {
    proxy: {
      // string shorthand:
      // https://:5173/foo
      //   -> https://:4567/foo
      '/foo': 'https://:4567',
      // with options:
      // https://:5173/api/bar
      //   -> http://jsonplaceholder.typicode.com/bar
      '/api': {
        target: 'http://jsonplaceholder.typicode.com',
        changeOrigin: true,
        rewrite: (path) => path.replace(/^\/api/, ''),
      },
      // with RegExp:
      // https://:5173/fallback/
      //   -> http://jsonplaceholder.typicode.com/
      '^/fallback/.*': {
        target: 'http://jsonplaceholder.typicode.com',
        changeOrigin: true,
        rewrite: (path) => path.replace(/^\/fallback/, ''),
      },
      // Using the proxy instance
      '/api': {
        target: 'http://jsonplaceholder.typicode.com',
        changeOrigin: true,
        configure: (proxy, options) => {
          // proxy will be an instance of 'http-proxy'
        },
      },
      // Proxying websockets or socket.io:
      // ws://:5173/socket.io
      //   -> ws://:5174/socket.io
      // Exercise caution using `rewriteWsOrigin` as it can leave the
      // proxying open to CSRF attacks.
      '/socket.io': {
        target: 'ws://:5174',
        ws: true,
        rewriteWsOrigin: true,
      },
    },
  },
})

server.cors

型: boolean | CorsOptions
デフォルト: { origin: /^https?:\/\/(?:(?:[^:]+\.)?localhost|127\.0\.0\.1|\[::1\])(?::\d+)?$/ } (localhost, 127.0.0.1, ::1 を許可)

開発サーバーの CORS を設定します。動作を微調整するためのオプションオブジェクトを渡すか、任意のオリジンを許可するには true を渡します。

危険

server.cors を true に設定すると、任意のウェブサイトが開発サーバーにリクエストを送信し、ソースコードやコンテンツをダウンロードできるようになります。常に許可されたオリジンの明示的なリストを使用することをお勧めします。

server.headers

型: OutgoingHttpHeaders

サーバー応答ヘッダーを指定します。

server.hmr

型: boolean | { protocol?: string, host?: string, port?: number, path?: string, timeout?: number, overlay?: boolean, clientPort?: number, server?: Server }

HMR 接続を無効にするか設定します (HMR WebSocket が HTTP サーバーとは異なるアドレスを使用する必要がある場合)。

サーバーエラーオーバーレイを無効にするには server.hmr.overlay を false に設定します。

protocol は、HMR 接続に使用される WebSocket プロトコルを設定します: ws (WebSocket) または wss (WebSocket Secure)。

clientPort は、クライアント側でのみポートをオーバーライドする高度なオプションで、WebSocket をクライアントコードが探すポートとは異なるポートで提供できるようにします。

server.hmr.server が定義されている場合、Vite は提供されたサーバーを介して HMR 接続リクエストを処理します。ミドルウェアモードでない場合、Vite は既存のサーバーを介して HMR 接続リクエストを処理しようとします。これは、自己署名証明書を使用している場合や、単一ポートで Vite をネットワーク経由で公開したい場合に役立ちます。

いくつかの例については、vite-setup-catalogue をチェックしてください。

注意

デフォルト設定では、Vite の前にあるリバースプロキシは WebSocket のプロキシをサポートしていると想定されます。Vite HMR クライアントが WebSocket への接続に失敗した場合、クライアントはリバースプロキシをバイパスして Vite HMR サーバーに直接 WebSocket を接続するフォールバックを行います。

Direct websocket connection fallback. Check out https://vite.dokyumento.jp/config/server-options.html#server-hmr to remove the previous connection error.

フォールバックが発生したときにブラウザに表示されるエラーは無視できます。リバースプロキシを直接バイパスすることでエラーを回避するには、次のいずれかの方法があります。

リバースプロキシを設定して WebSocket もプロキシする
server.strictPort = true を設定し、server.hmr.clientPort を server.port と同じ値に設定する
server.hmr.port を server.port とは異なる値に設定する

server.warmup

型: { clientFiles?: string[], ssrFiles?: string[] }
関連: 頻繁に利用するファイルのウォームアップ

ファイルをウォームアップして、事前に結果を変換・キャッシュします。これにより、サーバー起動時の初期ページロードが改善され、変換の連鎖的な発生を防ぎます。

clientFiles はクライアントのみで使用されるファイル、ssrFiles は SSR のみで使用されるファイルです。これらは、root からの相対パスとして、ファイルパスまたは tinyglobby パターンの配列を受け入れます。

Vite 開発サーバーの起動時に過負荷にならないように、頻繁に使用されるファイルのみを追加するようにしてください。

export default defineConfig({
  server: {
    warmup: {
      clientFiles: ['./src/components/*.vue', './src/utils/big-utils.js'],
      ssrFiles: ['./src/server/modules/*.js'],
    },
  },
})

server.watch

型: object | null

chokidar に渡すファイルシステムウォッチャーオプション。

Vite サーバーウォッチャーは、デフォルトで root を監視し、.git/、node_modules/、Vite の cacheDir、および build.outDir ディレクトリをスキップします。監視対象のファイルを更新すると、Vite は必要に応じて HMR を適用し、ページを更新します。

null に設定すると、ファイルは監視されません。server.watcher は互換性のあるイベントエミッターを提供しますが、add または unwatch を呼び出しても効果はありません。

node_modules 内のファイルを監視する

現在、node_modules 内のファイルやパッケージを監視することはできません。さらなる進捗や回避策については、issue #8619 をフォローしてください。

Windows Subsystem for Linux (WSL) 2 で Vite を使用する

WSL2 で Vite を実行している場合、Windows アプリケーション (WSL2 以外のプロセス) でファイルを編集しても、ファイルシステム監視は機能しません。これは WSL2 の制限によるものです。これは、WSL2 バックエンドを持つ Docker 上で実行している場合にも当てはまります。

これを修正するには、次のいずれかの方法があります。

推奨: WSL2 アプリケーションを使用してファイルを編集する。
- また、プロジェクトフォルダーを Windows ファイルシステムの外に移動することもお勧めします。WSL2 から Windows ファイルシステムにアクセスするのは遅いです。そのオーバーヘッドを取り除くことでパフォーマンスが向上します。
{ usePolling: true } を設定する。
- usePolling は CPU 使用率が高くなることに注意してください。

server.middlewareMode

型: boolean
デフォルト: false

ミドルウェアモードで Vite サーバーを作成します。

関連: appType, SSR - 開発サーバーの設定
例

import express
 from 'express'
import { createServer
 as createViteServer
 } from 'vite'

async function createServer
() {
  const app
 = express
()

  // Create Vite server in middleware mode
  const vite
 = await createViteServer
({
    server
: { middlewareMode
: true },
    // don't include Vite's default HTML handling middlewares
    appType
: 'custom',
  })
  // Use vite's connect instance as middleware
  app
.use
(vite
.middlewares
)

  app
.use
('*', async (req
, res
) => {
    // Since `appType` is `'custom'`, should serve response here.
    // Note: if `appType` is `'spa'` or `'mpa'`, Vite includes middlewares
    // to handle HTML requests and 404s so user middlewares should be added
    // before Vite's middlewares to take effect instead
  })
}

createServer
()

server.fs.strict

型: boolean
デフォルト: true (Vite 2.7 以降デフォルトで有効)

ワークスペースルート外からのファイル提供を制限します。

server.fs.allow

型: string[]

/@fs/ 経由で提供できるファイルを制限します。server.fs.strict が true に設定されている場合、許可されたファイルからインポートされていないこのディレクトリリスト外のファイルにアクセスすると、403 エラーになります。

ディレクトリとファイルの両方を指定できます。

Vite は潜在的なワークスペースのルートを検索し、それをデフォルトとして使用します。有効なワークスペースは以下の条件を満たしており、それ以外の場合はプロジェクトルートにフォールバックします。

package.json に workspaces フィールドが含まれている
以下のいずれかのファイルが含まれている
- lerna.json
- pnpm-workspace.yaml

カスタムワークスペースルートを指定するためのパスを受け入れます。絶対パスまたはプロジェクトルートからの相対パスを指定できます。例:

export default defineConfig({
  server: {
    fs: {
      // Allow serving files from one level up to the project root
      allow: ['..'],
    },
  },
})

server.fs.allow が指定されている場合、自動ワークスペースルート検出は無効になります。元の動作を拡張するために、ユーティリティ searchForWorkspaceRoot が公開されています。

import { defineConfig, searchForWorkspaceRoot } from 'vite'

export default defineConfig({
  server: {
    fs: {
      allow: [
        // search up for workspace root
        searchForWorkspaceRoot(process.cwd()),
        // your custom rules
        '/path/to/custom/allow_directory',
        '/path/to/custom/allow_file.demo',
      ],
    },
  },
})

server.fs.deny

型: string[]
デフォルト: ['.env', '.env.*', '*.{crt,pem}', '**/.git/**']

Vite 開発サーバーが提供することを制限する機密ファイルのブロックリスト。server.fs.allow よりも優先順位が高くなります。picomatch パターンがサポートされています。

注意

このブロックリストは public ディレクトリには適用されません。public ディレクトリ内のすべてのファイルは、ビルド時に出力ディレクトリに直接コピーされるため、フィルターなしで提供されます。

server.origin

型: string

開発中に生成されるアセット URL のオリジンを定義します。

export default defineConfig({
  server: {
    origin: 'http://127.0.0.1:8080',
  },
})

server.sourcemapIgnoreList

型: false | (sourcePath: string, sourcemapPath: string) => boolean
デフォルト: (sourcePath) => sourcePath.includes('node_modules')

サーバーのソースマップでソースファイルを無視するかどうかを決定し、x_google_ignoreList ソースマップ拡張機能を埋めるために使用されます。

server.sourcemapIgnoreList は、開発サーバーにおける build.rollupOptions.output.sourcemapIgnoreList と同等です。2 つの設定オプションの間の違いは、rollup 関数が sourcePath に相対パスで呼び出されるのに対し、server.sourcemapIgnoreList は絶対パスで呼び出されることです。開発中、ほとんどのモジュールは同じフォルダーにマップとソースを持っているため、sourcePath の相対パスはファイル名自体です。このような場合、絶対パスを使用すると便利です。

デフォルトでは、node_modules を含むすべてのパスが除外されます。この動作を無効にするには false を渡すか、完全に制御するには、ソースパスとソースマップパスを受け取り、ソースパスを無視するかどうかを返す関数を渡します。

export default defineConfig({
  server: {
    // This is the default value, and will add all files with node_modules
    // in their paths to the ignore list.
    sourcemapIgnoreList(sourcePath, sourcemapPath) {
      return sourcePath.includes('node_modules')
    },
  },
})

注意

server.sourcemapIgnoreList と build.rollupOptions.output.sourcemapIgnoreList は個別に設定する必要があります。server.sourcemapIgnoreList はサーバー専用の設定であり、定義された Rollup オプションからデフォルト値を取得することはありません。

サーバーオプション ​

server.host ​

server.allowedHosts ​

server.port ​

server.strictPort ​

server.https ​

server.open ​

server.proxy ​

server.cors ​

server.headers ​

server.hmr ​

server.warmup ​

server.watch ​

server.middlewareMode ​

server.fs.strict ​

server.fs.allow ​

server.fs.deny ​

server.origin ​

server.sourcemapIgnoreList ​