投稿者: noisefree-life

  • 【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によるリバースプロキシの仕組み
    インターネット HTTPS (443) AWS サーバー (EC2) Nginx 内部転送 (port:5678) n8n

    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の罠
    n8n (自社サーバー) Google (GCP) ① 認証リクエスト ② Mismatch エラー! n8nの認識: http://localhost:5678/… GCPの登録: https://独自ドメイン/… → 帰還先(Redirect URI)が一致しないためGoogleがブロック!

    罠③: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 downup -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に毎月課金することなく、フル機能の自動化を完全無料で回し続けることができます。初期のインフラ構築の壁さえ越えれば、あとは圧倒的な自由と効率が待っています!

  • Hello world!

    WordPress へようこそ。こちらは最初の投稿です。編集または削除し、コンテンツ作成を始めてください。