上千人活動,網路的重要性是「一次性、不能重來」!
只要它掛掉,不是慢一點,而是報到大排長龍、直播當眾斷流、贊助商和上千名觀眾全都看見的公關事件。
要讓它不出事,靠的不是「現場接個網路、開幾台分享器」,而是專屬專線、備援線路、高密度設計,加上現場有工程師顧著。
這篇文章會講清楚四件事:活動網路為什麼特別容易出事?直播為什麼會斷流?上傳頻寬要抓多少?什麼樣的活動網路才叫專業方案?如果你正要辦一場 5000 人次規模的展覽、論壇或發表會,這份攻略能幫你把「網路」這個最大的風險降到最低。
一、為什麼上千人的直播活動,網路特別容易「出事」?
活動網路和辦公室、倉儲網路最大的不同,是它沒有試運轉、沒有第二次機會。
活動只有那幾個小時,網路必須在幾個尖峰時刻一次到位,不能出錯。而它之所以容易崩,來自三股同時壓上來的壓力:
- 壓力一:尖峰併發爆量:活動人潮不是平均分布的——報到開始的那半小時、主講人上台的 keynote 時段、午休大家同時滑手機,都是瞬間湧入的尖峰。網路平常看似順暢,卻往往在這幾分鐘集體崩潰。
- 壓力二:直播上傳被擠:如果現場有直播,它吃的是上傳頻寬,而上傳是最稀缺、最容易被忽略的資源;一旦被現場觀眾上網的流量擠掉,直播就斷流。
- 壓力三:單一線路就是單點故障:只靠場館一條共用網路、或一條線路,那條線一斷,全場同時停擺,而且活動現場沒有時間慢慢修。
這三股壓力疊在一起,就是為什麼「臨時接個網路」對千人活動是場豪賭。
關鍵觀念:用「尖峰併發裝置數」估算,不是總人次
規劃活動網路,第一個、也是最常被搞錯的,就是用「總人次」估算。
5000 人次,絕不等於 5000 台裝置同時連線。
不是所有人都同時在場、也不是每個人隨時都在用網路;但反過來,每個人手上往往不只一台裝置。
實務上,一場 5000 人次的活動,同一時刻真正連線的常落在 1500–3000 台,而且高度集中在報到、keynote 等尖峰。
用總人次估,會把資源平均攤掉、抓不到尖峰的真實負載,結果就是「總頻寬看起來夠、尖峰卻照樣崩」。
正確的起點,是估算尖峰時刻的同時併發裝置數,再據此規劃頻寬與 AP 密度。這是活動網路規劃的第一個分水嶺。
二、直播為什麼會斷流?上傳頻寬與 QoS 的關鍵
如果你的活動要直播,這一節是重點中的重點,因為直播斷流是活動網路最公開、最難看的事故——它就發生在所有線上觀眾眼前。
問題的根源,在一個被普遍忽略的觀念:直播吃的是「上傳」,不是下載。
一般人測網速都看下載夠不夠快,但把影像即時推送到 YouTube、Facebook 或其他平台,靠的是上傳頻寬。而一般網路的上傳通常遠小於下載——這就是為什麼「下載很快」的網路,直播還是會頓、會斷。
實務上的需求是:一路 HD 直播約需要 5–10 Mbps 的「穩定」上傳頻寬,多路同時直播則需求倍增,4K 更高。這裡的關鍵字是「穩定」——直播不能忍受忽高忽低,一旦上傳瞬間被別的流量吃掉,畫面就卡。
專業做法有兩層:
- 第一,用 QoS(流量優先權)把直播與報到系統的流量等級拉到最高,確保它們永遠優先,不會被現場上千名觀眾滑手機、傳照片的流量擠掉;
- 第二,直播走專屬的「展場直播專線」,與觀眾共用的 WiFi 分流,從源頭把直播的命脈獨立出來。
這兩層做到,直播才有不斷流的底氣。
三、千人活動網路方案的四大支柱
要讓 5000 人次的活動全程不出事,靠的是四道互補的保險。少一道,風險就多一分。
| 支柱 | 做什麼 | 防止什麼 |
|---|---|---|
| ① 專屬頻寬專線 | 為活動申請專屬電路,不與場館或其他攤位共用 | 共用網路被別人拖垮、頻寬無保證 |
| ② 備援不中斷 | 建置 5G/4G failover,主線斷時自動切換備援 | 單一線路斷掉就全場停擺 |
| ③ 高密度 AP+QoS | 企業級 AP 按尖峰併發佈點,QoS 優先保護直播與報到 | 尖峰過載、直播與報到被擠垮 |
| ④ 現場駐點維運 | 工程師現場即時監控、調整、除錯 | 臨場突發、出事沒人即時處理 |
- 第一支柱專屬專線是地基——場館內建網路常與其他攤位、訪客共用,尖峰時你無法控制別人用掉多少,關鍵活動必須有自己的專屬頻寬。
- 第二支柱備援是底線——再好的單一線路都可能出意外,5G/4G failover 讓對外連線有第二條腿,主線一斷就自動接手。
- 第三支柱高密度 AP+QoS承接前兩節的設計:按尖峰併發而非總人次佈點、用企業級 AP(而非消費級設備),並用 QoS 守住直播與報到這兩條命脈。
- 第四支柱現場駐點,是活動網路最不能省的一環。因為活動現場的變數,遠端處理不了:攤位臨時移位、主辦方臨時加一路直播、某個區域人潮遠超預期、設備被人不小心碰掉線……這些都需要有人在現場、即時判斷、馬上動手。
更重要的是分工:主辦方該專注把活動辦好,不該在台下盯著無線電的數據。
現場駐點工程師的價值,就是讓主辦方完全不用操心網路——有人即時監控每個區域的負載、在尖峰前預做調整、出狀況時當場排除。這道「現場有人扛」的保險,是把「不能出事」從口號變成承諾的關鍵。
四、活動網路籌備時程:從提前申請到撤場
活動網路最大的時間地雷,是專線要提前數週申請。
拉一條新的專屬電路需要電信商的前置作業時間,等到活動前幾天才想到,往往來不及——這也是臨時找方案最常踩的坑。建議照以下時程倒推準備:
| 時程 | 要做的事 |
|---|---|
| 活動前數週 | 確認預估人次、尖峰時段與直播需求;申請專屬專線 |
| 活動前 1–2 週 | 現場勘測(Ekahau)、設計覆蓋與 AP 佈點、規劃 QoS 與備援 |
| 進場佈建 | 佈線、架設 AP、設定 QoS 與 failover、做壓力測試 |
| 活動當天 | 駐點工程師全程即時監控、依現場狀況調整 |
| 撤場 | 設備撤收、提供結案報告 |
特別建議在佈建階段做一次「彩排式測試」——用與活動當天完全相同的流程,預先測試報到登入、直播推流、互動系統,把問題在觀眾來之前就抓出來。活動網路沒有重來的機會,所有問題都該在開門前解決。
五、活動網路怎麼發包?該問廠商哪些問題
如果你要把活動網路發包出去,發包前先把這些資訊備齊:活動日期與場地、預估總人次與尖峰時段、是否直播(幾路、解析度)、報到/互動/POS 等系統需求。
這些決定了方案的規模與報價。
而面對廠商,與其比誰報的頻寬數字大,不如問對這幾個關鍵問題:
- 有沒有專屬專線?
- 還是只是接場館的共用網路?
- 有沒有備援?
- 主線斷了怎麼辦、有沒有 5G/4G failover?
- 現場有沒有駐點工程師?
- 出事時是遠端回覆、還是有人當場處理?
- 萬一出狀況,承諾的應變方式與責任是什麼?
問完這幾題,專業與否就一目了然。
記住一句準則:千人活動的網路,你買的不是頻寬,是「不出事的保證」。
便宜的方案如果在尖峰崩了、直播斷了,省下的錢遠不及一場公開事故的代價。
下一步:把活動日期、預估人次、是否直播、場地資訊整理成一份清單,預約一次活動網路方案評估。蓋斯克科技會以專屬專線、5G 備援、高密度企業級 AP 與現場駐點維運,為你的展覽與直播全程把關,讓 5000 人次的活動網路不出事。
辦公室搬遷、裝潢或網路架構需要全面規劃?
蓋斯克科技提供免費到府勘查(雙北地區),1,200+ 企業服務經驗,48 小時內提供規劃方案與透明報價。
企業 Wi-Fi 建置服務 免費預約諮詢02-2717-1019 LINE:@zonetech
大型活動網路的常見問題 FAQ
Q1:5000 人次的活動,網路頻寬要準備多少?
沒有單純依人次的公式,要按「尖峰同時併發裝置數」估算。5000 人次不等於 5000 台同時連線,實際同一時刻常落在 1500–3000 台,且高度集中在報到、keynote 等尖峰。正確做法是先估尖峰併發裝置數,再依使用型態(上網、直播、報到、互動)規劃頻寬與 AP 密度,並預留餘裕。用總人次估算會嚴重失準。
Q2:活動直播為什麼會斷流?要準備多少上傳頻寬?
因為直播吃的是上傳頻寬,而非下載,這點最常被忽略。一路 HD 直播約需 5–10 Mbps 的穩定上傳,多路或 4K 需求更高。一旦上傳被現場觀眾上網流量擠掉,畫面就會頓、斷。解法是用 QoS 把直播流量優先權拉到最高,並讓直播走專屬的展場直播專線,與觀眾公用 WiFi 分流,確保上傳穩定不被搶。
Q3:場館本來就有 WiFi,還需要另外申請專線嗎?
關鍵活動強烈建議另外申請專屬專線。場館內建網路通常與其他攤位、訪客共用,尖峰時你無法控制別人用掉多少頻寬,等於把活動成敗交給不可控的共用環境。報到、直播、金流這類不能出錯的系統,應走專屬頻寬並搭配備援,才能確保尖峰時段的穩定與優先權,避免被全場流量拖垮。
Q4:活動專線要提前多久申請?
建議至少提前數週。申請一條新的專屬電路,電信商需要前置作業與布建時間,臨時才提出往往來不及。提前申請也才有足夠時間做現場勘測、設計覆蓋、佈建與壓力測試,把問題在活動前解決。活動網路沒有重來的機會,越早啟動籌備,風險越低,這是大型活動最常被低估的時間地雷。
Q5:萬一活動當天網路斷了,怎麼補救?
靠事前的備援設計與現場駐點工程師。備援上,建置 5G/4G failover,主線中斷時自動切換到備援線路,幾乎無感;設計上採專線加備援的雙線架構,避免單點故障。人力上,現場一定要有駐點工程師即時監控、當場排除問題,而不是遠端回覆。把「斷線補救」設計在事前,而非等出事才應變,才是真正的不出事。
辦公室搬遷、裝潢或網路架構需要全面規劃?
蓋斯克科技提供免費到府勘查(雙北地區),1,200+ 企業服務經驗,48 小時內提供規劃方案與透明報價。
企業 Wi-Fi 建置服務 免費預約諮詢02-2717-1019 LINE:@zonetech




