Next.js×Amplifyにおけるroute handlerのrequest.urlの注意点

はじめに

先月から社内向けのシステム開発を丸っと担当しておりまして、フロント(Next.js)/バック(Rails)/インフラ(AWSをterraform管理)を全部やり遂げたんですが、最後デプロイで罠にハマりました。
久々にAI使ってるのに沼って頭が活性化されました！まとまった情報もなかったのでアウトプットしておきます！

最低限必要な画面✖️APIができて、認証基盤ができて、いざAmplifyにデプロイ！！！！
staging環境でログインできるかなぁと試したところ、見事できませんでした！

前提

技術スタック

• Next.js（App Router）

• Amplify + CloudFront

• Cognito 認証(providerはgoogle)

• Ruby on Rails

処理の流れ

ログインボタンクリック（Next.js）

→ Cognito Hosted UI（カスタムドメイン / 外部）

→ Google 認証画面（外部）

→ 認証後 callback API（Next.js route handler）

→ token 交換などの認証処理（Rails）

→ cookie にトークン設定（Next.js route handler）

→ ログイン後画面へリダイレクト（Next.js route handler）

起きたこと

最後のログイン後の画面がhttps//localhost:3000になる

問題の切り分け

ローカルでは何も問題なかったのでstaging環境で起こります(本番は未検証ですがきっと再現する)、
cloud watchを見ましたが、Rails API側はstatus code 200でエラー出てなくてイマイチわからずでした。

どこまで上手く行ってるのか確認していくと、cookieは意図したドメインで保存されていて。認証処理は上手くいってることがわかりました。

最後のリダイレクト処理のみうまくいってませんでした。

つまり、route handler内の処理で何か意図しないことが起きているのは明らかでした。

その時の問題のコード

return NextResponse.redirect(new URL("/dashboard", request.url));

問題点

結論、request.urlが意図した値(publicなfrontendのhost)になっていませんでした。

Amplify + Next.js（App Router）構成では、リクエストはCloudFront → Amplify の内部プロキシを経由します。そのため、route.ts 内で参照できる request.url は実際のパブリック URLではなく、内部の localhost URL になります。

ちなみにVercelでは NEXT_PUBLIC_VERCEL_URL が自動設定されますが、Amplifyでは明示的にフロントエンドのURLを環境変数で指定する必要があります。

今回は、リダイレクト先の base URL をNEXT_PUBLIC_FRONTEND_URL として固定することで解決しました。

うまく行ったコード

const baseUrl = process.env.NEXT_PUBLIC_FRONTEND_URL!;
return NextResponse.redirect(new URL("/dashboard", baseUrl));

おわりに

罠すぎました。
ローカルでは起きないことがstaging環境で起こるとデバッグもややこしくなるし難易度が一段とあがっちゃいます！だいぶ頭抱えました。

今まで個人開発でVercalでしかデプロイしたことなかったので初めてのAmplify(✖️Next.js特有と思いますが)で沼りましたが、やっぱり理解度の向上にはつながるのでたまにはハマるのもありだなって思いました！！！

他にも沼りながらも(SSRとcookieのパス等、、)なんとかリリースできそうです、、！
今回レビューはCTOにしてもらいながら全部1人でやったのでめちゃ力ついた気がします！
開発できるの幸せで楽しい〜〜〜🍓