fein's personal site

個人サイト制作：サイトマップへ戻る

独自ドメイン設定後にリダイレクト機能を追加する

このコードはFlaskの機能を使っており、サーバーサイドスクリプトに該当します。
次のように動作するリダイレクト機能を実装する方法を、このページには書いていきます。
注意したい独自ドメイン設定手順とルールの続きとも言えますね。

1. Flaskモジュールの使用:

Flaskクラスをインスタンス化してappとして使用しています。
Flaskはサーバーサイドフレームワークなので、このコードはサーバーサイドスクリプトです。

2. ルーティング（@app.route()）:

URLのルーティングを設定し、クライアントからのリクエストを処理しています。
この場合、すべてのURLリクエストをキャッチし、リダイレクト処理へ渡しています。

3. redirect関数:

サーバー側で新しいURLにリクエストをリダイレクトしています。
redirectはFlaskの標準的なサーバーサイド処理の一部です。

4. requestオブジェクト:

クライアントからのHTTPリクエスト情報を取得し、リクエストURLを基に新しいURLを構築しています。

このコードの構成を見ると、典型的なサーバーサイドスクリプトと言えます。
リクエストされたURLを動的に書き換え、新しいURLにリダイレクトする処理を行っていますし、実行はサーバー上で行われ、クライアント（ユーザーのブラウザ）にはリダイレクト先のURLだけが通知されます。

App Engineのリダイレクト設定

リダイレクト設定を自分で行うなら、自身のサイトの構造を知る必要があります。
このような構造は一般的に「プロジェクト構成」や「ディレクトリ構造」と呼ばれます。
私の場合、Google App Engineにデプロイされていて、動的Webサイト（Flask使用）と静的Webサイトが混在しているのが特徴となっています。

FEIN-SITES-DEV1
│  app.yaml           # メインサービスの App Engine 設定ファイル（ランタイム・ルート定義など）
│  dispatch.yaml      # サービス間のルーティング規則を定義するファイル
│  main.py            # Flask アプリケーションのエントリポイント（ルートや動的機能の設定）
│  README.md          # プロジェクトの概要や使い方を説明するドキュメント
│  requirements.txt   # アプリで必要な Python パッケージ（依存関係）のリスト
├─redirect-service    # リダイレクト専用サービスのディレクトリ
│      app.yaml       # リダイレクト用サービスの App Engine 設定ファイル
│      redirect.py    # リダイレクト処理を記述した Flask アプリケーション
│      requirements.txt # リダイレクト用サービスで必要な Python パッケージのリスト
├─static              # 静的ファイルを保存するディレクトリ（CSS, JavaScript, 画像など）
│  ├─css              # スタイルシート（デザイン）を格納
│  ├─js               # JavaScript（インタラクションや動作制御）のスクリプトを格納
│  └─menu             # メニュー関連のリソースを保存
├─templates           # Flask 用の HTML テンプレートを保存
│      top.html       # `/top` ルート用の動的コンテンツテンプレート
│
│   【上側がFlaskフレームワーク。サーバーサイドスクリプトを活用した動的Webサイトです。】
│   【下側が普通のホームぺージ。フロントエンド3言語による静的Webサイトです。】
│
└─www                 # 静的ウェブサイトのルートディレクトリ（主にフロントエンド用）
    │  favicon.ico    # ブラウザのタブに表示されるアイコン
    │  index.html     # 静的ウェブサイトのホームページ
    │  manifest.json  # PWA（Progressive Web App）の設定ファイル
    │  robots.txt     # 検索エンジンによるクローリング設定ファイル
    │  service-worker.js # PWA 用のサービスワーカー（キャッシュ管理やオフライン対応）
    ├─contents        # コンテンツ関連のファイルやデータを格納
    ├─css             # 静的ウェブサイト専用のスタイルシートを保存
    ├─fish            # 画像やリソース用ディレクトリ
    ├─script          # フロントエンド用 JavaScript を格納

この構造は、「Webアプリケーションを動かすためのファイルやフォルダを整理した箱」と考えると分かりやすいです。
それぞれの部分に役割があり、全体が一緒になって動きます。

1. メインサービス（上側部分）

この部分は、サーバー側（バックエンド）で動く頭脳のようなものです。
サーバーが「お客さん（訪問者）のリクエスト」を受け取ったり、必要な情報を探して返す役割を持ちます。

main.py

サーバーの中核部分。
お客さんが「/aboutページ見せて」と頼んだら、それに応じる処理を書く。

app.yaml

サーバーの設定を記述。
「どう動くのか」「どの言語（Python）で動かすか」を教える説明書。

templates/

見た目（HTML）を動的に生成するファイルの置き場所。

2. リダイレクト専用サービス

このセクションで集中的に見ていくエリアです。
リダイレクトとは、「訪問者を自動で別のページに連れて行く」仕組みです。
例えば、「古いページに来た人を新しいページに案内」するときなどに使います。

私の場合、他のエリアと同じようにPythonで書かれた小さな追加サービスとなっています。
別のサーバーでも動かせるよう、ファイルが独立しています。

3. 静的ファイル（下側部分）

静的ファイルは、「サーバー側で処理がいらない見た目のページや素材」の集まりです。単純にブラウザで読まれるだけの部分ですよね。
何かしらの紹介ページ（HTMLファイル）や、デザインの色や形を決めるCSSファイル、ボタンの動きを制御するJavaScriptファイルなどがあります。

css/

ページのデザインや色、フォントを決めるファイル。

script/

ページ上で動くプログラムを置く場所（例えば、ボタンをクリックしたときに動く仕組み）。

favicon.ico

ブラウザのタブに表示される小さいアイコン。

プロジェクト構成の全体像

1. サーバーが訪問者のリクエストを受け取る（例えば、「トップページを見たい」）。
2. サーバーが「バックエンド（動的部分）」でそのリクエストを処理する。
3. 必要に応じて「静的ファイル」を利用しながら、最終的なページを作成して訪問者のブラウザに返す。

この構造の強みは、「動的な処理」と「静的な素材」をうまく組み合わせて使える点です。
簡単にいうと、「頭を使って動く部分」（サーバー処理）と、「見た目を支える部分」（静的ファイル）が一緒に整理されていて、効率よく作業できるようになっています。

では、リダイレクト設定を行うソースコードを見ていきます。

リダイレクト設定を行うredirect.py

import os
from flask import Flask, request, redirect

app = Flask(__name__)

@app.route('/', defaults={'path': ''})
@app.route('/<path:path>')
def redirect_all(path):
    # クエリ文字列も含めた完全な URL を作成
    new_url = request.url.replace(request.host, 'feinatelier.org', 1)
    return redirect(new_url, code=301)

if __name__ == '__main__':
    port = int(os.environ.get('PORT', 8080))
    debug_mode = os.getenv('FLASK_DEBUG', 'False').lower() == 'true'  # デバッグモードを環境変数で制御
    app.run(host='0.0.0.0', port=port, debug=debug_mode)

このコードを動かすと、例えば「http://example.com/some-page」にアクセスした人を自動的に「http://feinatelier.org/some-page」に転送してくれる、という仕組みです。

1. ユーザーがリクエスト（ページにアクセス）。
2. Flaskアプリがそのリクエストを受け取る。
3. 新しいURLを作成し、ユーザーをそこに転送。

コードの部分ごとの説明をしていきます。

ライブラリの読み込み

import os
from flask import Flask, request, redirect

import os

環境変数やシステム関連の情報を扱うための標準モジュールです。

from flask import ...

FlaskはPythonでWebアプリを作るためのフレームワーク（便利ツールセット）です。
このコードではその一部の機能を使っています。

Flask

Webアプリの土台を作るためのクラス。

request

ユーザーのアクセス情報（URLやリクエスト内容など）を取得するために使用します。

redirect

別のURLに転送するための便利な関数です。

Flaskアプリの初期化

app = Flask(__name__)

役割

この一行でアプリケーションの土台を作成します。
「Flaskを使ってアプリを動かしますよー」という合図のようなものです。

リダイレクトのルート設定

@app.route('/', defaults={'path': ''})
@app.route('/<path:path>')
 def redirect_all(path):

@app.route(...)

訪問者がどのURL（パス）にアクセスしても、この関数が実行されるよう設定しています。

/

ルートパス（トップページ）用の設定。

<path:path>

任意のパス（例: /about や /contact）に対応します。

関数の中身

new_url = request.url.replace(request.host, 'feinatelier.org', 1)
return redirect(new_url, code=301)

request.url

ユーザーがアクセスした元のURLを取得します。

.replace(request.host, 'feinatelier.org', 1)

URLの中のホスト名（request.host = 現在のドメイン）を、feinatelier.orgに置き換えます。

redirect(...)

作成した新しいURLに転送します。

code=301

HTTPステータスコードで「恒久的なリダイレクト」を意味します。

アプリの起動

if __name__ == '__main__':
port = int(os.environ.get('PORT', 8080))
debug_mode = os.getenv('FLASK_DEBUG', 'False').lower() == 'true'
app.run(host='0.0.0.0', port=port, debug=debug_mode)

if __name__ == '__main__':

このコードが直接実行されるときにだけ動く部分を指定しています。

環境変数からポート番号とデバッグモードを取得

os.environ.get('PORT', 8080)

環境変数からポート番号を取得。指定がない場合はデフォルトで8080番を使用します。

os.getenv('FLASK_DEBUG', 'False').lower() == 'true'

デバッグモードをON/OFFする設定。

app.run(...)

アプリケーションを起動します。

host='0.0.0.0':
どのIPアドレスからのアクセスも受け付ける設定。

port=port:
ここで設定されたポート番号を使います。

debug=debug_mode:
デバッグモードを環境変数でON/OFFできます。

リダイレクト実装方法の選択肢

私のプロジェクト構成の場合、次の2つの変更方法が考えられました。
どちらも「default URL → 独自ドメイン」へのリダイレクトを実現できます。

1. シンプルにコードで処理したい場合

main.py に @app.before_request を追加してリダイレクト。
ただし、app.yaml の静的ハンドラは Flask 経由にならないため、すべてのリクエストに適用するには app.yaml の設定変更が必要でした。

2. 静的ハンドラもそのまま活かしたい場合

別途リダイレクト専用サービスを構築し、dispatch.yaml で default URL（fein-sites-dev1.ew.r.appspot.com）から振り分ける方法を採用する。

こういうときどちらの方法をとるかは、運用のしやすさで考えたほうが良いと思うんですよね。
どちらの方法でも「default URL から独自ドメインへの恒久リダイレクト (HTTP 301)」が実現できますが…
私は2.の静的ハンドラもそのまま活かす方を選択しています。
なぜ2.を選んだのかは、追って説明していきます。

リダイレクト設定を行うdispatch.yaml

dispatch:
  - url: "fein-sites-dev1.ew.r.appspot.com/*"
    service: redirect-service

このファイルは、Google App Engineでアプリケーション内のトラフィックルーティングを設定するために使います。
「どのリクエスト（URL）をどのサービスに送るか」を決めるルールを書いているってことです。

1. ユーザーが「fein-sites-dev1.ew.r.appspot.com/」にアクセスする。
2. dispatch.yaml を使って「このリクエストは redirect-service に送るべき」と判断する。
3. redirect-service が実行され、別のURL（例: http://feinatelier.org）にリダイレクトします。

1. dispatch:
このファイルで「どのリクエストをどのサービスに送るか」という指示を開始します。

2. - url: "fein-sites-dev1.ew.r.appspot.com/*"
ここでは、「すべてのURL（例: /about や /contact）」が含まれるこのドメイン（fein-sites-dev1.ew.r.appspot.com）に対するリクエストをキャッチします。

*

これはワイルドカードと呼ばれ、「すべてのURLを含む」という意味です。

例

以下すべてのリクエストを対象にします。

http://fein-sites-dev1.ew.r.appspot.com/

http://fein-sites-dev1.ew.r.appspot.com/about

http://fein-sites-dev1.ew.r.appspot.com/contact

3. service: redirect-service
上記のURLリクエストを redirect-service に送ります。
これはGoogle App Engine内で動作するサービスの名前で、リダイレクト処理を行うサービスを指します。

このファイルは、Google App Engineの中でどの機能をどのリクエストに対応させるかを分ける「交通整理」の役割を持っています。
エラーが出るとすべてのリクエストが止まる可能性があるため、修正する際には注意が必要です。

App Engineで複数のサービスを構成する

App Engine では、複数のサービスを持つ場合、各サービスごとに独自の app.yaml を配置します。
つまりこのプロジェクト内に複数の app.yaml が存在する形になりますが、これは正常な構成です。
メインサービス用とリダイレクト専用のサービス用、2つの app.yaml が存在するわけです。

また、プロジェクトルートに配置する dispatch.yaml によって、 https://fein-sites-dev1.ew.r.appspot.com/ へのリクエストがリダイレクト用サービスに転送されるので、メインサービスの app.yaml に手を加える必要がないのです。

リダイレクト設定に使うrequirements.txt

Flask==2.3.2
gunicorn==20.1.0

このファイルは、Pythonで作られたアプリケーションに必要なライブラリやツールの一覧を記載したものです。
アプリケーションを動かす際に、「どのバージョンのライブラリが必要なのか」を指定します。

1. このrequirements.txtを使って必要なライブラリをインストールします（pip install -r requirements.txt）。
2. FlaskはWebアプリを動かすためのコードを書く部分をサポート。
3. Gunicornは、そのアプリを外部（訪問者）からアクセスできる形で動作させます。

ここではPythonのWebフレームワークのFlask==2.3.2を使うよう指定しています。
FlaskはWebアプリを作るためのツールセットです。
例えば、リクエストを受け取ってレスポンスを返す機能や、HTMLを動的に作る機能を提供します。

同様に、ここではPythonのHTTPサーバーのgunicorn==20.1.0を使います。
GunicornはPythonのアプリケーションをサーバーとして動かすためのツール。
Flask単体よりも安定して、同時に多くのリクエストを処理できるようになります。

App Engineにおける設定ファイルの場所

dispatch.yaml はプロジェクトルート

dispatch.yaml は、App Engine におけるサービス間のルーティング規則を定義するグローバルな設定ファイルです。
プロジェクト全体でどのリクエストをどのサービスに振り分けるかを決定するため、ルートディレクトリに配置され、一元管理されます。

redirect.py は redirect-service ディレクトリ

redirect.py は、リダイレクト専用の処理を実装しているため、メインサービスから分離して管理されます。
こうすればリダイレクト処理だけを担当する独立したサービス（redirect-service）として運用でき、メンテナンスやデプロイの際に柔軟性が向上します。

app.yaml は各サービスごとに設置

app.yamlについては既に書きましたが、改めて。
App Engine では、各サービスごとに個別の設定ファイル（app.yaml）が必要です。
プロジェクトのルートにある app.yaml はメインサービス用、redirect-service フォルダ内の app.yaml はリダイレクト専用サービス用となっており、それぞれのサービス固有の設定（ランタイムやスケーリングなど）を管理しています。

requirements.txt も各サービスごとに設置

各サービスは、それぞれ異なる依存関係を持つ可能性があります。
メインサービスとリダイレクトサービスで必要なライブラリが異なる場合、別々の requirements.txt を管理することで、各サービスごとに必要なパッケージのみをインストールでき、依存性管理が容易になります。

equirements.txt について特記するなら、各サービスは独立した環境としてデプロイされるため、同じ内容の requirements.txt をそれぞれのサービスのディレクトリに配置しても全く問題ありません。
App Engine はサービスごとに依存パッケージをインストールするので、メインサービスと redirect-service で同じライブラリ（Flask や gunicorn）を使っていても干渉しません。

もし、コードや設定が共通している部分が多い場合、プロジェクト全体で管理する方法を工夫することも可能ですが…
シンプルな構成の場合は、各サービスディレクトリに同じ requirements.txt を用意するのが手間も少なく、一般的なアプローチだと思います。

リダイレクト設定を行うapp.yaml

runtime: python312
service: redirect-service

instance_class: F1
env: standard

automatic_scaling:
  min_idle_instances: 0
  max_idle_instances: 2
  max_concurrent_requests: 200

handlers:
- url: /(.*)
  script: auto

entrypoint: gunicorn -b :$PORT redirect:app

app.yaml は、Google App Engine (GAE) にアプリケーションをデプロイする際に必要な設定ファイルです。
このファイルには、アプリケーションの基本的な動作方法（ランタイムの種類、スケール方法、リクエスト処理の仕組みなど）が記述されています。

1. このapp.yamlをもとにGoogle App Engineがアプリケーションを設定します。
2. 必要に応じてインスタンスをスケールアップ／ダウンしてリソースを管理します。
3. リクエストを受け取ると、Flaskアプリ（redirect.py）が動作して処理します。

ただし、この設定は駆け出しサイト用です。
ある程度の規模になってくるとこれではアクセスを捌ききれないので、注意してください。

1. ランタイムとサービス名の設定

runtime: python312
service: redirect-service

runtime: python312

アプリケーションを動かす環境を指定しています。
この場合、Pythonのバージョン3.12を使用します。

service: redirect-service

このアプリケーションのサービス名を指定しています。
「redirect-service」という名前のサービスとして動作します。

サービス名とは、同じプロジェクト内で複数の機能を分けるために使用される「名前」です。

2. インスタンスの設定

instance_class: F1
env: standard

instance_class: F1

インスタンス（サーバー）のスペックを指定します。F1は、低コストの小規模なインスタンスで、軽量なアプリケーションに適しています。

env: standard

環境（エンジンの種類）を「Standard Environment」に設定。これは短時間の実行や軽い負荷向けの環境です。

3. 自動スケーリングの設定

automatic_scaling:
min_idle_instances: 0
max_idle_instances: 2
max_concurrent_requests: 200

min_idle_instances: 0

必要がないときはインスタンス（サーバー）を0個にしてコストを削減。

max_idle_instances: 2

アイドル状態でも最大2個のインスタンスを維持して、迅速にリクエストに応答。

max_concurrent_requests: 200

1つのインスタンスで同時に処理できるリクエスト数を最大200に設定。

4. ハンドラー（リクエストのルール）

handlers:
- url: /(.*)
script: auto

url: /(.*)

すべてのリクエスト（例: /about, /contact など）を対象としています。

/(.*) は「すべてのURL」を意味する正規表現です。

script: auto

Pythonランタイム環境で自動的にリクエストを処理。

5. 実行エントリポイントの設定

entrypoint: gunicorn -b :$PORT redirect:app

entrypoint

アプリケーションを実行するコマンドを指定します。

gunicorn -b :$PORT redirect:app

gunicornを使ってアプリケーションを実行。

-b :$PORT: 環境変数からポート番号を取得して接続。

redirect:app: redirect.pyファイルの中にあるFlaskアプリケーション（app）を実行。

このファイルは、アプリの「設定表」や「設計図」のようなものですよね。
間違った設定をするとアプリが正常に動かないこともあるため、細かい部分まで慎重に作成する必要があります。

リダイレクト専用の動作を完全に分離する

リダイレクト設定を一つの app.yaml に書き足すだけで済むケースだってあります。
app.yaml は、App Engineサービス全体の設定ファイルであり、アプリケーションの動作環境、すなわちランタイムやエントリポイント、URLマッピングを定義します。
ここでリダイレクト設定を app.yaml の一部に統合しようとすると、メインアプリ（静的ウェブサイトやFlaskアプリ）の動作と混ざり合ってしまって、平たく言うとややこしいんですよ…

リダイレクト設定があると、/ やその他のルートへのリクエストをリダイレクト用のロジックが処理してしまい、メインのアプリケーションに到達できなくなる可能性があります。
https://feinatelier.org/top のアクセスがリダイレクト設定に奪われるとか。
こういうのを、URLパスの競合と言います。

そもそもリダイレクトは独自の振る舞いが求められるケースが多く、例えば301リダイレクトのHTTPステータスを正確に返す必要があります。
リダイレクトの独立性を損なうようなプロジェクト構成の設計は、望ましくないです。
一方、メインアプリではHTMLや動的コンテンツの提供が優先されるため、同じ app.yaml 内でロジックが混在すると管理が煩雑になります。

現在のように、redirect.pyをredirect-serviceディレクトリに独立させて別のサービスとしてデプロイするアプローチは、App Engineのマイクロサービス設計に適合しています。

App Engineでは、複数のサービスをdispatch.yamlでルーティングできます。
すると、次のように役割を完全に分離した設計が可能になるんです。

メインサービス

main.py 静的ウェブサイトや動的コンテンツを提供。

リダイレクトサービス

redirect.py すべてのリクエストを新しいURL feinatelier.org に301リダイレクト。

こうすることで、互いの振る舞いが影響を与えることなく、独立して動作させることができます。
リダイレクト設定を一つの app.yaml に書き足すだけで済むケースというのは、ルート数が少なく、振る舞いが単純な場合ですよね。
特定のページだけ別のURLへ飛ばすとか。
でも今回のようにプロジェクト構成へ丸ごと独自ドメインを適用するようなケースでは、あまり適切とは言えないでしょう。
現在のアプローチが優れている理由としては、次の3点が挙げられます。

1. リダイレクト処理を完全に独立させて管理できる。
2. URLの競合を避け、役割を明確に分離できる。
3. dispatch.yamlを使うことで柔軟なサービス間ルーティングが可能。

つまり、今後を見据えた柔軟性と保守性を重視して、この設計にしているわけです。

App Engineへリダイレクト設定をデプロイ

さて、ここまで書けたら、App Engineへのデプロイしましょう。

リダイレクト専用サービスのフォルダ redirect-service へ移動してデプロイしてください。

$ gcloud app deploy app.yaml

次はプロジェクトのルートへ移動してから、そこに配置した dispatch.yaml をデプロイします。

$ gcloud app deploy dispatch.yaml

メインサービスはこれまで通り、プロジェクトルートでgcloud app deployをするのみです。

gcloud app deploy コマンドの注意点

プロジェクトルートで普通にWebサイトを更新する時には、gcloud app deployコマンドに「app.yaml」をつけなくても良いのですよ？
プロジェクトルートにあるapp.yamlを暗黙的に使うため、明示的にファイル名を書く必要がないからです。

gcloud app deployコマンドは、現在のディレクトリにapp.yamlが存在する場合、自動的にそのファイルを認識して使用します。
つまり、プロジェクトのルートにapp.yamlが配置されている状態でgcloud app deployとだけ入力すれば、明示的にファイル名を指定しなくてもデプロイが実行されます。

一方で、リダイレクト専用サービスの場合は、フォルダredirect-service内のapp.yamlをデプロイするため、フォルダに移動するか明示的にファイルパスを指定する必要があります。
そのため、次のような手順となっているのです。

redirect-serviceディレクトリへ移動してデプロイ。

gcloud app deploy app.yaml

プロジェクトルートに移動してdispatch.yamlをデプロイ。

gcloud app deploy dispatch.yaml

メインサービス（ルートのapp.yaml）のデプロイでは、ファイル指定が不要。

gcloud app deploy

このサイトでは現在、app.yaml 内で静的ハンドラとして www/ 以下のコンテンツを配信していますが、デフォルト URL でのアクセスは本ディスパッチ設定によりリダイレクト対象になるため、静的ファイルも自動的に独自ドメインに誘導されるのですよ。

以上が、このサイトに合わせた「App Engine のサービス／ディスパッチ設定でリダイレクトする方法」のソースコード解説になります。
これで https://fein-sites-dev1.ew.r.appspot.com/ へアクセスしたユーザーは自動的に https://feinatelier.org/ へリダイレクトされるってことですね。

リダイレクトのテストと検証

Twitterなどでフォロワーさんに「古いURLでアクセスしてみて!」などと、負荷をかけるようなことをしてはいけません。
デプロイ後は、ログなどでリダイレクトが正しく実施されているかを自分で確認しましょう。

$ gcloud app services list

SERVICE NUM_VERSIONS
default 167
redirect-service 1

default

メインのサービスです。
ここでは 167 個のバージョンが存在しており、これまでのデプロイ履歴（過去のバージョンも残っている状態）が反映されています。

redirect-service

リダイレクト専用サービスです。
ここには 1 個のバージョンが存在しているので、最新（そして唯一）のバージョンがデプロイされていることが分かります。

これが私の検証だとするなら、redirect-service は正常にデプロイされていて、ルーティング設定（dispatch.yaml）によって https://fein-sites-dev1.ew.r.appspot.com/ へのアクセスがこのサービスに振り分けられているのです。
設定は正しく反映されていると考えて良いでしょう。

仮に、ここで「Service Unavailable」などのエラーがブラウザに表示される場合は、リダイレクトサービスのログを確認して、エラーが発生していないかチェックする必要があります。
例えば、以下のコマンドでリアルタイムのログを確認できます。

$ gcloud app logs tail -s redirect-service

redirect-service のエラー内容や動作状況を詳しく把握して、調べてみましょう。
また、次のようにコマンドラインでも、リダイレクトが正しく機能しているか検証できます。

cURL でヘッダーを確認する

cURL（カール）は、データをURL経由でやり取りするためのコマンドラインツールです。
主にWeb開発やネットワーク管理で使用され、HTTPやHTTPSなどのプロトコルを通じてリクエストを送信し、その応答を確認することができます。
たとえば、「ヘッダーを確認する」という場合、cURLを使うと簡単にHTTPリクエストやレスポンスのヘッダー情報を取得できます。
ここで、あるURL https://example.com のヘッダー情報を取得してみましょう。

$ curl -I https://example.com

このコマンドの結果として、レスポンスのヘッダー情報（例：HTTPステータス、サーバー情報、コンテンツタイプなど）が表示されます。
これを独自ドメインのリダイレクト設定チェックに使うなら、次のようにターミナルやコマンドプロンプトから以下のコマンドを実行します。

$ curl -I https://fein-sites-dev1.ew.r.appspot.com/

HTTP/1.1 301 Moved Permanently
Location: https://feinatelier.org/

HTTP レスポンスのヘッダー情報だけが表示されます。─ 実際にはもっといろいろ出ますよ？ ─
このように、Location ヘッダーにリダイレクト先の URL が記載されていること、また 301 ステータスが返っていることを確認してください。
この方法でリダイレクトが正しく設定され、https://fein-sites-dev1.ew.r.appspot.com/ から https://feinatelier.org/ に転送されていることを確かめることができます。