リモートデータベースプロキシ（TCP/TLS）：クラウドワーカーとローカルホストを安全に接続

現代のクラウド開発は、エンジニアリングライフサイクル中にコードが動作する場所とデータが存在する場所の分断を根本的に変えています。サーバーレス関数を構築し、VercelやCloudflareのエッジワーカーに展開し、AWS Lambdaを無限にスケールするプロビジョニングを行います。しかし、これらのデプロイを支える基盤データ — 新たにシードされた関係データベースや高速キャッシュメモリストア — は、多くの場合あなたのローカルマシンにあります。

標準的な開発者のプレイブックは、通常、ローカルデータベースの前にモックHTTP APIを置き、リモートワーカーがデータを取得できるようにします。しかし、時にはAPIを使いたくない場合もあります。複雑なPrismaマイグレーションのテストや、深くネストされたSQL JOIN 文のデバッグ、またはキャッシュに接続されたクラウドワーカーの生のスループット評価など、APIの抽象化はむしろ邪魔になることもあります。あなたのクラウドインフラは、直接あなたのローカルデータベースと通信する必要があります。

インターネットトラフィックに対してローカルPostgreSQLを安全かつ一時的に公開する方法が必要です。ネットワーク変換層をバイパスし、あなたのローカルマシンの完全性を損なわずにTCPトンネルを使ったlocalhostデータベースソリューションが求められています。

当社の高度な開発者ネットワーキングに関する深掘りの第8部では、Layer 4トンネリングの仕組みを解説します。LocalXposeを使ってクラウドワーカーとローカルデータストアの間のギャップを埋める方法を詳しく説明し、安全なRedisリモートアクセスやPostgreSQLのTCPトンネルとTLSトンネルを通じた接続方法を紹介します — そして、選択したトンネルタイプによってデータベース側の設定がどう変わるかも解説します。

ネットワーキングのジレンマ：Layer 7トンネルがデータベースに失敗する理由

データベースを公開するための標準的なWebhookテストトンネルを試したことがあれば、すぐに接続エラーが出るのを見たことがあるでしょう。その理由を理解するには、OSIネットワークモデルの簡単な解説が必要です。

ほとんどの開発者向けトンネリングツールはLayer 7（アプリケーション層）で動作します。HTTPやHTTPSトラフィック用に設計されています。リクエストが公開エッジサーバに到達すると、プロキシエンジンはHTTPリクエストライン（例：GET /api/users HTTP/1.1）と標準ヘッダーを期待します。

しかし、データベースはHTTPを話しません。

PostgreSQLはPostgresのワイヤープロトコルというカスタムバイナリプロトコルを使います。RedisはRESP（REdis Serialization Protocol）を使用します。どちらも基本的にLayer 4（トランスポート層）のトラフィックです。これらのバイナリストリームをHTTPトンネルに流すと、プロキシはそれをHTTPテキストとして解析しようとし、正しいヘッダーが見つからずに接続を切断します。

これを回避するために、従来の開発者は次の二つの選択肢に頼ってきましたが、どちらも問題の解決にはなりません：

• ポートフォワーディング — 住宅用ルーターの管理パネルにアクセスしてポート5432をインターネットに公開する。セキュリティリスクが高く、Carrier-Grade NAT（CGNAT）を使うISPによってブロックされることもあります。
• VPNゲートウェイ — WireGuardやOpenVPNを設定し、クラウドワーカーとローカルマシンが仮想サブネットを共有する。動作はしますが、テストセッションのために数時間の設定が必要です。

現代的な解決策は、専用のTCPトンネルlocalhostデータベースプロキシです。HTTP解析を完全にスキップし、公開インターネットからの生のTCPバイトストリームを無条件にローカルホストのポートに転送します。

ツールチェーン：なぜLocalXposeなのか？

市場にはHTTP専用のWebhookプロキシが溢れていますが、信頼できるTCPおよびUDPトンネリングサービスは限られています。LocalXposeはこれに特化したリバースプロキシです。HTTP、HTTPS、TCP、TLS、UDPトンネルをネイティブにサポートし、このワークフローに必要なプロトコル範囲をカバーします。

機能	HTTPトンネル（Layer 7）	TCPトンネル（Layer 4）	TLSトンネル（Layer 4 + セキュリティ）
解析	ヘッダーとペイロードを検査	なし、バイナリストリームそのまま	暗号化されたバイトストリーム、検査なし
対象用途	Webhook、Next.jsプレビュー	PostgreSQL、MySQL、SSH	Redis with TLS、運用データ同期、TLS対応全般
TLS終端	LocalXposeのエッジサーバが復号、その後HTTPを渡す	該当なし — トラフィックはエンドツーエンドで暗号化されません（アプリ側が暗号化している場合を除く）	LocalXposeのエッジでは行わず、アプリ側が終端またはクライアントに証明書/キーを渡してローカルで終端
LocalXposeサポート	loclx tunnel http	loclx tunnel tcp	loclx tunnel tls

このTLS終端の行は一時停止して確認すべきです。多くのガイド（このドキュメントの以前の草稿も含む）は逆に解釈しており、TLSトンネルはエッジで終端できると誤解しています。LocalXposeの公式ドキュメントは明確に述べており、TLSトンネルは決してエッジで終端しません — ストリームはそのままアプリに渡すか、--crt/--keyを指定してクライアント側で終端します。この理解をもとに、以下のWorkflow 2と比較表を修正しています。

ワークフロー1：ローカルのPostgreSQLをインターネットに公開

Vercelのプレビュー展開にあるNext.jsアプリがあり、Prismaを使っていて、Docker上のPostgreSQLと通信したい場合。

1. LocalXposeをインストールして認証する。

LocalXposeはクロスプラットフォームのバイナリとnpmラッパーとして提供されています。

npm install -g loclx
loclx account login

（Homebrew、Snap、Chocolateyのビルドもあります。npmを使いたくない場合はそちらを利用してください。）

2. ローカルのPostgreSQLが動作していることを確認。

psql -h localhost -p 5432 -U postgres -d my_local_db

3. TCPトンネルを開始。

loclx tunnel tcp --to localhost:5432

これにより、動的に生成された公開エンドポイント（例：us.loclx.io:49152）が表示されます。これがあなたのローカルポート5432への直接パイプです。ただし、注意点としてこのアドレスはランダムであり、トンネルを再起動するたびに変わります。これをVercelの環境変数に設定する場合、ポートが変わると困るため、安定したエンドポイントを予約します：

loclx endpoint reserve
loclx tunnel tcp --reserved-endpoint us.loclx.io:4455

4. リモートワーカーに設定。

# フォーマット： postgresql://[ユーザ名]:[パスワード]@[トンネルホスト]:[トンネルポート]/[データベース名]
DATABASE_URL="postgresql://postgres:mysecretpassword@us.loclx.io:4455/my_local_db"

5. 通常通りマイグレーションやクエリを実行。

クラウド関数はus.loclx.io:4455に接続し、LocalXposeが直接Dockerコンテナにフォワードします。

TCPトンネルはペイロードを検査しないため、PostgresのSSLネゴシエーション（sslmode=require、verify-full、クライアント証明書など）はそのまま通過します。Postgresに特にTLSトンネルタイプを使う必要はなく、必要に応じてストリームの暗号化は設定次第です。

ワークフロー2：LocalXpose TLSトンネルを使ったRedisの安全なアクセス

RedisはPostgresとは異なる問題を抱えています。信頼されたプライベートネットワーク内で動作するよう設計されており、多くのローカルインストール（Homebrewやaptのデフォルトビルドを含む）にはTLSが組み込まれていません。プレーンテキストでRedisを公開すると、キャッシュ内容やセッショントークン、アプリの状態が誰でも読めてしまいます。

ここでTLSトンネルが重要になります。ただし、ここでの訂正：loclx tunnel tlsコマンドは、それ自体で暗号化を追加しません。 LocalXposeのTLSトンネルタイプは、エッジサーバ間のバイトストリームを暗号化しますが、そのエッジサーバはHTTPトンネルのようにストリームを復号しません。終端はあなたの側で行います。方法は二つ：

• ローカルサービスがすでにTLSをサポートしている場合。 loclx tunnel tlsをそれに向けると、暗号化されたバイトはそのままアプリに渡されます。
• ローカルサービスがTLSをサポートしていない場合（例：Plain FTP）、--crt/--keyオプションを使ってLocalXposeクライアントに証明書とキーを渡し、クライアント側で復号して平文をアプリに渡します。

RedisがTLSサポートを有効にしている場合のみ、最初のケースに該当します。Redisはバージョン6.0以降ネイティブTLSをサポートしていますが、redis.confのtls-portを設定し、明示的にビルドする必要があります（例：make BUILD_TLS=yes）。requirepassだけでは認証はできても暗号化はされません。TLSトンネルを6379ポートに使う場合は、TLSサポートが有効になっていることを確認してください。

1. ローカルRedisでTLSを有効化。

# redis.conf
tls-port 6379
port 0
tls-cert-file /path/to/redis.crt
tls-key-file /path/to/redis.key
tls-ca-cert-file /path/to/ca.crt
requirepass MyUltraSecurePassword

ACLユーザもACL SETUSERコマンドで設定可能です。複数サービスがトンネルを通じて接続する場合は推奨されます。

2. リッスン状態を確認。

redis-cli --tls --cert redis.crt --key redis.key --cacert ca.crt -h localhost -p 6379 ping

3. TLSトンネルを開始。

loclx tunnel tls --to localhost:6379

これにより、安全なエンドポイント（例：eu.loclx.io:51020）が得られます。必要に応じてドメインを予約してください。

4. リモートクライアントの設定にrediss://を使用。

# 'rediss://'プレフィックスはTLS接続を強制
REDIS_URL="rediss://default:MyUltraSecurePassword@eu.loclx.io:51020"

トンネルはパススルーのため、LambdaのRedisクライアントが行うTLSハンドシェイクは、直接あなたのローカルRedisサーバと交渉します。LocalXposeは暗号化されたバイトを運ぶだけで、暗号化の当事者ではありません。

セキュリティ強化：IPホワイトリスト設定

上記の両ワークフローは、デフォルトではインターネットのどこからでもアクセス可能です。これは目的でもありますが、リスクも伴います。LocalXposeは設定ファイルのプラグインとしてIPホワイトリストをサポートしており、HTTPだけでなくTCPやTLSトンネルにも適用されます：

# config.yaml
db-tunnel:
  type: tcp
  region: us
  to: localhost:5432
  plugins:
    ip_whitelist:
      - 203.0.113.0/24   # 例：クラウドプロバイダーのNATゲートウェイの範囲

loclx tunnel config -f /path/to/config.yaml

LambdaやVercelの関数に静的な出入口IP（例：AWS NAT Gateway）がある場合、そのCIDRに制限することで、「ポートを推測するだけ」のリスクをほぼ完全に排除できます。

なお、TCPおよびTLSトンネルは、Freeプランでは利用できません。無料/スタータープランはHTTP(S)のみ対応です。TCP、TLS、UDPトンネルや予約エンドポイント、カスタムドメインは有料のProプラン（$8/月、年払い$96、10トンネル、帯域無制限）に限定されます。これを理解した上で、無料アカウントでは動作しないコマンドに依存したワークフローを構築しないよう注意してください。

最小権限の原則：セキュリティの義務

ファイアウォールに穴を開けてローカルデータベースに直接アクセスできるのは強力な機能ですが、同時に危険も伴います。ルーターのNAT保護をバイパスすることは、セキュリティ上のリスクを伴います：

• 未認証のデータストアを公開しない。 PostgreSQL、MySQL、Redisには、トンネルを張る前に強力なパスワード（またはRedisのACLユーザ）を設定してください。postgres:postgresやadmin:adminのデフォルトは絶対に避けてください。
• トンネルは一時的なものとみなす。 一時的な統合テストのために使用し、セッション終了時にLocalXposeデーモンを停止してください。長期間放置しないこと。
• データをマスクする。 この方法で公開されるローカルデータベースは、合成データや匿名化されたデータのみを保持してください。本番のダンプをPII付きのデータで復元し、それをトンネル経由で外に出すことは避けてください。侵害されたトンネルは、あなたのローカルマシンを情報漏洩の源にします。
• IPホワイトリストを利用。 呼び出し元のインフラに安定した出出口範囲がある場合に限ります（上記参照）。

遅延問題の克服：コネクションプーリング

最後に、物理的な制約についても理解しておく必要があります。us-east-1のLambdaが同じリージョンのRDSにクエリを送る場合、遅延はサブミリ秒です。しかし、TCPトンネルを経由してあなたのラップトップにクエリを送ると、AWSのデータセンターからLocalXposeのエッジ、インターネット、ISP、Wi-Fi、Docker、そしてあなたのアプリまで、多くの経路を通るため、遅延は増大します。1回のクエリに100msかかることもあります。ORMが複数のリレーションを解決するために複数のラウンドトリップを行うと、50msの遅延が数秒に膨らむこともあります。

修正すべきポイントは、Lambdaの*デフォルト*タイムアウトが3秒であり、最大900秒（15分）に設定可能なことです。ただし、API Gateway（RESTまたはHTTP API）を経由する場合、*ゲートウェイ*が29秒の制限を設けており、Lambdaのタイムアウト設定に関係なく制限されます。vercel.jsonやserverless.ymlのタイムアウトを60秒にしても、API Gatewayの制限により切断される可能性があります。Function URLsや非同期呼び出し（EventBridge、SQS）はこの制限の対象外で、最大900秒まで使用可能です。

テスト時のラウンドトリップコストを抑えるために:

• 適切な層でタイムアウトを延長。 Lambdaの設定やAPI Gatewayの統合タイムアウトを調整します。
• コネクションをローカルでプール。 サーバーレス関数は頻繁にコネクションを開閉し、高遅延のトンネルではコストが高くなります。PostgreSQLの前にPgBouncerを配置し、トンネルの先をPgBouncerにします。
• クエリをバッチ化。 IN句を使った一括処理を優先し、ラウンドトリップの回数を削減します。

自動化：Docker、Node.jsクライアント、CI/CD

インタラクティブなCLI以外に、LocalXposeは以下のツールを提供し、loclx tunnel ...コマンドを毎回手動で入力する必要をなくします：

• 公式Node.jsクライアント（node-localxposeまたはlocalxposeとしてnpmに公開）PromiseベースAPIを持ち、client.tcp({ to: '127.0.0.1:5432', reservedEndpoint: '...' })やclient.tls({ crt: '/path/to/cert.pem', key: '/path/to/key.pem' })で、テストランナーやシードスクリプトにトンネルのライフサイクルを直接組み込めます。
• 公式Dockerイメージ（localxpose/localxpose）は、サイドカーコンテナとしてトンネルを動かすのに便利です。Let’s Encrypt証明書を使ったTLSトンネルを生成する場合は、/home/nonroot/.localxposeにボリュームをマウントしてください。さもないと、Let’s Encryptの証明書制限（ドメインあたり週5証明書）に引っかかります。
• GitHubアクション（LocalXpose/localxpose-action@v1）は、ワークフロー内でトンネルを立ち上げるのに便利です。実際のPostgresインスタンスにアクセスできる状態で、インフラを立てずにテストできます。

これらはすべて、上記のTCP/TLSの仕組みを変えるものではなく、コマンドを自動化・スクリプト化するための補助ツールです。

究極のインテグレーションショートカット

リモートデータベースプロキシは、現代のバックエンド開発の柔軟性を示す証です。Layer 4ルーティングを活用することで、サーバーレスクラウドインフラとローカル開発環境の物理的距離を一時的に縮めることが可能です。

マイクロサービスのデバッグ、Webhookデータ変換のテスト、または一度きりのキャッシュテストのためにAPIモックを書きたくない場合でも、TCPトンネルを使ったlocalhostデータベースパターンは非常に有用です。どのトンネルタイプが何をするのか、どれが有料プランを必要とするのか、どれが事前にTLSを話す必要があるのかを理解しておけば、ツールボックスに入れておく価値があります。

---

チェンジログ

LocalXposeの公式ドキュメント、GitHubリポジトリ、npmリスト、Redisの公式ドキュメント、AWS Lambdaのドキュメント（2026年9月9日時点）を参照し、事実確認済みです。

• 最大の修正点（TLSトンネルの仕組み）： 草稿ではLocalXposeは「エッジでTLS接続を終端できる」または「そのまま通す」と誤解させる記述がありましたが、実際はTLSトンネルはエッジで終端しません。ストリームはそのままアプリに渡すか、--crt/--keyを使ってクライアント側で終端します。この理解に基づき、Workflow 2と比較表を修正しています。
• Redis TLSの前提条件： 元のワークフローはloclx tunnel tls --to localhost:6379の前にrequirepassを設定するだけでしたが、RedisのTLSサポートはバージョン6.0以降でtls-portを設定し、ビルド時にmake BUILD_TLS=yesを行う必要があります。redis.confのTLS設定例と、redis-cliのTLS接続確認コマンドを追加しました。ACLユーザも推奨されます。
• AWS Lambdaのタイムアウト事実の修正： 草稿の「標準設定は10秒」はAWSの公式情報ではなく、実際のデフォルトは3秒です。最大900秒まで設定可能です。API Gateway経由の場合は29秒の制限があり、これを超えると自動的に切断されることも追記しました。Function URLsや非同期呼び出しはこの制限の対象外です。
• 無料プランの制限について： TCP/TLS/UDPトンネルや予約エンドポイント、カスタムドメインはProプランのみの機能です。無料/スタータープランはHTTP(S)のみ対応です。これに関する注意喚起を追加しました。
• 予約エンドポイントの追加： 出力例のus.loclx.io:49152はランダムに割り当てられるため、固定化するにはloclx endpoint reserveと--reserved-endpointを使う必要があります。
• IPホワイトリストの具体例： どのように設定するかを具体的なconfig.yaml例とともに示し、HTTPだけでなくTCP/TLSにも適用されることを明記しました。
• Postgres/TLSトンネルの補足： TCPトンネルはペイロードに依存しないため、Postgresのsslmode設定はそのまま通過します。TLSトンネルは必要に応じて使うものであり、必須ではありません。
• Docker、Node.jsクライアント、CI/CDの追加： 公式のNode.jsクライアント、Dockerイメージ、GitHubアクションについて言及し、証明書の制限についても触れています。
• 正確性の確認と不要な記述の削除： コマンド例やURLスキーム、Layer 4とLayer 7のフレーミングについてはそのまま維持し、不要な前書きやメタデータは削除しました。