Solana dapp 何時該換 RPC

這篇在講 Solana dapp 何時該從免費 RPC 換成專用 RPC，還附可直接抄的切換模板。

我看過太多 Solana 小專案死在同一個地方：前面 demo 很順，免費 RPC 一接就跑，交易也能送，大家都以為自己很會。結果一有真使用者進來，延遲、timeout、confirmation 卡住，整個體驗像在踩爛泥。我最煩的不是程式碼壞掉，是你明明以為自己在做產品，實際上只是把流量丟進一個本來就不想扛你的免費端點。這次讓我把這件事講清楚的，是 Insider Monkey 的這篇 From Hobby Project to Production: How One Developer Scaled Their Dapp on Solana。它不是技術白皮書，但它把那個尷尬時刻講得很準：專案從玩具變成產品，第一個要補的常常不是功能，是基礎設施。

這篇原文沒有提供 star、bookmark 或閱讀數，我就不亂掰。它真正有價值的地方，是把「免費 RPC 夠用」和「免費 RPC 會開始騙你」這條線畫出來。這種故事我很吃，因為我自己也踩過。你以為你在省錢，其實是在把故障時間往後延，等到用戶最多、最難看的時候一起爆。

免費 RPC 不是架構，是試用期

“For a hobby project making a few test transactions per day, it was perfect. No cost, no complexity, no friction.”

翻譯一下就是：免費 RPC 對學習、測試、玩票很舒服，但它不是拿來當產品骨架的。一天幾筆 test transaction，不叫負載，那只是熱身。你在 tutorial 階段覺得一切都很順，很多時候不是因為架構好，是因為根本沒人用。

我之前接一個 bot，前期也是這樣。免費、方便、免設定，看起來超省事。可是一旦有幾個人同時送交易，問題就開始冒出來。不是你的 code 突然變爛，是你把 app 建在共享資源上，然後還期待它像專屬服務一樣穩。這種期待本身就很不合理。

實操上，我會把免費 RPC 的定位寫死：只給 local dev、內部測試、demo。只要你開始在意 confirmation time、吞吐量、或某個 action 不能失敗，免費 tier 就不該再被算進正式架構。它可以是起點，但不要騙自己它是終點。

• 免費 RPC 只拿來開發和內測。
• 從第一天就記 request volume，不要等出事才看。
• 先寫下「什麼情況算用戶看得到失敗」，再決定何時升級。

上線那一刻，端點會直接講真話

“Within the first hour, transactions started timing out.”

這句很刺耳，因為它通常是真的。實驗室裡看起來沒事，不代表上線後沒事。你在 staging 跑單人流程，RPC 看起來像沒脾氣；一旦真使用者同時進來，排隊、限流、延遲一起出現，app 就開始像壞掉。其實壞的常常不是 app，是你後面那條路。

我最常看到的錯誤，是團隊先懷疑自己的商業邏輯、wallet flow、簽章流程、序列化，什麼都查一輪，最後才承認 upstream 有問題。這很人性，我也幹過。因為我們總想先怪自己，覺得外部服務應該沒那麼脆弱。結果現實就是，shared endpoint 在高峰時段就是會抖。

實操寫法很簡單：不要只測 sequential request，要測 concurrent request。你要看 timeout rate、dropped submission、confirmation lag。尤其是交易、swap、bot 這類時間敏感功能，先做 burst test，再放真人上去。你要的是在 staging 把爛事逼出來，不是等到第一批用戶幫你找。

• 上線前先做並發測試，不要只跑單筆成功案例。
• 把 timeout rate 當成一級指標，不是附帶資訊。
• Debug 時把 RPC 症狀和 app bug 分開記錄。

專用 RPC 很無聊，但無聊就是你要的

“The setup took 20 minutes. She updated her endpoint URL, redeployed her bot, and invited her users back.”

這段我很喜歡，因為它完全不浪漫。沒有什麼神奇遷移、沒有大改 codebase，就是換 endpoint、redeploy、回來繼續做事。這才是對的。基礎設施的升級如果搞得像大型工程，通常只有兩種可能：你太晚換，或你一開始就選錯方向。

原文把專用 Solana infrastructure 講成把 hobby script 變成 production system 的那個開關，我認同。因為當用戶開始期待交易真的落地，你就不是在寫程式而已，你是在跑服務。專用 RPC 提供的是優先權、較穩的 uptime 預期、還有比較不會被別人流量拖下水的空間。白話一點，就是買可預測性。

我自己看過太多團隊對月費很敏感，對故障成本卻很鈍。每次一看到 dedicated RPC 的帳單就皺眉，但如果那個帳單能換掉 support ticket、用戶流失、和一堆「我剛剛明明有按送出」的抱怨，那其實不貴。帳單是明的，損失是慢慢流血。

實操上，我會建議在正式上線前就選好專用 provider，切換方式盡量只靠 environment variable。不要把 endpoint 寫死在 code 裡，這種事很容易把切換搞成一場災難。如果供應商有 staging endpoint，就先拿 staging 驗證 production config，再做一次乾淨的 redeploy。

如果你要看 Solana 官方脈絡，可以先從 Solana 的文件開始，再對照像 Helius 這類 RPC provider 的說明。重點不是我推薦哪一家，而是你要先承認 RPC 不是免費水電，它是你產品的一個依賴。

基礎設施不是背景音，它就是產品的一部分

“Infrastructure is part of your product.”

這句我想直接貼在很多團隊的牆上。因為太多人以為產品是 UI、是功能列表、是交易流程圖，結果把基礎設施當成背景雜訊。問題是，使用者根本不看你的架構圖，他只感受到交易有沒有成功、swap 有沒有卡住、整個 app 穩不穩。

也就是說，可靠性本身就是功能。如果你的 app 理論上很快，實際上卻常常失敗，那使用者體感就是爛。更糟的是，很多 bot 或 dapp 的商業模式還會偷偷依賴「網路平靜」這件事，一旦流量一上來，整個模型就露餡。那不是產品，那只是運氣。

我看過團隊花很多時間修 UI 邊距、動畫、顏色，後端 request 卻一直被 throttling，這種落差很常見。前台看起來像 ready，log 也寫得像沒事，結果一有 spike 就整個垮掉。這篇原文最有用的提醒就是：不要把 delivery quality 和 product quality 分開看。它們本來就是同一件事。

實操寫法：把你的基礎設施假設寫進需求文件。像是「需要 sub-second confirmation」、「可以接受 retry」、「可以接受 2% timeout」這種話要明講。然後把每個假設對應到 provider 能不能做到。做不到，就別說功能已完成；最多只能說 demo 能跑。

付錢買穩定，比付代價救火便宜

“The $100/month she was spending on a dedicated node was nothing compared to the cost of losing users due to failed transactions.”

這段就是整篇最現實的地方。免費看起來很優雅，付費看起來像提早花錢，但只要你真的上線，這個帳很快就會算回來。因為使用者信任比月費貴太多了，而且它不是一次性成本，是會慢慢壞掉的成本。

翻譯一下就是：你判斷 infra 花費，不能拿「以前都免費」當基準，要拿「失敗一次會損失多少」當基準。對任何涉及付款、swap、交易的產品來說，延遲和失敗都會直接打到信任。support time、退款、流失、重試，這些都不是抽象概念，是你真的會付出去的代價。

我會建議團隊自己算一遍：一個失敗 action 的成本是多少？如果不精準，就抓區間。再拿這個數字去對照專用 RPC 的月費。多半會發現，所謂昂貴的方案其實便宜得離譜。尤其是你如果做的是金融相關功能，reliability spend 應該是產品預算，不是 ops 預算裡可有可無的一項。

• 先估一個失敗交易會帶來多少 support 和 churn 成本。
• 把這個成本和月費直接對比。
• 把 reliability 花費從「維運」升級成「產品預算」。

免費 tier 可以留著，但不要讓它騙你

“Free RPC endpoints are great for learning and testing. But the moment you have real users, real transactions, and real expectations, you need infrastructure that can scale with you.”

這句我同意。免費 tier 不是壞東西，我自己還是會拿來探索 API、驗證鏈上流程、做 proof of concept。問題不在免費，而在你把「暫時能用」誤認成「可以承擔真實流量」。這種誤判很常見，而且很貴。

白話講，學習和生產之間有一條很實際的線，不是哲學問題。當你不能再忍受 timing variance、dropped request、shared rate surprise，線就過了。過了之後，每一個 shortcut 都開始反咬你。你省下來的不是成本，是把風險往後拖。

實操上，我會先定一個 migration trigger。比如：DAU 到多少、每小時交易量到多少、timeout rate 超過多少，就切專用 RPC。這樣你就不是靠感覺做決策，而是靠規則。很多團隊會卡在「再看看」，最後就看進了事故單。

可抄的模板

# Solana dapp RPC 升級模板（可直接貼到團隊文件）

## 目標
把 dapp 從免費 public RPC 遷移到專用 RPC，確保上線後的交易確認、timeout 率、和 support 成本都可控。

## 觸發條件
只要符合任一條，就啟動切換：
- 開始有真實使用者下單、swap、或送交易
- timeout rate 連續 2 天高於可接受值
- 使用者開始回報「送出但沒反應」
- 交易延遲影響產品體驗或收入

## 上線前檢查
- [ ] RPC endpoint 改成 environment variable
- [ ] staging 已驗證新 provider
- [ ] 已做 concurrent request 測試
- [ ] 已記錄 timeout / dropped request / confirmation latency
- [ ] 已準備回滾到舊 endpoint 的方案

## 切換步驟
1. 選定專用 RPC provider
2. 先在 staging 更新 endpoint
3. 跑 10-30 分鐘並發測試
4. 確認交易建立、送出、確認都正常
5. 切 production traffic
6. 觀察 24 小時 metrics
7. 若異常，立刻回滾到舊設定

## 團隊說法
免費 RPC 是拿來學習的。
專用 RPC 是拿來服務使用者的。
只要產品開始依賴穩定性，RPC 就不是背景雜訊，而是產品的一部分。

## 可直接貼的 rollout note
我們要把 Solana dapp 從免費 public RPC 切到專用 RPC，原因是 production traffic 需要可預測的 confirmation、較低的 timeout 風險，以及可追蹤的支援能力。這次切換會透過 environment variable 控制，方便回滾與驗證。

## Metrics
- timeout rate
- dropped request rate
- confirmation latency
- failed user actions
- support tickets related to transaction issues

如果是我自己寫內部 playbook，我會就用這種語氣。不要裝得很偉大，直接講清楚什麼時候換、怎麼測、成功長什麼樣子。這篇原文最有用的地方，也正是它把「之後再說」變成一個可以執行的切換決策。

來源致謝：原始故事來自 Insider Monkey；我這篇的拆解是原文觀點加上我自己對 RPC-backed apps 和 production cutover 的實務整理。Solana 官方文件可參考 Solana，RPC provider 範例可看 Helius。