【Zapier難民必見】AWS上のn8nを完全HTTPS化し、Gmail(OAuth2)連携するまでの全手順と罠

「Zapierの課金が辛い…」「n8nを自前構築(セルフホスト)したいけど、インフラ構築で挫折した」

そんな悩みを抱える非エンジニア向けに、AWS（RHEL 8）上で構築したn8nを完全HTTPS化（独自ドメイン＋SSL）し、最難関であるGoogle API（GmailのOAuth2認証）を突破するまでの全手順をまとめました。

実際に私が構築中に直面した「4つの罠（エラー）」とその解決策を図解入りで解説します。

フェーズ1：HTTPS化への道（Nginx + Let’s Encrypt）

n8nを外部サービス（Googleやkintoneなど）と安全に連携させるには、URLに「鍵マーク」をつけるHTTPS化が必須です。ここではWebサーバー「Nginx」を門番（リバースプロキシ）として立たせます。

図解：Nginxによるリバースプロキシの仕組み

Nginxが外部からの通信を安全に受け止め、内部で動いているn8nへ橋渡しをします。これによりn8n自体を直接インターネットに晒す危険を回避できます。

罠①：RHEL 8には標準でEPELがない

NginxやCertbot（無料SSL化ツール）を入れる際、Ubuntuなら一発ですが、RHEL 8などの堅牢なサーバーではepel-releaseが標準で見つからずエラーになります。

エラー: Unable to find a match: epel-release

【解決策】
FedoraプロジェクトのURLから直接RPMパッケージを指定してインストールします。

sudo dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm

罠②：Let’s Encrypt発行時の「Timeout」とAWSの壁

sudo certbot --nginx を実行した際、タイムアウトエラーが発生することがあります。

エラー: Timeout during connect (likely firewall problem)

【解決策】
セキュリティを意識してAWSのインバウンドルールを「My IP（自分の家）」だけに絞っていませんか？
Let’s Encryptは「本当にあなたがドメインの所有者か？」を確認するため、アメリカ等のサーバーからあなたの80番ポート（HTTP）へ通信チェックに来ます。一時的に80番と443番ポートのソースを 0.0.0.0/0 に解放してください。

フェーズ2：Google OAuth2認証の壁（Gmail連携）

HTTPS化が完了したら、いよいよGoogle（Gmail）との連携です。GCP（Google Cloud Platform）でアプリを登録し、Client IDとSecretを発行します。

図解：OAuth2におけるRedirect URIの罠

罠③：redirect_uri_mismatch（URLの不一致）

n8nの画面で「Sign in with Google」を押すと、Googleの画面でエラーが出ます。

【ここに 400 redirect_uri_mismatch のエラー画像を挿入】

【解決策】
n8n自身が「自分のURLは localhost だ」と勘違いしているのが原因です。Docker環境の場合、.envファイルまたはdocker-compose.ymlに以下を追記して、コンテナに環境変数を注入します。

environment:
  - WEBHOOK_URL=https://あなたのドメイン/

その後、docker compose down と up -d で再起動すると、n8nの画面上のURL表示が正しい独自ドメインに切り替わります。

罠④：Nginxの 414 URI Too Long エラー

URLは合ったのに、今度は n8n 上に赤いエラー通知が出ます。

【ここに status code 414 のエラー画像を挿入】

【解決策】
Googleが送り返してくる長大な認証情報（トークン等）のURLを、門番であるNginxが「長すぎて受け取れない！」と弾いています。Nginxの設定ファイル（n8n.conf）のserverブロック内に、受け皿（バッファ）を広げる設定を1行追加します。

server {
    server_name あなたのドメイン;
    
    # この1行を追加してバッファを拡張
    large_client_header_buffers 4 32k;
    
    location / { ... }
}

罠⑤：403 access_denied（テストユーザー未登録）

ついにGoogleの画面にたどり着いたと思ったら、アクセス権限がないと弾かれます。

【ここに 403 access_denied 審査プロセス未完了のエラー画像を挿入】

【解決策】
GCPで作成したアプリは「テストモード」のため、事前に名簿に登録したアドレスしか認証できません。GCPコンソールの「OAuth同意画面（または対象メニュー）」から、テストユーザーとして自分のGmailアドレスを登録してください。

ついに開通！

これらすべての壁を越え、Googleからの警告画面（詳細→安全ではないページへ移動）を抜けて権限をすべて許可すると……

【ここに Connection successful の緑のチェック画像を挿入】

Connection successful!
これであなただけの最強の自動化要塞が完成しました。

ZapierやMakeに毎月課金することなく、フル機能の自動化を完全無料で回し続けることができます。初期のインフラ構築の壁さえ越えれば、あとは圧倒的な自由と効率が待っています！