55 lines
3.2 KiB
Markdown
55 lines
3.2 KiB
Markdown
# Synology Proxy 過去の失敗原因と対策 (Recap)
|
||
|
||
ユーザー様より「なぜSynology経由だとうまくいかなかったのか？」というご質問を頂きました。
|
||
過去のエラーログと構成状況に基づく分析結果は以下の通りです。
|
||
|
||
## 1. 最大の原因:「自宅の壁 (Network Accessibility)」
|
||
|
||
以前の構成では、アプリの設定が以下のような **ローカルIPアドレス** になっていました。
|
||
|
||
```dart
|
||
// 以前の設定 (イメージ)
|
||
static const String proxyUrl = 'http://192.168.31.89:8080';
|
||
```
|
||
|
||
* **何が起きたか**:
|
||
* 自宅のWi-Fiに繋いでいる時: **OK** 🟢 (繋がる)
|
||
* 会社のWi-Fi / 電車の4G回線: **NG** ❌ (繋がらない)
|
||
* **症状**:
|
||
* 外出先でアプリを開くと「タイムアウト」や「接続拒否」エラーが発生。
|
||
* これを回避するためにポート開放やVPNなどを検討しましたが、設定が複雑で不安定になりがちでした。
|
||
|
||
## 2. 第2のハードル:「セキュリティ制限 (HTTP vs HTTPS)」
|
||
|
||
AndroidやiOSの最新OSは、**暗号化されていない通信 (HTTP)** をデフォルトでブロックします。
|
||
|
||
* **問題点**: 自宅サーバーに正式なSSL証明書 (`https://`) を設定するのは、ドメイン取得や証明書更新などの手間が非常に大きいです。
|
||
* **結果**: アプリ側で `android:usesCleartextTraffic="true"` といったセキュリティ緩和設定を入れる必要があり、リリース審査的にも好ましくない状態でした。
|
||
|
||
## 3. 第3の壁:「往復のレイテンシ (Double Hop)」
|
||
|
||
```text
|
||
[スマホ] --(画像)--> [Synology] --(画像)--> [Google Gemini]
|
||
```
|
||
|
||
* **ボトルネック**:
|
||
* 自宅のインターネット回線（特に**上り/アップロード速度**）が遅い場合、スマホから画像を受け取ってGoogleに投げるまでの時間が倍増します。
|
||
* 画像サイズが大きいと、ここで10秒〜20秒の待ち時間が発生し、アプリが「応答なし」と判断して切断してしまうケースがありました。
|
||
|
||
---
|
||
|
||
## ✅ 今回の解決策: Cloudflare Tunnel
|
||
|
||
今回提案している「Phase 2: Container Manager + Cloudflare Tunnel」構成では、これらが全て解決します。
|
||
|
||
1. **脱・ローカルIP**: `cloudflared` コンテナが自動でトンネルを掘り、`https://ai-proxy.example.com` のような**固定の公開URL**を発行してくれます。
|
||
* → **会社からも電車からも繋がります。**
|
||
2. **自動HTTPS化**: Cloudflareが勝手にSSL証明書を貼ってくれるので、アプリからは完全に安全な `https` 通信として見えます。
|
||
* → **セキュリティエラーが出なくなります。**
|
||
3. **速度対策**:
|
||
* これでも「自宅回線の上り速度」依存は残りますが、アプリ側の実装で「画像の圧縮(Resize)」を適切に行うことで回避可能です（実装済み）。
|
||
|
||
### 結論
|
||
前回の失敗は「技術的な不可能」ではなく、**「ネットワーク経路(アクセス権)の問題」** でした。
|
||
Cloudflare Tunnel を導入することで、この経路問題はきれいに解消されます。
|