Docs

Add new doc from here

網路設定變更

Last Updated: 2026年6月27日

說明如何從 BESTNET-CLOUD 伺服器管理畫面查看與新增網路介面(NIC)、指派 IP 位址並變更連線狀態,含介面清單欄位解說、子網路選擇與疑難排解。

API 規格

Last Updated: 2026年6月27日

BESTNET-CLOUD 客戶入口網站提供 HTTP REST API,回應皆為 JSON。本指南說明基底 URL、Basic 認證、主要方法群與請求範例,協助您以程式自動化查詢與操作已簽約服務。

AI 代理對自己的操作說了「不行」——AI 護欄與三層治理,DB 遷移中被攔下兩次的實錄

Last Updated: 2026年6月27日

將伺服器實際作業交給 AI 代理後,安全機制(護欄)在執行前兩次攔下危險操作。它是守門人,還是統制的極限?以實例談事前原則×承認關卡×護欄的三層治理與稽核日誌運用。

在 plink・PowerShell 5.1・SQL Server 2022 上踩到的 10 個坑——把 Windows 實機作業交給 AI 代理 (SSH/字元編碼/T-SQL)

Last Updated: 2026年6月27日

以 AI 代理(Claude Code)在實機運行 Windows/SQL Server 自動化所踩的 10 個坑。從 plink 主機金鑰釘選、CP932/BOM、cmd 引號、RemoteSigned,到 System.Data.SqlClient 的 GO 分割、ARITHABORT、sys.partitions,以症狀→原因→對策逐一解說。

以 AI 自動化 Oracle 19c → SQL Server 2022 遷移的前處理——「不交付任何一行實際資料」的 Claude Code 實踐記

Last Updated: 2026年6月27日

在完全不向 AI 編碼代理(Claude Code)交付實際資料的前提下,完成異質 DB 遷移(Oracle 19c→SQL Server 2022)的前處理:相容性預測、轉換設計,以及在遷移目標實機上的套用與功能驗證,並提出統制 3 原則與三層治理。

DNS服務使用指南(操作指南)

Last Updated: 2026年6月15日

BESTNET-CLOUD DNS 服務操作指南。透過客戶入口建立區域、新增/編輯/刪除各類 DNS 記錄(A、CNAME、MX、TXT 等)、DNSSEC、故障轉移監控,並附操作截圖。

LLM 幻覺稽核的實作

Last Updated: 2026年6月13日

// BASTION Technical Explanation2026-06-13 LLM Hallucination Audit Implementation Cross-checking the numbers AI writes against real-device logs Author: Hideyuki Chinda / BESTNET LLC Related: The More Beautiful the Design, the More You Doubt It with Real Data — BASTION’s Verification Discipline 1. The Trigger — The AI Wrote “639.” The Real Count Was 0 Some time...

設計越優美,越要用真實資料質疑 ― BASTION 投入正式環境前的驗證紀律

Last Updated: 2026年6月13日

在為正式環境基礎設施導入自動控制之前,用真實資料反證自己的假設 ― BASTION 的驗證紀律。

在 Web 伺服器上實作 AI 主動防火牆的故事

Last Updated: 2026年6月9日

2026.04 / Tech Blog / BASTION 在網頁伺服器上實作 AI 主動式防火牆的經驗 Fail2Ban 的固定閾值無法偵測未知的 Bot 模式或垃圾請求,我們實作了一套由本地 LLM 每 15 分鐘分析並自動封鎖的機制。在現有的 nginx + Fail2Ban 之上添加 AI 分析層,建構三層防禦架構。 Fail2Ban 雖然優秀但對「未知」威脅較弱 針對網頁伺服器的 Bot 對策,nginx 的 UA map + 速率限制 + Fail2Ban 的組合是標準配置。將每分鐘產生 10 次 403 的 IP 封鎖 1 小時。簡單且確實。 但這種方式存在結構性弱點。 Fail2Ban 的閾值是「固定的」。僅能透過「每分鐘 403 達 10 次」等靜態條件觸發。不斷變更 UA 緩慢爬取的 Bot、連續請求不返回 403...

從 Slack 批准閘道器畢業遷移至攻擊來源 IP 完全自動化封鎖的故事

Last Updated: 2026年6月9日

2026.04 / Tech Blog / BASTION 從 Slack 批准閘門畢業,轉向攻擊來源 IP 的完全自動封鎖 在上一篇文章中實作了 Slack 批准閘門方式的反應式防禦,但透過 AI 代理的批准存在結構性問題。透過切換到不經由 LLM 的直接管道,轉向了從偵測到 15 分鐘內完成自動封鎖的完全自主型。 前情提要 BASTION 的反應式防禦是一個機制:本地 LLM 偵測到連接埠掃描或暴力破解時,透過 OPNsense 的防火牆 API 自動封鎖攻擊來源 IP。 在上一篇文章(AI 偵測到攻擊→在 Slack 批准→自動在防火牆封鎖的機制製作記)中,為了安全起見,我們採用「Slack 批准閘門方式」——AI 提案,人類在 Slack 批准後才執行封鎖——開始運作。 但在實際運作中發現了 Slack 批准閘門的結構性問題,僅僅一天就轉向了完全自動化。本文記錄這個過程,以及為什麼「不經由 LLM 的管道」才是正確答案。 Slack 批准閘門發生的問題 問題 1:AI 代理「謊稱完成」 嘗試同時批准 3 個封鎖提案,在 Slack 發送了以下訊息。 操作員 13:34...

AI 偵測到攻擊→透過 Slack 核准→建置了自動封鎖至防火牆的機制

Last Updated: 2026年6月9日

AI 偵測攻擊→Slack 批准→自動加入防火牆封鎖的機制 在 BASTION 的「偵測→通知」循環中新增「自動處置」功能。AI 偵測到連接埠掃描後會在 Slack 發布封鎖建議,由人員批准後立即在 OPNsense 防火牆中加入封鎖規則。24 小時後自動解除。 僅「偵測並通知」已不足夠 過往的 BASTION 是分析日誌、偵測異常並在 Slack 發出通知的機制(第 1 回參照)。然而收到通知後的動作——封鎖攻擊來源 IP 的防火牆處置——仍需人員手動開啟 OPNsense 管理介面進行操作。 凌晨 3 點收到通知,隔天早上登入後才進行封鎖。在這 6 小時內,攻擊者可以任意掃描。 因此我們為 BASTION 實作了反應式防禦。AI 偵測到攻擊後會自動提議加入防火牆封鎖,只需在 Slack 批准即可立即在 OPNsense 中加入規則。 但不會立即完全自動化。賦予 AI 變更防火牆規則的權限,代表存在誤判而阻斷正常通訊的風險。首先採用「AI 提議→人員批准→執行」的 Slack 批准閘道方式,累積實績後再逐步自主化。 整體流程 步驟 執行者 動作 1. 攻擊偵測 analyze.sh(每 15 分鐘) 日誌分析偵測連接埠掃描、暴力破解。severity: HIGH 判定...

使用 Claude Code 將 PRTG 網路設備監控定義遷移至 Zabbix【續集】

Last Updated: 2026年6月9日

使用 Claude Code 將 PRTG 的網路設備監控定義遷移到 Zabbix【續篇】 Migration / Monitoring 使用 Claude Code 將 PRTG 的網路設備監控定義遷移到 Zabbix【續篇】 繼上次的 UPS 篇之後,這次遷移的是交換器、路由器、無線 AP 混合的環境。 在全部設備為同一廠商這個統一優勢的基礎上,採用「先註冊、後啟用」的安全流程進行。 Claude Code PRTG Zabbix SNMP Python 與上次(UPS 篇)的差異 上次是全部為 APC UPS 的統一配置,因此只需套用 1 種範本即可完成。 這次的對象是 2023 年的備份,包含交換器、路由器、無線 AP 等多種設備。 上次(UPS 篇) 全部為 APC UPS 1 種範本・立即啟用。 30 分鐘完成。 這次(網路設備篇) 3 個類別混合 分為交換器、路由器、AP。...

只需導向 syslog,AI 就能自動判定設備種類並開始監控的機制已經建立

Last Updated: 2026年6月9日

2026.04 / Tech Blog / BASTION 只要轉發 syslog,AI 就能自動判定設備類型並開始監控的機制 當新設備開始傳送 syslog 的瞬間,LLM 會讀取日誌樣本並自動判定「這是 Windows 客戶端」「這是防火牆」。套用適當的監控範本並立即開始監控。無需手動註冊設備。 傳統監控導入中最麻煩的事 導入監控工具時,最耗費工時的不是初始設定,而是「每台設備的註冊作業」。 無論是 Zabbix 還是其他 SIEM,每次將新設備加入監控對象時都需要「主機註冊→範本選擇→解析器設定→測試→正式套用」的步驟。10 台設備需要 2〜3 人日,100 台則需要 20〜30 人日。而且每次設備增減都會產生這項作業。 BASTION 消除了這整個流程。 BASTION 的做法:只需設定一行 rsyslog 目的地。之後全由 AI 處理。設備類型判定、監控範本套用、終端增減追蹤都是自動的。人工註冊作業為零。 機制的整體架構 以下 5 個步驟全自動運作。 步驟 執行內容 執行時機 1. 日誌抵達 新設備傳送 syslog。rsyslog 以主機名稱自動建立目錄 即時 2. 偵測新主機 與上次的主機清單比較,發現新目錄 每天 1 次(cron) 3....

AI 日誌監控偵測到「當機 PC 導致帳戶鎖定」的案例

Last Updated: 2026年6月9日

2026.04 / Tech Blog / BASTION AI 日誌監控如何偵測到「當機 PC 造成的帳號鎖定」 BASTION 的 Windows 用戶端監控偵測到公司內部人員帳號的異常鎖定。透過 Slack 特定來源 IP,發現原因是一台當機的終端設備。從偵測到找出原因僅需 5 分鐘。 發生了什麼事 BASTION 的定期分析報告中出現了不尋常的一行。 失敗帳號: svc-ldap=203, DC-01$=194, SV-01$=24, admin-user=13 鎖定對象: svc-ldap=225, DC-01$=224, SV-01$=33, admin-user=16 Copy to Clipboard 問題出在 admin-user。這是人員帳號。被鎖定了 16 次。完全沒有頭緒。 為什麼這很重要:人員帳號反覆發生鎖定時,可能是密碼暴力破解攻擊。需要確認來源 IP,判斷是外部攻擊還是內部終端設備問題。 透過 Slack 特定來源 IP BASTION 具備透過 Slack 進行互動式分析指示的功能。 Copy to Clipboard 原因 確認來源 IP...

使用 Claude Code 在 30 分鐘內將 PRTG 的 UPS 監控定義遷移至 Zabbix

Last Updated: 2026年6月9日

遷移 / 監控 使用 Claude Code 在 30 分鐘內將 PRTG 的 UPS 監控定義 遷移至 Zabbix 只需提供一個備份檔案。無需 API 伺服器,也不必從零開始撰寫腳本。 將任務完全交給 AI 代理後,它真的成功運作了。 Claude Code PRTG Zabbix APC UPS SNMP Python 為什麼要從 PRTG 遷移到 Zabbix? 本公司一直使用PRTG Network Monitor 透過 SNMP 監控部分區域的 UPS(不斷電系統)。 雖然運作穩定且沒有特別的不滿,但隨著感測器數量接近授權上限, 加上成本檢討的契機,我們決定考慮遷移至 Zabbix。 Zabbix 是開源軟體,主機數和指標數無限制。與 Grafana 的官方外掛也相當完善。 沒有理由不遷移。問題在於「遷移作業本身」。 不存在 PRTG → Zabbix 的一鍵遷移工具。 當裝置數量眾多時,手動重新設定可能需要數天時間。 因此這次我們使用了...

自動化本地 LLM 推論伺服器存活監控的經驗

Last Updated: 2026年6月9日

本地 LLM 推論伺服器的死活監控自動化 檢測 GPUStack「看似運作但無法推論」的狀態。建立了每 5 分鐘執行一次的兩階段健康檢查 + Slack 通知 + Zabbix 整合機制。 問題所在 在上一篇文章(使用本地 LLM 自動分析基礎架構日誌的機制)中介紹的 BASTION,是一個每 15 分鐘使用本地 LLM(Qwen2.5-14B)自動分析基礎架構日誌的機制。 這個機制的單點故障是GPUStack(LLM 推論伺服器)。當 GPUStack 停止運作時,日誌收集會繼續進行,但分析和通知會全部停止。而且,發現停止運作的時間會很晚。等到人類注意到每 15 分鐘的 Slack 通知「沒有出現」,可能已經過了好幾個小時。 GPUStack 本身具有模型自動重啟功能。當程序崩潰時會自動重啟。但是,僅靠這個功能無法檢測到某些情況。 GPUStack 自動重啟無法檢測的情況:・API 程序存活但模型因 OOM 而卸載・API 回傳 200 但模型不回應推論請求・網路上無法從 BASTION 伺服器到達 GPUStack 也就是說,「程序存活」和「推論實際運作」是不同的問題。需要從外部定期確認「是否真的能進行推論」的機制。 設計方針 要做的事情很簡單。每 5 分鐘呼叫 GPUStack 的 API,正常時不做任何事,異常時發送 Slack 通知。不過,有幾個設計決策。 兩階段檢查 將健康檢查分為兩個階段。 階段...

「針對日本黃金週的攻擊」調查後,發現了全球規模的機器人經濟

Last Updated: 2026年6月13日

// BASTION Technical Explanation2026-05-16 I thought we were investigating “attacks targeting Japan’s Golden Week,” but what I found was a global-scale bot economy Author: Hideyuki Chinda / BESTNET LLC Related articles: How multilayer correlation campaign detection works / DMZ Agent and verification engine / Implementation record: achieving accuracy and decisiveness with local LLM infrastructure log...

Qwen2.5-14B + GPUStack 實現精度與確定性兼具的實作記錄

Last Updated: 2026年6月9日

// BASTION 技術解說 2026-05-14 Qwen2.5-14B + GPUStack 兼顧精確度與確定性的實作記錄 著者: 珍田 秀幸 / ベストネット合同会社 相關文章: 多層相關活動偵測機制 / DMZ Agent 與驗證引擎 1. 前言 — 為何選擇本地 LLM BASTION 的核心是本地 LLM(Qwen2.5-14B)。我們並未選擇 GPT-4 或 Claude 等最先進的外部 LLM API,而是選擇在自己的 GPU 伺服器上運行 Qwen2.5。 「既然精確度較高的應該使用更好的,為何特意選擇性能較差的本地模型?」這樣的疑問是理所當然的。本文將說明該選擇的背景,以及實際上是如何運作的。 先說結論,本地 LLM 除了「精確度」之外還有 3 個強大的優點,在基礎設施維運這個領域中,這些優點更為重要,這就是我們要說的故事。 2. 雲端 LLM 的 3 個障礙 在 BASTION 開發初期,我們理所當然地考慮使用 OpenAI API 或 Anthropic...

在可能遭受入侵的 DMZ 環境中採用「不信任 Agent」前提的設計

Last Updated: 2026年6月9日

// BASTION 技術解說 2026-05-13在可能遭到入侵的 DMZ 環境中「不信任 Agent」的設計前提 作者:珍田 秀幸 / ベストネット合同会社 相關文章: 多層關聯活動偵測機制 1. 前言 — DMZ 存在安全監控的「死角」 對於雲端服務業者或主機代管業者而言,公開 Web 伺服器或反向代理等 DMZ(非武裝區)伺服器是最容易成為攻擊目標的地方。 即使在這些地方,透過 syslog 轉送來集中管理日誌的架構並不罕見。然而,這裡有一個重要的前提: // 重要前提 不能信任「遭到入侵後的 DMZ」 DMZ 伺服器位於攻擊者的最前線,隨時都有可能遭到入侵。如果內部監控系統無條件信任遭到入侵的伺服器所傳送的日誌或狀態資訊,攻擊者就能透過持續傳送「偽裝正常狀態」來欺騙監控系統。 BASTION 的 DMZ Agent 正是基於「Agent 本身可能遭到入侵」這個前提進行設計。本文將說明這個「Agent 不信任模型」以及支援此模型的驗證引擎設計。 2. 為何現有的 EDR 或 SIEM Agent 不足夠? 透過 EDR(Endpoint Detection & Response)或 SIEM 產品的 Agent 功能,也能進行端點異常偵測。然而,這些產品大多基於以下前提: Agent...

多層關聯活動偵測機制

Last Updated: 2026年6月15日

// BASTION Technical Explanation2026-05-10 How Multi-Layer Correlation Campaign Detection Works Visualizing attack scenarios invisible in single-device logs through cross-layer tracing Author: Hideyuki Chinda / BESTNET LLC Related Articles: Evolving BASTION from a “Security Product” to an “AI Ops Platform” 1. Introduction — Why “Single-Device Logs” Are Not Enough In security log monitoring operations, judgments about...

本地 LLM 在監控報告中捏造數值的事件及其對策

Last Updated: 2026年6月9日

本地 LLM 偽造監控報告數值的事件與對策 BASTION 的 AI 監控報告中寫著「認證失敗 639 件」。實際上是 0 件。針對本地 LLM 安全監控中無法避免的幻覺問題,採用抽樣檢查與多層備援機制來因應的紀錄。 AI 會說謊 BASTION 每 15 分鐘會使用本地 LLM 分析基礎架構日誌,並將報告發送到 Slack。某天的報告中寫著以下內容。 incoming-webhook 17:08 在 Windows AD 中,雖然發生大量認證失敗和帳戶鎖定,但這些是由 Kerberos 電腦帳戶和 LDAP 整合所引起,屬於正常情況。在 VPN 中,發生 239 件來自 OpenVPN 的認證失敗。 639 件認證失敗。239 件 VPN 認證錯誤。單看數字,似乎應該判斷為「異常」的數值。 但直接統計實際日誌後,認證失敗為 81 件,VPN 認證錯誤為 102 件。進一步調查後發現,傳遞給 LLM 的輸入資料中寫著「認證失敗:0 次」「VPN 錯誤:無錯誤」。LLM 將輸入的「0」改寫成「639」。 抽樣檢查方法...

建立了透過跨所有系統的日誌關聯來偵測單一系統無法發現的攻擊機制

Last Updated: 2026年6月9日

2026.04 / Tech Blog / BASTION 建立跨全系統日誌關聯機制,偵測個別無法發現的攻擊 防火牆的連接埠掃描、VPN 的認證失敗、應用程式的登入嘗試。個別事件的嚴重程度為「低」。然而,當同一 IP 同時出現在這三個層級時,那不是巧合,而是攻擊活動。我們在 BASTION 中實作了多層關聯引擎,並在實際攻擊中驗證了跨 3 層的活動偵測。 個別設備監控存在結構性盲點 BASTION 至今為止一直是針對每個設備分析日誌並偵測異常。防火牆的連接埠掃描、Web 伺服器的 bot 攻擊、AD 的認證失敗——當每個設備超過閾值時就進行封鎖。 然而這種方式無法偵測組合低於閾值攻擊的活動。 攻擊者不會集中在單一設備上。首先透過連接埠掃描偵察網路配置,接著嘗試 VPN 認證,最後嘗試登入 Web 應用程式。每個階段都只是「稍微多一點」的程度,在個別監控系統中不會達到閾值。然而從整體來看,同一 IP 依序攻擊多個防禦層——這明顯是一個活動。 為了偵測這種「個別看不見,但橫向檢視就能看見」的模式,我們在 BASTION 中實作了多層關聯引擎。 多層防禦的結構 BASTION 監控的基礎架構由 5 個防禦層組成。 層級 防禦對象 偵測的事件 L1: 網路邊界 防火牆 連接埠掃描、DDoS、惡意封包 L2: VPN / 遠端存取 VPN 閘道 TLS 錯誤、認證失敗、憑證探查 L3: 認證基礎架構...

從 GPUStack v0.7.1 遷移至 v2.1.1 的經驗分享

Last Updated: 2026年6月9日

Tech Blog GPUStack Docker Migration NFS Shared CacheGPU 叢集營運備忘錄 將 GPUStack 從 v0.7.1 遷移至 v2.1.1 在不破壞共用 NFS 模型快取配置的情況下進行升級 這是將基於舊 installation script 營運的 GPUStack 環境遷移至基於 Docker 的 v2 系統的紀錄。 在維持管理節點與 NFS 兼用配置的同時,分階段遷移了 2 台 GPU 工作節點, 並整理了模型快取共用、工作節點重新連接、部署時的 backend/CUDA 整合確認等內容。 為公開發布,已將主機名稱、IP、權杖抽象化 Ubuntu / Docker / NVIDIA GPU / NFS 對象:GPUStack v0.7.1 → v2.1.1 本文的前提 實際環境由 1 台管理節點和...

在 Proxmox VE 上的 Ubuntu 24.04 VM 中為 Tesla V100 安裝 NVIDIA Driver 和 CUDA 12.9

Last Updated: 2026年6月9日

Proxmox VE / Ubuntu 24.04 / NVIDIA CUDA 在 Proxmox VE 上的 Ubuntu 24.04 虛擬機中為 Tesla V100 安裝 NVIDIA Driver 和 CUDA 12.9 在 Proxmox VE 的 OVMF 虛擬機中透過 PCIe 直通 Tesla V100,並在 Ubuntu 24.04 端安裝 NVIDIA 驅動程式和 CUDA Toolkit 12.9 的步驟。 也包含如何避免在 OVMF 環境中容易出現的 BAR0 is 0M @ 0x0 / This PCI I/O region...

在 BESTNET 雲上建置 Redmine

Last Updated: 2026年6月9日

BESTNET Tech Blog 在 BESTNET-CLOUD 上建置 Redmine 的步驟 Ubuntu 24.04 / Apache + Passenger / PostgreSQL / HTTPS,啟動 Redmine 6.1 系的伺服器建置篇 本文將依序整理在 BESTNET-CLOUD 上準備的 Ubuntu 24.04 LTS 虛擬機上建置 Redmine,直到可以從瀏覽器進行首次登入的狀態。 LDAP/LDAPS 整合、外部 SMTP、Zabbix 整合預計在後續的另一篇文章中處理,本次首先以「能夠穩定顯示登入畫面的 Redmine 伺服器」完成為目標。 本次目標 達成點 透過 HTTPS 顯示 Redmine 登入畫面,並能以管理員進行首次登入的狀態。 本次範圍 OS 初始設定、Redmine 配置、DB 初始化、Apache + Passenger、自簽 SSL 等。 下次以後 AD / LDAPS、外部...

聯盟行銷使用條款

Last Updated: 2026年6月9日

Affiliate Program Terms BESTNET LLC聯盟行銷計畫使用條款 本條款訂定由 BESTNET LLC(以下稱「本公司」)營運之聯盟行銷計畫(以下稱「本計畫」)的使用條件。聯盟行銷註冊申請者及參與者應同意本條款後,使用本計畫。 制定日:2026年3月14日營運者:BESTNET LLC 參與方式審查・核准制計算期間原則為30天報酬確定付款後30天以上且為有效訂單最低提領金額NT$2,017手續費方案依商品・條件另行訂定 第1條(適用) 本條款適用於本計畫相關之一切使用關係。 本公司就本計畫,於管理介面、網站、個別通知、活動頁面、電子郵件及其他本公司指定之方法中另行訂定之條件、營運基準、手續費方案、指引等(以下統稱「個別條件」),應構成本條款之一部分。 個別條件與本條款牴觸時,於該牴觸範圍內,以個別條件優先適用。 第2條(定義) 「聯盟夥伴」係指同意本條款,經本公司核准而參與本計畫之個人或法人。 「推薦連結」係指本公司針對各聯盟夥伴所發行之附識別碼URL、橫幅、代碼及其他用於計算推薦之手段。 「合格推薦」係指透過推薦連結及其他本公司認可之方法,於本公司系統上有效計算之推薦。 「合格訂單」係指基於合格推薦所產生之訂單中,符合本公司另行指定之對象商品・對象行為,且滿足本條款及個別條件所訂承認條件之訂單。 「報酬」係指針對合格訂單,本公司向聯盟夥伴支付之手續費、推薦費、佣金及其他無論名目為何,基於本計畫所產生之金額。 第3條(本公司與聯盟夥伴之關係) 聯盟夥伴應以獨立事業者或個人身分參與本計畫,並非本公司之代理人、員工、共同事業者、加盟主或銷售代理店。但與本公司另行締結書面契約時不在此限。 聯盟夥伴不得代理本公司締結契約,以本公司名義表示・請求・收款,或使本公司負有法律義務。 聯盟夥伴未經本公司明示同意,不得自行承接本公司服務相關之支援、保固、退款、請求、障礙應對及其他客戶應對。 第4條(參與申請及審查) 欲參與本計畫者,應以本公司指定之方法提出申請,並正確且以最新內容提供本公司要求之資訊(姓名或名稱、聯絡方式、網站URL、社群媒體帳號、預定之集客方法及其他本公司認為必要之事項)。 本計畫採審查・核准制,本公司得依申請內容、媒體內容、集客方法、過往營運實績、品牌適配性、詐欺風險及其他本公司指定之基準,任意判斷是否同意參與。 本公司無須負有理由說明義務,得不核准申請,或要求提交追加資料、本人確認、媒體確認及其他確認。 未成年人提出申請時,應取得法定代理人之同意。未成年人提出申請時,本公司得視為已取得該同意。 第5條(註冊資訊及帳戶管理) 聯盟夥伴於註冊資訊有變更時,應迅速以本公司指定之方法更新。 聯盟夥伴應自行負責嚴格管理登入資訊及其他帳戶認證資訊,不得向第三方出借、轉讓、共用或買賣。 本公司得將透過帳戶所進行之行為,視為持有該帳戶之聯盟夥伴本人之行為。 每一人或每一法人所能持有之帳戶,除本公司另行核准之情形外,原則為一個。確認有重複帳戶時,本公司得進行整合、停用或刪除。 第6條(推薦方法及廣告表示) 聯盟夥伴得透過自己管理或合法擁有使用權限之網站、部落格、社群媒體、影片發布、電子報、廣告媒體及其他合法管道,進行基於本計畫之推薦。 聯盟夥伴應遵守法令、業界自律規範、平台條款及廣告表示相關各項指引,並於必要時以閱覽者易於理解之方法標示「廣告」「PR」「贊助商」等字樣。 本公司於本計畫實施所需之範圍內,授予聯盟夥伴非專屬、不得轉讓、可撤銷之權利,以使用本公司提供之橫幅、標誌、文字、推薦連結及其他素材。 聯盟夥伴除經本公司事前核准外,不得以本公司官方網站、本公司支援窗口、本公司代理店及其他使人誤認為本公司之態樣表示或招攬。 第7條(推薦之計算及歸屬) 合格推薦之成立,應依據推薦連結、Cookie、推薦代碼、與客戶帳戶之關聯及其他於本公司系統上有效記錄之資訊進行判斷。 用於推薦計算之Cookie及其他計算期間,除個別條件另有訂定外,原則為自推薦點擊時起30天。 針對同一客戶存在多個聯盟夥伴或多個廣告接觸點時,推薦之歸屬應依本公司系統最終判定為有效之推薦資訊、客戶註冊資訊、既有之關聯及其他本公司認為合理之基準決定。 因瀏覽器設定、拒絕Cookie、裝置切換、廣告阻擋器、平台限制、手動輸入、第三方媒體規格及其他超出本公司合理控制之事由而導致推薦無法正確計算時,本公司不負其責任。 透過推薦連結註冊之客戶,於本公司系統上可能關聯至該聯盟夥伴。但該關聯不保證對該客戶之所有未來訂單均支付報酬,各訂單之合格性應依該時點之手續費方案及個別條件進行判斷。 第8條(合格訂單及承認條件) 欲獲承認為合格訂單,至少應符合下列各款。 為本公司指定為聯盟夥伴對象之商品或服務之有效訂單。 基於合格推薦所產生,且於本公司系統上能有效確認對該聯盟夥伴之歸屬。 訂單金額之付款已完成。 付款完成日起已經過30天以上。 與該訂單相關之所有服務均處於有效狀態。 不存在取消、退款、拒付、付款否決、無法回收、詐欺使用或與其相當之事由。 原則上,以本公司另行訂定為對象之新客戶之有效訂單為報酬對象。但續約、升級、追加契約、選購申請及其他訂單列為對象時,本公司應於個別條件中明示。...

建置 OPNsense 的 WireGuard VPN 並從 Windows 用戶端連線的步驟

Last Updated: 2026年6月9日

網路設定教學 將自宅、據點、公司內部的 OPNsense 設定為 WireGuard 伺服器,並從 Windows PC 安全連線的實作步驟。 本文以「進入公司 LAN 或自宅 LAN」用途為前提,採用 分割通道 (split tunnel) 配置。步驟架構 遵循 OPNsense 官方的 WireGuard Road Warrior Setup 與 WireGuard 一般說明、Windows 官方安裝程式指南。[1][2][4] 預估時間:20〜30 分鐘 更新日期:2026-03-13 本文建立的配置 Windows 用戶端 ⇄ WireGuard 通道 ⇄ OPNsense 協定:WireGuard / UDP 用途:遠端存取 方針:分割通道 用戶端:官方 WireGuard for Windows Overview 概述與前提 OPNsense 的 WireGuard 是透過 Instance(伺服器端虛擬介面設定)與...

OPNsense 範本初次設定程序

Last Updated: 2026年6月9日

設定指南 OPNsense 範本 初次設定步驟 這是初次啟動後安全開始使用的步驟。先確定 WAN,在以 HTTPS 保護 WebGUI 的同時逐步進行設定。 WAN 優先設定HTTPS WebGUI僅在必要時使用 SSHLAN 可稍後新增 建議: 在完成首次 WebGUI 登入之前,為防止混淆 WAN / LAN,請僅保留 WAN 側 NIC 的狀態進行。 對象與前提 對象:提供的 OPNsense 範本 前提:最初配置的 NIC(vtnet0)將作為 WAN 使用 建議在完成首次 WebGUI 登入之前,為防止混淆 WAN / LAN,僅保留 WAN 側 NIC 的狀態進行 可根據需要稍後新增 NIC 以建立 LAN(雲端上的私有網路) 初次使用 HTTPS WebGUI 登入並進行設定 SSH 僅在必要時使用。本步驟中所有 SSH...

OpenWrt 初始設定步驟

Last Updated: 2026年6月9日

設定指南 所提供的 OpenWrt 範本 初次設定步驟 初次啟動後安全開始使用的步驟。先設定 WAN,並以 HTTPS 保護 LuCI,逐步進行配置。 WAN = eth0作業用LAN = eth1HTTPS GUI(LuCI)SSH 僅在必要時使用 對象與前提 對象:所提供的 OpenWrt 範本 WAN = eth0(設定全域IP的介面) 作業用LAN = eth1(DHCP / 主控台復原用網路) 初次使用 HTTPS GUI(LuCI)登入 SSH 僅在必要時使用(金鑰註冊後啟動 / 開放22,禁止密碼SSH) 重要事項(必讀) 本範本不支援 cloud-init,因此初次需要手動設定。 存取來源IP限制為必須(雲端防火牆 / SG 與 OpenWrt 防火牆雙方都必須將 443 / 22 限制為僅允許客戶的管理端IP) 設定錯誤會導致無法存取。作業期間請保持主控台開啟 主控台可能會被解釋為 US 鍵盤配置(特別是 / 或...

SSL憑證:更新・請求(請求書發行時機/付款期限/逾期處理)

Last Updated: 2026年6月9日

本頁面針對 BESTNET LLC 提供的網域名稱服務, 明確說明請款單的發行時機、付款期限、逾期的處理方式。 ※網域受註冊局/註冊商等第三方機構規則影響。最終的註冊可否、復原可否、期間以第三方規則為準。 ※時間基準原則上為日本時間(JST)。 1. 重點須知 網域的續約請款單原則上於有效期限前 30 天發行。 付款期限(請款單的到期日)原則上為網域的有效期限日。 註冊/續約/移轉等手續原則上於確認入帳後執行(未入帳時手續不會進行)。 逾付款期限後,網域將變為過期(Expired)狀態,網站/郵件等可能停止運作。 過期後的復原可否、期間、費用因 TLD 而異,也可能無法復原。 2. 名詞解釋(本頁面使用的詞彙) 有效期限(期限日):網域註冊的有效期限日(必須在此日期前完成續約)。 請款單(Invoice):在客戶入口網站發行的續約費用等付款請求資料。 付款期限(Due Date):請款單的到期日。原則上與「有效期限日」為同一日。 過期(Expired):超過有效期限的狀態。可能影響 DNS/郵件/網站運作。 復原期間(Grace/Redemption 等):過期後可透過額外手續、額外費用復原的可能期間(因 TLD 而異)。 3. 續約請款單的發行時機 續約請款單原則上於有效期限前 30 天自動發行。 3-1. 期限前通知(參考) 期限接近時,本公司將進行多次通知(例:30/15/10/5/1 天前)。 ※即使未收到郵件,客戶入口網站上的請款單、有效期限顯示為準。 3-2. 時程範例(有效期限為 6/30 的情況) 時期 本公司(客戶入口網站)的動作 客戶建議採取的行動 5/31(30 天前) 發行續約請款單/期限前通知(30 天前) 確認付款方式、儘早付款 6/15(15 天前) 期限前通知(15...

使用本地 LLM 自動分析基礎架構日誌的實作經驗

Last Updated: 2026年6月9日

2026.04 / Tech Blog / BASTION 使用本地 LLM 建置基礎設施日誌自動分析機制的實作經驗 防火牆、身份驗證基礎設施、交換器、負載平衡器、Web 伺服器的日誌每 15 分鐘由 AI 自動分析,偵測異常、判定嚴重程度、提出處置建議並通知至 Slack。日誌資料完全不對外傳送。 為什麼要做這個 契機很單純,就是沒有時間看日誌這個問題。 BESTNET-CLOUD 運行著多台防火牆、L2/L3 交換器、Windows AD、負載平衡器、Web 伺服器。每一個都會產生 syslog,但日常要讓人工目視確認所有日誌並不實際。雖然我們用 Zabbix 監控資源,但讀取 syslog 內容並判斷「這個攻擊模式可以放著不管還是應該處理」這部分仍然是人工作業。 AWS DevOps Agent(2026 年 3 月 GA)或 Azure Security Copilot 等公有雲端服務也推出了 AI 日誌分析服務。然而,這些主要針對雲端上的資源,並沒有直接解析和分析本地端實體設備 syslog 的功能。此外,由於日誌資料會傳送到雲端供應商的 AI 基礎設施,在有封閉網路需求的環境中無法使用。 既然如此,只能自己做了。幸運的是,本地運行的 LLM 效能已達到實用水準,所需的組件都有開源軟體可用。 整體架構 系統名稱為BASTION(堡壘)。取其城堡、最後防線之意,象徵在封閉環境中守護基礎設施的理念。 架構很簡單。 使用的組件如下。全部都是開源軟體或免費方案。 組件 功能 授權...

網域:續約・帳單(發行帳單時機/付款期限/逾期處理)

Last Updated: 2026年6月9日

本頁面針對 BESTNET LLC 提供的網域服務,就更新時的請款單發行時機、付款期限、逾期處理等重點進行整理說明。 1. 重要事項 網域的註冊、更新、轉移均依照上層註冊商/註冊局等第三方規則處理。當第三方規則與本公司顯示內容有所矛盾時,就該網域而言以第三方規則為優先。 本公司於「確認入帳後」執行註冊/更新/轉移等手續。(僅發行請款單並不代表更新已完成) 若在有效期限前無法確認入帳,將不會執行更新手續,網域將過期(失效)。過期後雖有可能復原,但無法保證,且可能產生額外費用。 註冊完成後,基於規格限制原則上無法因客戶因素取消/退款。 2. 用語說明 有效期限(期限):網域的有效期限日。可在入口網站的網域詳細資訊中確認。 更新請款單(更新發票):當有效期限接近時發行的更新費用請款單。 付款期限:原則上為「有效期限(更新期限)前」。若使用銀行轉帳,因反映需要時間,請預留充裕時間付款。 逾期(延遲):超過有效期限(付款期限)仍未入帳的狀態。 3. 請款單發行時機 3.1 新註冊・轉移的請款單 申請(訂購)時發行請款單。 信用卡/PayPal/Stripe等:訂購時確定付款。 銀行轉帳:需於申請日起3日內付款(若未入帳,可能視為取消申請)。 3.2 更新請款單(更新發票) 本公司標準設定為在有效期限前30日自動發行更新請款單。 4. 期限相關通知郵件(何時收到) 4.1 有效期限通知(網域通知郵件) 本公司標準設定為在有效期限前以下天數發送有效期限通知。 30日前 15日前 10日前 5日前 1日前 4.2 未付款請款單提醒(期限前) 若更新請款單維持未付款狀態,本公司標準設定為在付款期限前3日發送提醒郵件。 4.3 逾期提醒(期限後) 若超過付款期限,本公司標準設定為在逾期後以下天數發送提醒郵件。 1日後 3日後 7日後 注意:郵件通知僅為輔助,無論是否收到,客戶都需自行管理期限。請務必在入口網站上確認請款單・期限,包括垃圾郵件分類等情況。 5. 付款期限(何時前需付款) 5.1 信用卡/PayPal/Stripe等 新申請:訂購時確定付款。 更新:請於更新請款單的付款期限(有效期限)前完成付款。 5.2 銀行轉帳 新申請:請於申請日起3日內付款。...

在 Ubuntu 24.04 上嘗試安裝 OpenClaw

Last Updated: 2026年6月9日

Infrastructure / Self-hosted AI Agent 在 Ubuntu 24.04 上安裝 OpenClaw 繼 Windows Server 2019、Windows 11 之後,這次驗證了在 Ubuntu 24.04 上安裝 OpenClaw。 Linux 原生環境是官方支援對象,與 Windows 環境相比大幅簡化。 但是遠端儀表板存取需要裝置配對核准這個陷阱。 包含該步驟在內的所有記錄公開如下。 OpenClaw Ubuntu 24.04 Linux nginx HTTPS GPUStack與前一篇文章的關係 本文是「Windows Server 2019」「Windows 11」OpenClaw 安裝記錄的續篇。 在 Windows 環境中遇到的 PATH 問題、npm 錯誤、NODE_OPTIONS 問題在 Ubuntu 上完全沒有發生。 環境配置 OpenClaw 主機 Ubuntu 24.04 LTS OpenClaw v2026.4.10(npm...

在 Windows 11 上嘗試原生安裝 OpenClaw

Last Updated: 2026年6月9日

Infrastructure / Self-hosted AI Agent 在 Windows 11 上原生安裝 OpenClaw 我們之前驗證過在 Windows Server 2019 上原生安裝 OpenClaw。 這次我們在 Windows 11 上嘗試相同的原生路徑。 在 Server 2019 上遇到的種種障礙是否會在 Windows 11 上重現, 還是能順利執行——我們公開這次的驗證記錄。 OpenClaw Windows 11 原生安裝 pnpm GPUStack Self-hosted AI與前篇文章的關係 本文是「在 Windows Server 2019 上安裝 OpenClaw(完整版)」的續篇。 關於 Server 2019 的驗證內容請參考該文。 為什麼選擇原生路徑而非 WSL2 在 Windows 11 上,只需一行 wsl --install 就能執行...

解決 V100 上 pipeline_parallel=2 當機問題

Last Updated: 2026年6月9日

  Tech BlogGPUStackvLLMTesla V100Multi-Node GPU 叢集運作備忘 解決 pipeline_parallel=2 在 V100 上當機的問題達成 tensor_parallel=4 + 64K 上下文穩定運作 在使用 GPUStack v2.1.1 + vLLM 0.17.1 於多節點(Tesla V100×4 張)上執行 Qwen2.5-14B-Instruct 時,每次發送聊天訊息都會出現 _TorchTensorAcceleratorChannel 的 AttributeError 導致當機。原因在於 pipeline_parallel 與 V100 不相容。變更為 tensor_parallel=4 / pipeline_parallel=1 後根本解決,並進一步將上下文長度擴充至 64K 的記錄。 AI-GPUST01: GPU-Worker-A / Tesla V100×2  |  AI-GPUST02: GPU-Worker-B / Tesla V100×2  |  GPUStack v2.1.1 /...

在不推薦的環境中嘗試運行:在 Windows Server 2019 上安裝 OpenClaw

Last Updated: 2026年6月9日

在不推薦環境中嘗試運行:在 Windows Server 2019 上安裝 OpenClaw(完整版) Infrastructure / Self-hosted AI Agent 在不推薦環境中嘗試運行:在 Windows Server 2019 上安裝 OpenClaw(完整版) OpenClaw 官方推薦使用 WSL2,但 Windows Server 2019 不支援 WSL2。 即便如此,我們沒有放棄,改以原生 Windows 路徑嘗試運行, 克服了 WSL 的限制、npm 的已知錯誤、模組缺失、與 GPUStack 的連接問題、工作階段損壞等 多達兩位數的障礙,最終成功啟動儀表板並完成對話。 為了幫助在相同環境下嘗試的使用者,本文公開完整步驟(包含所有踩坑點)以及建立的營運支援工具。 OpenClaw Windows Server 2019 Node.js pnpm GPUStack vLLM Self-hosted AI 免責聲明 Windows Server 2019 不在 OpenClaw 官方支援範圍內。 本文不保證運作正常,僅作為驗證目的之紀錄公開。 不建議用於正式環境。...

GPUStack v2.1.1 徹底解決多節點推論無法啟動的所有問題

Last Updated: 2026年6月9日

Tech Blog GPUStack Multi-Node vLLM Tesla V100 TroubleshootingGPU 叢集營運筆記 GPUStack v2.1.1 多節點推論無法啟動問題全解決記錄 2節點4×V100 執行 Qwen2.5-32B 的完整記錄 GPUStack v2.1.1 + vLLM 後端,使用2台 GPU 工作節點(各 Tesla V100-PCIE-32GB × 2張)進行多節點分散式推論時,接連發生不同問題。從 Ray 的叢集連接失敗、Gloo 的通訊錯誤、/dev/shm 不足,到 V100 特定的 CUDA 核心錯誤,本文按時序記錄所有故障排除與解決方案。 GPU-Worker-A: / Tesla V100×2 | GPU-Worker-B: / Tesla V100×2 | GPU-Server: GPUStack Server | GPUStack v2.1.1 / vLLM 0.17.1 /...

從 Dify v1.9.2 升級至 v1.13.3 的進行方式與容易遇到的問題

Last Updated: 2026年6月9日

基礎架構 / 自行託管 AI 平台 將 Dify 從 v1.9.2 升級至 v1.13.3 的進行方式與常見問題 自行託管的 Dify 升級難度,會隨著舊有 docker-compose.yaml 的自訂調整程度而提高。 本次整理了使用 Docker Compose 營運的 Dify 從 v1.9.2 更新至 v1.13.3 的進行方式, 並針對公開發布將敏感資訊進行遮罩處理。 相較於單純更新 image tag,以官方 compose 為基礎進行替換,再還原環境相依設定的方針最為安全。 Dify Docker Compose Weaviate Self-hosted Upgrade Masked for Public 公開發布注意事項 本文中的網域、電子郵件地址、API 金鑰、認證資訊、憑證路徑、主機名稱、磁碟區配置的部分內容, 為避免實際環境被特定,已進行遮罩或抽象化處理。 Before 更新前的配置 Dify v1.9.2 基礎 使用 Docker Compose 營運...

使用 10G 私有網路連接 Bestnet Cloud × GPU-VPS,<br>實作 GPUStack 叢集的步驟

Last Updated: 2026年6月9日

How-to BESTNET-CLOUD GPU-VPS GPUStack 10G Private Network NFS Shared CacheTech Blog / Infrastructure Build Guide 將 Bestnet Cloud × GPU-VPS 透過 10G 私有網路連接, 實作 GPUStack 叢集的步驟 以 Bestnet Cloud 作為控制平面,GPU-VPS 作為推論 Worker 的分離架構, 透過共享 NFS 快取統一管理模型檔案的配置。 從客戶入口網站端的準備工作到 Ubuntu 上的實作、運行確認,整理成操作指南文章。 Ubuntu 24 / GPUStack 0.6.x 系統的實際初期建置範例10G Private Link1 次 模型下載2 台+ GPU Worker1 處 共享模型儲存位置 Scope...

切換至 BESTNET DNS 服務

Last Updated: 2026年6月9日

DNS SERVICE 遷移指南 概述 本操作手冊說明在本公司客戶入口網站(BESTNET-CLOUD)上,如何從 標準網域註冊商提供的 DNS(例如:dns*.name-services.com)切換至 本公司 DNS 服務(例如:dns*.cloudns.net)的操作步驟。 切換作業主要由以下 2 個階段組成。 階段 1 DNS 記錄遷移 將現有的 A / CNAME / MX / TXT 等記錄匯入本公司 DNS 服務。 階段 2 名稱伺服器切換 從註冊商的標準 DNS 變更為本公司 DNS 服務的名稱伺服器。 重要 建議順序 依照步驟 4(記錄遷移)→ 步驟 3(NS 切換)的順序執行較為安全。 重要事項 切換名稱伺服器(NS)的瞬間,參照的 DNS 將會立即改為本公司 DNS 服務。若切換時必要的 DNS 記錄尚未齊全,網站 / 郵件 / 各項驗證將會立即受到影響。...

Whois保護的管理

Last Updated: 2026年6月9日

網域管理指南 本程序說明如何在客戶入口網站上 開啟/關閉網域的 WHOIS 保護(WHOIS 隱私)。 概述 啟用 WHOIS 保護(隱私)後,WHOIS 資訊中顯示的註冊者資訊 (姓名、地址、電子郵件等)將被替換為註冊商的隱私資訊 (或不顯示),從而可以抑制個人資訊的公開。 前提條件 已登入客戶入口網站 可以開啟目標網域的「網域詳細資料」畫面 目標網域可使用 WHOIS 保護(隱私)選項 (根據 TLD 或合約內容,可能不會顯示或提供) 操作步驟 1 在目標網域的「網域詳細資料」畫面中開啟「管理隱私」 開啟目標網域的「網域詳細資料」畫面, 點擊左側選單的「管理隱私」。 點擊左側選單的「管理隱私」。 2 確認「隱私保護」的目前值 在畫面下方的「隱私保護」下拉式選單中, 確認目前的設定(例如:關閉)。 確認目前的設定狀態。 3 從下拉式選單中選擇「開啟」或「關閉」 點擊下拉式選單,從顯示的選項中選擇所需的狀態 (開啟 或 關閉)。 從下拉式選單中選擇所需的設定。 補充說明:紅框為範例,顯示點擊並選擇「開啟」的狀態。 4 點擊「儲存變更」以套用 變更設定後,點擊「儲存變更」。 變更設定後點擊「儲存變更」。 注意: 點擊後,畫面可能會進入載入中狀態(顯示轉圈圖示)。 請勿關閉頁面,等待完成。 5 確認設定已套用 儲存後,確認隱私保護的顯示為所需的狀態 (例如:開啟)。 確認儲存後設定已套用。 補充說明 反映至...

關於請求書操作、開立時機、付款期限

Last Updated: 2026年6月9日

Billing Guide 請求書(Invoice)的確認・支付・PDF保存/列印 這是一份關於客戶入口網站中請求書的基本操作,以及請求書發行時機、支付期限(Due date)概念的指南。 請求書確認Pay NowPDF保存Due date ※ 畫面顯示與選單名稱可能會因您的合約方案或權限而有所不同。 ※ 網域・SSL憑證的續約/請款規則不同。詳情請參閱網域・SSL憑證的續約及請款相關說明。 1. 請求書的確認與支付 在客戶入口網站中,您可以一併進行請求書的確認、支付及PDF保存(列印)。請求書會在服務續約(計費週期更新)或方案變更等時機自動發行。請於支付期限(Due date)前完成支付。 ※ 網域・SSL憑證的續約/請款可能與上述不同。詳情請參閱上述連結。 1-1確認請求書 請求書以「未支付(Unpaid)」「已支付(Paid)」等狀態進行管理。開啟目標請求書後,可以確認支付期限(Due date)、請款金額、明細(對象服務・期間・選項等)。續約月份或進行方案變更的月份,明細項目可能會比平常更多。 從選單開啟「請款(Billing)」→「請求書(Invoices)」。 從列表中選擇目標請求書。 確認狀態(未支付 / 已支付)、支付期限、金額及明細。 1-2支付請求書 開啟未支付的請求書,從「支付(Pay Now)」進行結帳。結帳方式會依您的合約內容而異(信用卡、PayPal、銀行轉帳等)。結帳完成後,請求書狀態會更新為「已支付(Paid)」。 如果支付後狀態仍未切換,可能是結帳反映需要時間,請稍候片刻後重新整理頁面。 在目標請求書畫面選擇「支付(Pay Now)」。 選擇結帳方式,並依照指示完成支付。 支付後,確認請求書狀態已變更為「已支付(Paid)」。 1-3下載請求書PDF/收據 請求書可以PDF格式保存,可用於公司內部報帳或帳簿保管。如果顯示「PDF」「Download」「Print」等按鈕,可從該處下載或列印。 ※ 收據的顯示有無及處理方式(與請求書相同 / 分開顯示)可能會因支付方式或設定而有所不同。 開啟請求書畫面。 從「PDF」「Download」「Print」等按鈕進行保存 / 列印。 1-4請求書的發行時機與支付期限(Due date) 本公司為了防止遺漏支付,同時避免未支付狀態長期化,會分階段發行請求書並發送提醒通知。支付期限(Due date)是「支付截止日」。請配合於期限前完成支付。 若持續未支付,服務可能會被暫停(suspend)或自動終止(解約處理)。 -7日請求書會在支付期限的7日前自動生成。當日支付期限當日可能會發送提醒。+3 / 6 / 9日超過支付期限後,會在3日後 /...

手動更新服務

Last Updated: 2026年6月9日

服務續約指南 客戶入口網站提供「手動續約服務」功能,可讓您 在任意時間點提前發行服務續約帳單(續約用發票)。 概述 客戶入口網站提供「手動續約服務」功能,可讓您 在任意時間點提前發行服務續約帳單(續約用發票)。 此操作執行的內容 執行此操作後,目標服務的 下次帳單日期將更新為「今日」, 並發行續約帳單。 前提條件 已登入客戶入口網站 持有需要續約的服務 具有發行及支付續約帳單的權限(依合約與權限設定而異) 操作步驟 1在服務頁面開啟「手動續約服務」 開啟客戶入口網站的服務頁面。 點選服務選單中的 「手動續約服務」。 2點選「立即續約」 顯示「手動續約服務」頁面。 點選頁面中的 「立即續約」 按鈕。 3在確認對話框點選「OK」 顯示確認對話框後,確認內容。 若沒有問題請點選 「OK」(若要取消請點選「取消」)。 4確認已發行的帳單,並視需要進行付款 續約帳單發行後,將跳轉至帳單頁面。 畫面右上方會顯示 「已發行新帳單」。 確認內容後,若要立即結帳請點選 「立即付款!」。 注意事項 畫面顯示(帳單編號、金額、按鈕顯示等)可能因您的合約內容、設定、語言而有所不同。 若誤操作執行或對帳單內容有疑問,請開啟工單。

從範本建立伺服器

Last Updated: 2026年6月9日

概述 在客戶入口網站(畫面範例:BESTNET-CLOUD)中,使用現有的範本來 建立新伺服器(虛擬機)的步驟。 請確認: 本手冊使用生成式AI等工具製作,因此畫面截圖內的註解(箭頭、框線、編號等)位置, 可能與實際畫面稍有偏差。操作時,請以實際畫面顯示與文字內容為準。 事前準備 能夠登入客戶入口網站 要使用的範本(例:Private 下的範本)已建立完成,且擁有使用權限 若要使用SSH金鑰登入,請事先註冊SSH金鑰(可從畫面的「SSH金鑰管理」進行註冊) 步驟 1. 開啟「新增伺服器」 開啟客戶入口網站的「伺服器清單(執行個體清單)」。 點擊左側選單內的「新增伺服器」。 圖1. 點擊「新增伺服器」 2. 輸入主機名稱與密碼 輸入主機名稱(例:DEMO-HOST)。 輸入密碼。 密碼請設定為不易被第三方猜測的內容。 圖2. 1) 主機名稱 2) 輸入密碼 3. 選擇SSH金鑰 點擊「SSH金鑰」,選擇已註冊的金鑰(例:SSH_ONE)。 若無法選擇SSH金鑰,請先從「SSH金鑰管理」註冊金鑰。 圖3. 選擇SSH金鑰 4. 選擇範本 點擊「OS範本」。 從清單中選擇顯示在 Private 下的範本(例:DEMO-HOST_Template)。 若要從範本建立,請選擇Private 的範本,而非 ISO(Community)。 圖4. 選擇Private下的範本 5. 設定資源與網路 設定CPU核心。 設定RAM。 設定磁碟容量。 選擇「Interface net0」的IPv4 Pool(例:Public IP(s))。 根據需求設定Number...

帳戶點數使用規定

Last Updated: 2026年6月9日

制定日:2026年1月11日 適用開始日:2026年1月14日 最終更新日:2026年02月17日 第1條(目的) 本規定旨在規範BESTNET LLC(以下簡稱「本公司」)所提供之託管服務及其附屬服務(以下簡稱「本服務」)中,帳戶餘額(以下簡稱「餘額」)之授予、使用、充當、調整、失效、退款(最終結算)及其他處理事項。 本規定未規定之事項,應遵循本公司之共通使用條款、個別條件、價格表、本公司另行訂定之政策及法令等規定。 第2條(定義) 本規定使用之用語定義如下: 餘額:記錄於客戶帳戶中之金額相當額,可於本公司規定之範圍內充當本服務費用之餘額。 客戶:依本公司指定方式完成本服務使用登記,並經本公司核准者。 入金型餘額:客戶為充作未來費用支付之目的,自願向本公司支付資金,經本公司加算至客戶帳戶之餘額(包含「儲值」、「資金追加」等)。 退款型餘額:本公司作為退款手段而授予客戶帳戶之餘額(包含錯誤請款之更正、重複支付之結算、未提供部分之結算等)。 無償餘額:本公司基於促銷、補償、優惠等目的而無償授予之餘額。 優惠券等來源餘額:透過優惠券、代金券、活動代碼等兌換而授予之餘額。 服務餘額:本公司因SLA違反等補償而授予之餘額。服務餘額原則上包含於無償餘額中(除個別條件另有規定外)。 最終結算:客戶終止使用本服務時,僅限本公司認可之情形下,依本公司指定方式進行之餘額結算程序(第10條)。 第3條(餘額之性質) 餘額係用於充當本服務費用之支付,不得兌換為現金、電子貨幣、加密資產或其他價值。但本規定第10條規定之最終結算且本公司同意退款之情形除外。 餘額不產生利息。 餘額除本公司另行許可外,不得向第三方轉讓、借予、設定擔保、變現或為其他處分。 第4條(餘額之授予・加算) 本公司得因下列事由授予・加算餘額: 客戶自願支付資金之情形(入金型餘額) 本公司選擇以餘額授予方式進行退款・結算之情形(退款型餘額) 優惠券等之兌換(優惠券等來源餘額) 本公司判斷而無償授予(含無償餘額、服務餘額) 本公司認為合理必要之其他調整(錯誤更正等) 本公司於授予・加算餘額時,得進行身分確認、支付審查、交易審查、使用限制及其他必要措施。 本公司得基於系統或營運上之需要,訂定或變更入金型餘額之受理條件(對象、上限、方式等)。 第5條(餘額之使用範圍) 客戶得依本公司指定之方式,將餘額充當本服務之使用費、續約費、選購項目費及本公司指定之其他費用支付。 本公司得針對下列費用限制或禁止使用餘額充當: 已向第三方支付之實際費用、不可退款之費用(例:註冊機構費用等) 基於防範詐欺之考量,須使用特定支付方式之交易 依法令、支付機構或本公司方針受限制之交易 客戶同意,使用餘額支付之交易如發生取消・退款時,本公司得以合理適當之方式(退回餘額、退還原支付方式或其他方式)進行結算。但法令或支付機構規定限制退款方式時,應依其規定辦理。 第6條(餘額之充當方法・充當順序) 本公司得對請款(發票)自動充當餘額,或依本公司指定程序以人工方式充當。 餘額之充當順序依本公司另行訂定。原則上依下列順序充當: 退款型餘額 入金型餘額 無償餘額/優惠券等來源餘額(有期限者優先充當期限較近者) 本公司得基於請款性質、會計處理、防範詐欺等觀點,於合理範圍內變更前項順序。 第7條(有效期限・失效) 入金型餘額及退款型餘額,除本公司另有規定外,不設有效期限。 無償餘額、優惠券等來源餘額、服務餘額,得適用本公司另行訂定之有效期限。 客戶如有違反使用條款、詐欺行為或有合理詐欺疑慮時,本公司得為調查目的而停止餘額使用,或使無償餘額等失效。 第8條(轉讓・合併・移轉) 餘額僅歸屬於客戶本人之帳戶,不得向第三方轉讓、於帳戶間移轉、變更名義或合併。但本公司特別認可時不在此限。 客戶如對本公司負有未償債務,本公司得於合理範圍內以餘額進行抵銷。 第9條(錯誤授予・調整) 本公司如發現因系統故障、人為疏失、詐欺行為或其他事由而錯誤授予・減算・充當餘額時,得依本公司裁量於合理範圍內進行更正(追加、減算、取消、重新計算等)。 因前項更正而導致客戶產生不足金額時,本公司得請求該不足金額。 第10條(退款・最終結算)...

建立新伺服器

Last Updated: 2026年6月9日

概述 從客戶入口網站建立新伺服器(虛擬機器)的步驟。 本步驟選擇 ISO 來建立。選擇 ISO 時,建立後需要從主控台安裝作業系統。 補充說明: 如果選擇作業系統範本,可以在幾分鐘內開始使用已完成基本設定的伺服器。無需像 ISO 那樣手動安裝。 請確認: 本操作手冊是利用生成式 AI 等工具製作,因此畫面截圖內的註解(箭頭、框線、編號等)位置可能與實際畫面略有偏差。操作時請以畫面顯示或文字內容為準進行確認。 事前準備 能夠登入客戶入口網站 服務狀態為 啟用中 (建議)事先註冊 SSH 金鑰 建立新伺服器的步驟(使用 ISO) 1. 開啟 BESTNET-CLOUD 服務 在「儀表板」> 「我的服務」中選擇 BESTNET-CLOUD 分頁。 點擊目標服務列右端的箭頭(→)移至管理畫面。 ① 選擇 BESTNET-CLOUD 分頁 → ② 點擊右端箭頭 2. 開啟「新增伺服器」 點擊實例列表中顯示的 「新增伺服器」。 點擊「新增伺服器」 3. 輸入主機名稱和密碼 主機名稱:輸入任意的伺服器名稱(例:DEMO-HOST)。 密碼:設定初始使用者(root)的密碼。 為了安全起見,請設定足夠長度且難以猜測的密碼。 ① 主機名稱 → ② 密碼...

團隊管理

Last Updated: 2026年6月9日

概要 本文件說明客戶入口網站中 Teams(團隊)管理的基本操作步驟。 建立團隊、設定與團隊關聯的聯絡人(Contacts)和權限(特權 / Privileges), 並使用邀請碼(Invite Code)邀請成員。 本手冊使用生成式AI等工具協助製作,畫面截圖中的註解(箭頭、框線、編號等)位置可能與實際畫面略有偏差。 本手冊旨在幫助理解操作意圖,實際操作時請以畫面顯示與文字內容為準。 事前準備 可登入客戶入口網站的帳號(管理員或具有建立團隊權限的帳號)。 已建立欲加入團隊的聯絡人(Contacts)(若尚未建立,請於「聯絡人」畫面使用新增功能建立)。 操作步驟 1. 開啟「聯絡人管理」 點選左側選單的[聯絡人管理]。 2. 切換至「Teams」分頁 顯示聯絡人清單畫面後,點選上方分頁的[Teams]。 3. 新增團隊 點選Teams畫面右上方的[新增團隊]。 4. 輸入團隊基本資訊 名稱:輸入團隊名稱(例:開發團隊、會計團隊等)。 說明:輸入補充說明以便了解用途(選填)。 5. 將Contacts(聯絡人)加入團隊 點選Contacts欄位,搜尋欲新增的聯絡人。 從候選清單中點選該聯絡人以新增(可複選)。 補充說明: 將顯示已註冊的聯絡人候選清單。若找不到,可能是尚未建立該聯絡人。 6. 設定權限(特權 / Privileges) 在畫面下方的特權區塊設定授予團隊的權限。 建議先從預設特權(預設組)選擇,可快速設定所需權限。 視需要個別勾選或取消勾選核取方塊以微調權限。 無:最低限度(僅授予個別必要權限時使用) 會計:主要授予帳務與付款相關操作權限 完整權限:允許所有(或大部分)操作 技術人員:主要授予客服支援與技術作業所需操作權限 7. 儲存變更並建立團隊 輸入與設定完成後,點選[儲存變更]。 儲存後將自動轉至團隊詳細資訊畫面(視環境而定顯示可能有所不同)。 8. 分享Invite Code(邀請碼)以邀請成員 確認團隊詳細資訊畫面中的Invite Code。 點選右側的複製圖示以複製邀請碼。 將複製的邀請碼分享給希望加入的成員(如透過公司內部通訊軟體等)。...

子使用者管理

Last Updated: 2026年6月9日

概要 本手冊說明如何在客戶入口網站上 「新增、設定權限、編輯及刪除子使用者(聯絡人)」 。 請確認: 本手冊是運用生成式 AI 等技術製作,因此畫面截圖中的標註(箭頭、框線、編號等)位置, 可能與實際畫面略有偏差。操作時請以畫面顯示內容及文字說明為準。 什麼是子使用者(聯絡人) 子使用者是以主帳戶的「聯絡人(Contact)」身分建立, 僅授予必要的操作權限以允許使用入口網站的使用者。 事前條件 已使用主帳戶登入客戶入口網站 已事先準備好要註冊為子使用者的電子郵件地址 新增子使用者 1. 開啟聯絡人(子使用者)管理畫面 點選左側選單的 [帳戶]→[管理聯絡人]。 從[管理聯絡人]移至子使用者管理畫面。 2. 選擇新增方式(新增 / 邀請) 從聯絡人畫面右上方,根據用途選擇新增方式。 [新增聯絡人]:管理員當場設定使用者資訊、密碼及權限後建立。 [邀請使用者]:適合透過發送邀請郵件,由使用者端完成註冊的運作方式(顯示內容可能因環境設定而異)。 從右上方按鈕執行聯絡人(子使用者)的新增或邀請。 3. 輸入子使用者的基本資訊 點選[新增聯絡人]。 輸入必填項目(姓名、電子郵件地址、密碼等)。 視需要啟用 [要通知聯絡人嗎?](通知內容可能因環境設定而異)。 電子郵件地址與密碼將成為子使用者的登入資訊。 權限(Privileges)設定 1. 選擇權限範本 在「特權」區段中,可透過選擇範本(例如:無/會計/完整權限/技術人員) 一次性授予常用的權限組合。 選擇範本後,視需要調整個別權限勾選。 2. 調整個別權限 建議以 最小權限 為基礎,僅授予必要的操作權限。 對於「變更主要設定檔詳細資料」等會影響整個帳戶的權限,請特別注意授予範圍。 3. 設定服務(合約)單位的權限 可針對每個訂購中的服務,控制允許的操作 (例如:Power Management、Rebuild、VNC Console 等)。...

案例

Last Updated: 2026年6月9日

準備中

客戶入口網站安全設定

Last Updated: 2026年6月9日

安全設定指南 本手冊彙整了在客戶入口網站中進行安全相關設定 (多因素驗證、允許的IP存取)的操作步驟。 概要 在客戶入口網站中,透過設定多因素驗證(MFA)與 允許的IP存取, 可以強化帳號的安全性。 事前準備 可登入客戶入口網站的帳號 若要設定多因素驗證,需準備以下其中之一 智慧型手機(Google Authenticator / Authy 等驗證應用程式) 已註冊電子郵件地址的接收環境(使用Email MFA時) 1. 開啟安全設定畫面 1從左側選單開啟「安全」 登入客戶入口網站。 點選左側選單的「安全」。 2. 設定多因素驗證 2開啟「多因素驗證」分頁 從安全畫面上方的分頁選擇 「多因素驗證」。 在「多因素驗證」畫面中,會顯示可用的方式 (例:Google Authenticator / Email MFA)。 2.1啟用Google Authenticator 點選「Google Authenticator」框內的「啟用」。 使用驗證應用程式掃描顯示的QR碼(或手動輸入密鑰)。 點選畫面上的「繼續」。 若之後顯示確認碼輸入畫面,請輸入驗證應用程式顯示的一次性密碼即可完成(請依照畫面指示操作)。 2.2啟用Email MFA 點選「Email MFA」框內的「啟用」。 點選「Send one-time code via Email」(或重新傳送)以透過電子郵件接收確認碼。 在「One-time code」中輸入收到的確認碼,然後點選「送出」。 3. 設定允許的IP存取(IP限制) 3.1新增允許的IP/範圍 「允許的IP存取」是...

基於特定商業交易法的標示

Last Updated: 2026年6月9日

基於特定商取引法之標示(特定商取引法に基づく表示) 【銷售事業者】 ベストネット合同会社 【營運統籌責任人】 代表社員 珍田 秀幸 【所在地】 〒989-4302 宮城県大崎市田尻大貫字北長根161-1 【電話號碼】 0229-25-8716 技術支援僅透過客戶入口網站的工單受理。除個別合約情況外,不提供電話支援服務。 ※受理時間:平日10:00〜17:00(國定假日、年末年初除外) ※諮詢事項,基於記錄保存之考量,建議透過表單/電子郵件聯繫。 【電子郵件地址】 info@bestnetllc.co.jp 【銷售URL】 https://bestnetllc.co.jp 【客戶入口網站(申請・合約管理・請款・支援)】 https://hb.bestnetllc.co.jp 【銷售價格(服務對價)】 於各服務/各方案的申請畫面・價目表中顯示。 (例:月費/年費/時數計費、初期費用、選購項目費用等) ※顯示價格原則上為未稅價格,若有其他標示方式則於申請畫面中明示。 【商品價格以外所需費用】 ・網際網路連線費用、通訊費(由客戶負擔) ・銀行轉帳情況:轉帳手續費(由客戶負擔) ・網域/SSL等,因註冊局/認證機構等之規定可能產生額外費用(於申請畫面中明示) ・整合服務/現場作業等:可能產生交通費・住宿費・入館費等實際費用(事前估價或個別合約中明示) 【付款方式】 請依申請畫面顯示之方式付款。 (例:銀行轉帳、PayPal、Stripe等 ※依服務而異) 【付款時期】 ・信用卡/PayPal/Stripe等:訂購(申請)時確定結帳。 ・銀行轉帳:申請日起3日內,續約請款於續約日(期限)前付款。期限內未確認入帳時,可能視為取消申請。 ・月費/年費等持續計費(訂閱制)情況:於續約日自動結帳(或續約請款)。續約前解約時,不進行下次以後之請款。 【服務提供時期(交付時期)】 ■雲端/VPS/GPU‑VPS/Reseller等(客戶入口網站提供服務) 確認結帳後,原則上於數分鐘〜1個工作日內以可開始使用之狀態提供。 (需審查時、繁忙時、依設定內容提供可能延遲) ■網域註冊/移轉/續約・SSL憑證 確認結帳後,原則上開始進行手續。因外部機構(註冊局/註冊商/認證機構等)之處理,提供完成可能需時。 ■整合服務/導入支援/個別開發/諮詢顧問等(個別案件) 遵循個別估價・個別合約(NDA/業務委託合約等)所定之交期・實施日。 【提供方式(交付方式)】 ・透過客戶入口網站提供、電子郵件通知、或本公司指定之方式 ・整合服務/現場作業等:現場對應、線上會議、成果物之電子交付等(遵循個別合約) 【申請有效期限】 ・選擇銀行轉帳情況:請於申請日起3日內付款。 ・附估價之服務:估價單上有有效期限規定時,依其規定。 【銷售數量限制・提供條件】 ・GPU‑VPS等部分服務,因庫存/設備狀況等提供數量有限制。 ・各方案之上限(CPU/記憶體/頻寬/儲存空間等)及使用限制,遵循申請畫面・規格頁面・使用條款。 【解約・取消(申請之撤回/解除)】...

虛擬機擴充規格

Last Updated: 2026年6月9日

概述 說明如何升級現有 VPS 合約的資源(例如:RAM、磁碟容量)。 本流程是從服務詳細資訊畫面的 More 選單執行 升級。 前提條件 能夠登入客戶入口網站 目標 VPS(服務)處於「有效(啟用)」狀態 可使用付款方式(銀行轉帳 / 信用卡等) 操作步驟 1. 開啟 VPS 詳細資訊畫面並顯示 More 選單 從左側選單的 服務 開啟目標 VPS 的詳細資訊畫面。 點選畫面右上角的 More。 2. 選擇「升級」 從 More 選單點選 升級。 3. 選擇要升級的資源 開啟「資源升級」畫面。調整想要升級項目的滑桿。 RAM [GB]:例如從 16 增加到 24 Disk Size:視需要增加 其他如備份保留世代數、快照、額外 IP 等,依環境需求選擇 4. 點選「繼續」 點選頁面下方(或相關區塊右側)的 繼續。 5. 選擇付款方式 顯示升級內容和帳單金額。選擇要使用的付款方式。...

隱私權政策

Last Updated: 2026年6月9日

第1條(適用範圍及優先關係) 本政策適用於本公司在提供本網站及本服務相關之取得、使用、保管、提供及其他處理(Processing)個人資料等之作業。 本公司就本服務另行訂定有關隱私或資訊管理之規定、聲明(包括使用條款、個別畫面上之聲明、指南等)時,該規定、聲明應補充本政策,如有牴觸,以該規定、聲明為優先。 本公司就與本服務相關之整合服務、導入支援、個別開發、顧問諮詢或其他個別專案,與客戶簽訂保密協議(NDA)或其他個別契約(以下稱「個別契約」)時,如該個別契約就個人資料等或機密資訊之處理另有規定,則該規定優先於本政策適用。 縱有前項規定,該個別契約不得免除或限制本公司依適用法規(包括GDPR)所負義務或資料主體(Data Subject)之權利,但適用法規允許之範圍不在此限。 第2條(用語定義) 本政策使用之主要用語定義如下。 「個人資訊」:指個人資訊保護相關法律及其他法令所稱之個人資訊。 「個人資料(Personal Data)」:指GDPR所稱之個人資料,或構成個人資訊資料庫等之個人資訊。 「處理(Processing)」:指取得、記錄、編輯、保管、使用、提供、消除及其他一切處理行為。 「資料主體(Data Subject)」:指可由個人資料識別之個人。 「管理者(Controller)」及「處理者(Processor)」:指GDPR所定義之管理者及處理者。 「Cookie等」:指Cookie、廣告識別碼、裝置識別碼及其他使用類似技術所取得之資訊。 「使用日誌」:指存取日誌、IP位址、瀏覽器資訊、操作歷程、認證及安全日誌及其他因使用本服務等而自動產生、累積之記錄。 第3條(本公司立場:管理者/處理者) 本公司原則上就本公司之客戶管理、計費、支援、行銷、本網站營運等相關之個人資料等,以**管理者(Controller)**身分處理。 另一方面,就客戶於雲/VPS等儲存、處理之資料(可能包含客戶自終端使用者等取得之個人資料,以下稱「客戶內容」),本公司因維護、營運支援或其他目的而處理時,本公司得依契約內容以**處理者(Processor)**身分處理。此情況下,本公司將依個別契約(包括DPA等)及客戶合理指示進行處理。 第4條(取得之個人資料等) 本公司於提供本服務時,可能取得以下個人資料等。 帳戶・契約資訊:姓名(包括負責人姓名)、公司名稱、部門名稱、地址、電話號碼、電子郵件地址、登入ID、認證資訊、契約內容等 計費・付款資訊:帳單地址資訊、交易ID、付款狀態、發票・收據資訊等 使用支付代行服務時,本公司可能不保存信用卡號等資訊。 支援相關資訊:詢問內容、工單內容、處理歷程、通訊內容、障礙處理所需範圍之設定資訊・日誌等 技術資訊・使用記錄:IP 位址、存取日期時間、終端裝置/瀏覽器資訊、作業系統資訊、瀏覽頁面、參照來源、認證・安全記錄、操作歷程、Cookie 等 網域/SSL 相關資訊(提供時):註冊者資訊、WHOIS 相關資訊、DNS 設定資訊、憑證申請資訊(網域所有權驗證資訊、組織資訊等) 防範不當使用資訊:偵測不當訂單・未經授權存取等所需資訊(交易相關資訊、記錄、識別碼等) 行銷相關資訊(實施時):電子郵件發送的同意/停止狀態、問卷回覆、活動報名資訊等 其他:本公司於本服務申請畫面、設定畫面等指定之資訊 第5條(使用目的) 本公司將所取得之個人資料等用於下列目的。 本服務之提供、帳戶管理、合約履行、身分驗證(實施時) 使用費用之請款、結算、入帳確認、退款處理、會計・稅務處理 服務營運(監控、故障處理、安全性對策、備份、維護等) 諮詢處理、提供支援、重要通知(規約變更、故障聯絡等)之通知 網域註冊/移轉/續約、DNS 管理、SSL 憑證申請・發行・更新等手續 防範不當使用、處理違反使用規約行為、權利保護、爭議處理 本服務之改善、新功能開發、使用狀況分析、統計資料製作(包含以無法識別個人之形式進行之情況) 活動、電子報等資訊 第6條(GDPR 處理之法律依據) 本公司處理 EEA/英國等資料當事人之個人資料時,主要基於下列法律依據進行處理。 履行合約(Contract):本服務提供、帳戶管理、支援處理等 遵守法律義務(Legal Obligation):會計・稅務、基於法令之處理等...

雲資源升級

Last Updated: 2026年6月9日

Client Portal Guide 雲端服務的資源變更流程 本指南說明如何在客戶入口網站上,對已簽約的雲端服務資源(CPU 核心數、記憶體、NVMe SSD、備份保留代數、快照上限等)進行升級(增強)/降級(縮減)的操作流程。 升級降級點數退款資源變更 說明: 本操作手冊係利用生成式 AI 等工具製作,畫面截圖內的註解(箭頭、框線、編號等)位置,可能與實際畫面略有偏差。 本手冊旨在協助理解操作流程,實際操作時請以畫面顯示內容及文字說明為準。 前提條件 已登入客戶入口網站 目標服務狀態為「啟用中」 若升級會產生額外費用,需確保付款方式(信用卡 / PayPal / 銀行轉帳等)可正常使用 升級與降級的差異 升級 若產生額外費用,系統會建立帳單,付款完成後資源才會生效。 降級 差額會以點數形式退款顯示。並非直接退款至原付款來源。 Upgrade 升級(資源增強)流程 1. 開啟目標服務 從左側選單的「服務」進入服務清單。 點擊目標服務名稱(例:BESTNET-CLOUD)進入管理畫面。 在服務清單中,點擊目標服務名稱(紅框(1))。 2. 開啟「資源」頁面,點擊「升級 / 降級」 在目標服務的管理畫面開啟「資源」頁面。 點擊畫面右下方的「升級 / 降級」。 點擊「升級 / 降級」(紅框(2))。 3. 設定欲變更的資源,點擊「繼續」 將欲升級的項目(例:記憶體、NVMe SSD 等)透過滑桿調整至希望的數值。設定完成後,點擊頁面下方的「繼續」。 增加所需項目後,點擊「繼續」(紅框(3))。 4. 確認估價內容,選擇付款方式後「提交」 確認變更內容(已增加的項目)及費用。選擇付款方式,點擊「提交」確定升級。 選擇付款方式(紅框(4)),點擊「提交」(紅框(5))。 5....

OpenSense 虛擬路由器從 ISO 檔案安裝與設定

Last Updated: 2026年6月9日

前提: 若您使用 BESTNET Cloud,可以從標準提供的 ISO 檔案安裝 OPNsense 虛擬路由器。 本說明將記載從建立虛擬機器到 ISO boot 安裝與初始設定的流程。 STEP1. 建立虛擬機器 按照以下順序進行,即可建立 OPNsense 虛擬機器。 1、建立新伺服器 2、輸入任意主機名稱 3、輸入預計設定的密碼(OPNsense 不支援自動設定密碼,需要登入 OS 後手動設定) 4、SSH 金鑰管理(OPNsense 不支援自動管理 SSH 金鑰,需手動設定) 5、選擇 OS 範本 請選擇 OPNsense-25.1-dvd-amd64.iso 6、配置運算資源 7、interface net0 請配置 PublicIP(s)。 8、請點擊「建立新虛擬機器」。 STEP2. 為 LAN 建立額外介面 在已建立的虛擬機器概要頁面中,依序點擊「網路」→「介面」,然後點擊「新增網路介面」。   接下來,將要配置的位址從 Public IP(s) 改選為您合約中雲端實例已配置的私有網路,然後點擊「Assign new IP」。 最後點擊「新增網路介面」即完成。   STEP3. OS 安裝 啟動虛擬機器後會從...

VPS-新用戶申請流程

Last Updated: 2026年6月9日

概要 本手冊說明如何從客戶入口網站新申請 VPS(NV方案)的操作步驟。 事前準備 用於申請的電子郵件地址(新註冊時) 登入密碼(新註冊時) SSH公開金鑰(OpenSSH格式。若需使用公開金鑰認證登入) 付款方式(銀行轉帳/信用卡付款等) 補充:畫面顯示及文字說明可能因入口網站設定而略有不同。 1. 選擇方案並進入訂購畫面 1-1. 在方案頁面選擇所需方案 開啟入口網站的方案(價格)頁面。 從滑桿(例如:NV-16 / NV-32 / NV-64 / NV-96)中選擇所需方案。 確認顯示的規格(CPU/記憶體/NVMe SSD/傳輸流量)及月費。 1-2. 進入訂購畫面 點擊「進入訂購畫面」。 若出現Cookie同意的彈出視窗,請點擊「Accept」等選項關閉。 2. 在訂購畫面設定資源配置 在訂購畫面中,設定各項目後右側的「購物車摘要」將反映金額。 (錄影中以 NV-32 為例) 2-1. 選擇產品(方案) 在「選擇產品」中點擊所需方案(例如:NV-32)。 2-2. 設定 RAM / CPU / Disk 在「RAM [GB]」滑桿選擇記憶體容量。 在「CPU Cores」滑桿選擇CPU核心數。 在「Disk Size [GB]」滑桿選擇磁碟容量。 2-3. 設定備份・快照(如有需要) 在「備份保留世代數」選擇保留世代數(額外數量等)。 在「快照」選擇所需的快照數量。 2-4....

本公司管理外的外部網域DNS記錄管理

Last Updated: 2026年6月9日

DNS SERVICE 指南 概述 本操作手冊整理了如何從本公司客戶入口網站(Client Area)管理 非本公司管理之外部網域(註冊商為其他公司之網域)的DNS記錄。 重點在於,在客戶入口網站上建立區域(DNS管理對象之網域),並在 事先遷移、建立必要的DNS記錄後,在外部註冊商端 將名稱伺服器(NS)切換至本公司DNS伺服器。 STEP 1 新增區域 在Client Area的DNS SERVICE中建立目標網域的區域。 STEP 2 遷移必要記錄 匯入現有DNS設定,或手動註冊。 STEP 3 切換NS 在外部註冊商端將名稱伺服器替換為本公司DNS伺服器。 重要事項(請先閱讀:預防事故之思維) 切換NS的瞬間,權威DNS會切換至本公司DNS。若切換時新區域中未備齊必要記錄,網站/郵件/各種認證將立即受到影響。 特別是郵件相關(MX / SPF / DKIM / DMARC)、認證用TXT(Google / Microsoft / 各種SaaS / SSL自動更新等)、CAA、SRV容易發生遺漏事故。 若網域已啟用DNSSEC,可能需要更新/刪除DS記錄(詳見後述)。 免責聲明・支援服務說明 本操作手冊整理了一般性的作業範例。依網域架構及外部服務(郵件、各種SaaS、SSL自動更新等)的使用情況,所需的DNS記錄及遷移步驟可能有所不同。 對於依循本操作手冊執行後所產生之間接性、衍生性損害(機會損失、業務中斷、郵件未送達等),本公司恕不負責。 如有疑問/難以判斷影響範圍/已啟用DNSSEC/包含郵件在內的遷移作業時,請在作業前從本公司客戶入口網站開啟支援工單諮詢(我們將依狀況提供確認事項之說明)。 前提條件(事前準備) 可登入本公司客戶入口網站 合約已包含DNS SERVICE(DNS管理服務) 在目標網域的註冊商(例:お名前.com / Cloudflare Registrar等)具有變更名稱伺服器的權限 可確認目前的DNS設定(現有DNS的管理介面,或區域檔案/記錄清單) 欲新增、變更的DNS記錄資訊(例:A記錄的IP、MX的主機名稱、TXT的值等) 切換前檢查清單(建議:切換NS前務必執行)...

憑證簽發與部署

Last Updated: 2026年6月9日

技術教學 在 Ubuntu 24 + Apache + WordPress 上導入 PEM 格式的 SSL 證書的方法 這是一個通用教學,說明如何將認證機構 (CA) 管理畫面發行的 PEM 格式 SSL 證書導入到 Ubuntu 24 + Apache + WordPress 環境中。 Ubuntu 24ApacheWordPressPEM SSL 免責聲明 本文是關於在 Ubuntu 24 + Apache + WordPress 環境中導入 SSL 證書 (PEM 格式) 方法的技術教學,說明一般步驟。 所刊載內容基於撰寫時的資訊,但根據特定環境、配置、證書類型、CA 規格、中介軟體版本等,操作和設定方法可能有所不同。 概要 本文是一個通用教學,說明如何將認證機構 (CA) 管理畫面發行的 PEM 格式 SSL 證書(顯示在畫面內文字方塊中的類型)導入到 Ubuntu...

DNS服務-方案的升級降級

Last Updated: 2026年6月9日

DNS SERVICE 指南 概述 本文件說明如何從客戶入口網站進行 DNS SERVICE 方案的 升級/降級。 注意 螢幕截圖為範例環境(例如:Basic → Start 升級)。 顯示的方案名稱、金額、計費時間會依合約內容或設定而有所不同。 STEP 1 選擇目標服務 從 DNS SERVICE 清單開啟目標服務的詳細資訊頁面。 STEP 2 選擇變更目標方案 在升級 / 降級畫面選擇變更目標。 STEP 3 確認計費內容並確定 確認金額、計費週期後送出並完成。 事前準備 能夠登入客戶入口網站 目標 DNS SERVICE 為「啟用」狀態 執行升級/降級時,可能會產生差額費用或信用額度結算 升級步驟 1開啟 DNS SERVICE 清單並選擇目標服務 從左側選單開啟服務 → DNS SERVICE, 點選目標行的服務名稱(例如:Basic)進入詳細資訊頁面。 從 DNS SERVICE 清單選擇目標服務 2在服務詳細資訊開啟「升級 /...

共通使用條款

Last Updated: 2026年6月9日

基本資訊 制定日:2025-12-24 修訂日:2026-02-19 適用開始日:2026-02-19 事業者:ベストネット合同会社(以下稱「本公司」) 地址:宮城県大崎市田尻大貫字北長根161-1 聯絡方式: 一般支援:支援工單 Abuse通報窗口:此表單 第1條(適用) 本規約規定本公司提供之虛擬伺服器(VPS)、GPU-VPS、雲端/IaaS、主機代管、附帶之網路/儲存/備份/快照/ISO相關功能/API等所有服務(以下統稱「本服務」)的使用條件。另外,本公司提供之域名註冊服務及SSL憑證發行服務,適用另行制定之使用規約。 本規約包含標準支援條件(附件A)及SLA・故障時服務信用條件(附件B)。 本服務可能存在制定服務特定規格(CPU/記憶體/儲存/頻寬等)、費用、提供範圍及其他個別條件之「個別條件」。個別條件與本規約(正文或附件)有矛盾時,該個別條件優先適用。 但是,關於第13條(IP位址等之處理)、第14條(本服務之變更・中斷・終止)、第15條(規約之修訂)、第16條(免責・責任限制),若個別條件進行與本規約不同之處理,本公司應於該個別條件中明示優先於本規約之旨意。 客戶申請本服務或使用本服務時,視為客戶已同意本規約及個別條件。 第2條(定義) 本規約之用語定義如下。 (1) 「客戶」:使用本服務之個人或法人 (2) 「帳戶」:本公司為本服務使用而發行之識別符 (3) 「使用環境」:指客戶於本服務上使用之領域(例:虛擬機器、容器、主機代管帳戶、儲存空間等)。本規約中標示為「實例」時,包含使用環境。 (4) 「分配IP」:本公司分配予客戶或使用環境之IP位址(包含固定/32等) (5) 「固定IP」:指本公司通常持續分配相同分配IP之運用形態。但是,固定IP仍可能依據第13條及第14條而變更・停止。 (6) 「上游業者」:指本公司為提供本服務而使用之線路業者、ISP、轉接業者、IX、資料中心業者及其他第三方業者。 (7) 「通訊」:包含傳入/傳出,與使用環境相關之所有網路通訊 (8) 「不當使用(Abuse)」:違反本規約(包含第5條)之行為,或本公司基於合理依據判斷為不當使用之行為 (9) 「階段運營(信任等級)」:第10條規定之運用區分(新規/實績/法人) (10) 「信用額度」:依據本公司另行制定之規定,記錄於客戶帳戶之等同金額,可於本公司規定範圍內充當本服務支付之餘額。 (11) 「服務信用」:指因SLA違反等之補償或本公司判斷而給付之信用額度。 (12) 「標準支援」:指附件A規定之標準支援。 (13) 「SLA」:指附件B規定之可用率保證及服務信用條件。 第3條(申請・帳戶管理・確認程序) 本公司為安全運營及防止不當使用,可能於申請時或使用期間要求本人確認/法人確認/聯絡方式確認/使用目的確認等(以下稱「確認程序」)。 客戶於本公司要求確認程序時,應於合理期間內提交真實且正確之資訊。若有虛假・不備・不一致情形,本公司可拒絕申請、停止使用、降低階段運營等級、追加限制等。 客戶應始終保持於本公司註冊之聯絡方式(電子郵件/電話等)處於可接收狀態。聯絡不能持續時,本公司為安全運營,可依據第7條(通訊限制・技術措施)及第10條(階段運營)進行限制,或依據第14條(本服務之變更・中斷・終止)進行停止等。 第4條(共同責任・資訊安全) 本公司致力於維護本公司設備・網路・控制基礎設施之安全。 客戶對使用環境上之OS/中介軟體/應用程式/認證資訊/金鑰/設定/資料之保護負責(主機代管等本公司管理範圍依據個別條件)。 客戶應採取包含以下之適當資訊安全對策。 (1) OS・中介軟體・應用程式之持續修補(本公司管理範圍除外) (2) 不使用預設認證資訊,使用強固認證(金鑰、強固密碼、可能範圍內之MFA等)...

私有網路

Last Updated: 2026年6月9日

私有網路設定指南 說明如何在客戶入口網站上申請私有網路(Private IP / 子網路), 並將私有IP分配給 BESTNET-CLOUD 和 BESTNET-VPS 的伺服器。 概述 本手順書說明如何在客戶入口網站上申請私有網路 (Private IP / 子網路),並將私有IP分配給 BESTNET-CLOUD 和 BESTNET-VPS 的 伺服器。 前提條件 已登入客戶入口網站 若要使用私有網路(Private IP / 子網路),必須先「訂購」Private-IP 商品 私有網路(Private IP)的申請 1BESTNET-CLOUD:訂購 Private IP(子網路) 從畫面上方的「訂購」開啟訂購畫面。 在商品列表中選擇 BESTNET-CLOUD_PRIVATE-IP。 在 IPv4 Subnet size 選擇所需的大小(例如:/24 等)。 點擊畫面下方的 「訂購」。 2BESTNET-VPS:訂購 Private IP(子網路) 從畫面上方的「訂購」開啟訂購畫面。 在商品列表中選擇 BESTNET-VPS_PRIVATE-IP。 在 IPv4 Subnet size 選擇所需的大小(例如:/24...

虛擬機範本建立

Last Updated: 2026年6月9日

概述 本手冊說明在客戶端入口網站中,從既有執行個體建立範本, 並確認狀態變更為 Ready 的流程。 請確認: 本手冊使用生成式AI等工具協助製作,因此畫面截圖中的註解(箭頭、框線、編號等)位置, 可能與實際畫面略有偏差。操作時請以實際畫面顯示和文字內容為準。 事前準備 已登入客戶端入口網站 作為範本來源的執行個體(Source)至少存在1台 Note: 建立範本期間,來源執行個體可能會暫時變更為 templating 狀態。 步驟1:開啟範本畫面 開啟目標服務(例:BESTNET-CLOUD)的畫面。 從畫面左側(服務內選單)開啟 テンプレート(圖中①)。 點擊 Create template(圖中②)。 開啟範本畫面並點擊 Create template 步驟2:輸入範本資訊 選擇 Source(範本來源)(圖中①)。 在 名前 欄位輸入範本名稱(圖中②)。 在 Description 欄位輸入說明(選填)(圖中③)。 點擊 Create template 開始建立(圖中④)。 輸入範本資訊並執行 Create template 步驟3:確認狀態變更為 Pending 開始建立後,範本清單會新增一列,狀態顯示為 Pending(處理中)。 當狀態為 Pending 時,請等待處理完成。 若狀態未更新,請重新整理頁面(reload)確認。 狀態為 Pending 表示正在處理中 步驟4:確認狀態變更為 Ready 處理完成後,範本狀態會變更為...

SSL 憑證重新簽發

Last Updated: 2026年6月9日

關於網域和SSL憑證的續約及請款

Last Updated: 2026年6月9日

網域申請

Last Updated: 2026年6月9日

網域註冊指南 說明從客戶入口網站申請(註冊)新網域的步驟。 畫面為範例。 概要 本手冊說明從客戶入口網站申請(註冊)新網域的步驟。 申請時,訂單畫面或網域註冊資訊所使用的姓名、地址、公司名稱等 請以英文(半形英數字)輸入。 事前準備 已登入客戶入口網站 已決定欲取得的網域名稱(例如:example.com) 訂單(結帳)時的聯絡資訊(姓名、地址、公司名稱等)請準備好以英文(半形英數字)輸入 重要 訂單畫面的「客戶資訊」或「網域聯絡人」所輸入的註冊者資訊(WHOIS / Registrant) 請以英文(羅馬字、半形英數字)填寫。 若以日文註冊,可能因註冊商要求而發生註冊錯誤。 輸入範例 Name: Taro Suzuki Address: 1-1-1 Otemachi, Chiyoda-ku City: Tokyo / State: Tokyo / Postal Code: 100-0004 Country: Japan 網域申請步驟 1開啟網域搜尋畫面 從客戶入口網站的「網域」選單開啟 「批次網域搜尋」。 2輸入希望的網域名稱並搜尋 在搜尋欄輸入欲取得的網域名稱(例如:example.com)。 點擊「搜尋」(①)。 3從搜尋結果選擇希望的TLD並點擊「註冊」 從搜尋結果顯示的候選中選擇欲取得的網域(TLD)。 點擊該行的「註冊」(①)。 4點擊「訂購所選網域」 點擊畫面右下方顯示的 「訂購所選網域」(①)。 5確認、設定網域的配置 在「網域配置」畫面確認註冊期間、IDN設定、名稱伺服器、聯絡資訊等。 期間:選擇1年等希望的註冊期間。 IDN Language:處理日文網域(例如:例え.テスト)等IDN時,選擇對象語言(①)。僅註冊英數字網域時,通常不需變更。 名稱伺服器:使用獨立名稱伺服器時,從「我想使用自己的名稱伺服器」進行設定。...

有效期限與狀態的確認

Last Updated: 2026年6月9日

SSL憑證購買

Last Updated: 2026年6月9日

OV SSL 發行指南 本手冊說明從客戶入口網站購買 OV SSL證書、 核准 網域控制驗證(DCV) 到確認發行狀態的流程。 重要 申請 OV SSL 時,需要以英文(半形英數字)輸入聯絡資訊。 若包含日文(全形)可能會發生錯誤。 OV SSL 發行流程 事前準備 目標網域(例:example.com) CSR(憑證簽署請求)(於伺服器建立) 聯絡資訊(英文):姓名、部門、職稱、地址、電話號碼、電子郵件地址等 能夠接收 DCV 驗證郵件(例:admin@ / administrator@ / hostmaster@ / postmaster@ / webmaster@) Step 1:訂購 OV SSL 1-1 在訂購畫面輸入網域(主機名稱)並繼續 在客戶入口網站選擇 OV SSL 商品(例:GeoTrust True BusinessID),開啟訂購畫面。 在主機名稱中輸入目標網域。 點擊右側的繼續。 1-2 支付帳單 將產生帳單(Invoice)。 點擊立即付款!,依照指示完成付款。 Step 2:設定憑證資訊(CSR・聯絡人) 2-1 從...

郵件轉發功能

Last Updated: 2026年6月9日

網域管理指南 概述 本手冊說明如何從客戶入口網站 新增、變更、刪除網域的郵件轉發設定。 郵件轉發的概念圖 操作 1 新增 將寄送到網域的郵件自動轉發至現有的電子郵件地址。 操作 2 變更 編輯現有的轉發目的地地址並儲存。 操作 3 刪除 將目標列清空後儲存,刪除轉發設定。 什麼是郵件轉發 郵件轉發是將寄送到網域的郵件(例:sales@yourdomain.example)自動轉發至現有的郵件信箱(例:Gmail等)的機制。 轉發是「轉送收到的郵件」的功能,並非建立郵件信箱(收件匣)本身。 回覆基本上會從轉發目的地的電子郵件地址寄出(並非從網域端的地址寄出)。 前置條件 能夠登入客戶入口網站 目標網域狀態為有效(Active) 目標網域使用預設的名稱伺服器 已準備好作為轉發目的地使用的現有電子郵件地址(例:Gmail / Microsoft 365 / 公司內部郵件等) 重要 郵件轉發功能的前提是目標網域使用 預設的名稱伺服器。 若使用自訂名稱伺服器,可能會出現畫面不顯示或無法儲存的情況。 操作步驟 1開啟郵件轉發畫面 登入客戶入口網站,開啟目標網域的詳細畫面。 從網域選單點擊「郵件轉發」。 網域選單的「郵件轉發」 2新增轉發目的地 在郵件轉發欄的輸入列中,輸入郵件信箱名稱(@左側)。例:輸入 sales 會形成 sales@yourdomain.example 這樣的地址。 在轉發目的地中,輸入作為轉發目的地的電子郵件地址(例:forward-to@example.com)。 點擊「儲存變更」。 儲存後,確認轉發設定已反映在列表中。 新增:輸入郵件信箱名稱和轉發目的地後儲存 儲存後:轉發設定已新增至列表 3變更轉發目的地 編輯列表中顯示的目標列的轉發目的地電子郵件地址。 點擊「儲存變更」。 儲存後,確認變更內容已反映。...

註冊自訂名稱伺服器

Last Updated: 2026年6月9日

網域管理指南 概述 本作業手冊說明如何透過本公司客戶入口網站,將目標網域的名稱伺服器 切換至外部DNS伺服器(外部DNS代管)。 變更名稱伺服器後,DNS記錄的查詢對象(權威DNS)將切換至外部DNS端。 切換後本公司端所設定的DNS記錄將不再被查詢,因此 請務必事先在外部DNS端準備好區域(DNS記錄)再進行作業。 STEP 1 準備外部DNS 在外部DNS端完成區域建立及必要記錄的註冊。 STEP 2 輸入名稱伺服器 在客戶入口網站設定自訂名稱伺服器。 STEP 3 儲存・確認 儲存設定後,從外部確認NS及記錄的切換狀態。 重要說明(請先閱讀:預防事故的注意事項) 名稱伺服器切換=查詢對象整個切換。若切換時外部DNS端的設定不完整,Web / 郵件 / 各項驗證將立即受到影響。 特別容易遺漏的項目包括:郵件(MX / SPF / DKIM / DMARC)、驗證用TXT(Google / Microsoft / 各類SaaS)、SSL更新用TXT(_acme-challenge)、CAA、SRV。 執行切換作業前,請記錄現行DNS設定(本公司端 / 其他服務端),並在外部DNS端建立對等的記錄。 若網域已啟用DNSSEC,切換時可能需要更新 / 刪除DS記錄(詳見後述)。 免責聲明・支援服務說明 本作業手冊彙整一般性的運用範例。依據網域架構及外部服務(郵件、各類SaaS、SSL自動更新等)的使用狀況,所需的DNS記錄及轉移步驟會有所不同。 對於依照本手冊執行而產生的間接性、衍生性損害(機會損失、業務中斷、郵件無法送達等),本公司恕不負責。 若有不明之處 / 難以判斷影響範圍 / 已啟用DNSSEC / 需要連同郵件一併切換,請於作業前透過本公司客戶入口網站開啟支援工單諮詢。 事前準備 外部DNS服務所提供的名稱伺服器(通常2個以上)主機名稱 外部DNS端已完成目標網域的區域建立・記錄設定...

註冊鎖定的管理

Last Updated: 2026年6月9日

網域管理指南 概述 本操作手冊說明如何在客戶入口網站上,開啟/關閉網域的 註冊鎖定(Registrar Lock)(鎖定/解鎖)。 將註冊鎖定設為開啟時,可有效防止第三方進行未經授權的網域轉移(Transfer)。 若要進行網域轉移,請事先將其變更為關閉。 狀態 1 開啟 可有效防止第三方進行未經授權的轉移。建議在日常營運時使用此設定。 狀態 2 關閉 在進行網域轉移(Transfer Out)前所需的設定。 重點 變更後請確認 確認出現儲存成功訊息,以及網域詳細資訊的顯示狀態已更新。 事前準備 可登入客戶入口網站 目標網域處於啟用狀態 以具有目標網域管理權限的帳戶(合約持有人帳戶)進行操作 操作步驟 1 開啟目標網域的詳細資訊頁面 開啟客戶入口網站的控制台。 從「我的服務」內的網域清單中,點擊目標網域右側的箭頭(①)。※從網域名稱連結開啟亦可。 從控制台選擇目標網域 2 前往「註冊鎖定」設定頁面 點擊網域詳細資訊頁面上方概要欄中的註冊鎖定(①)。 開啟網域詳細資訊頁面的「註冊鎖定」 3 變更註冊鎖定(開啟/關閉)並儲存 在「網域鎖定設定」區段中,點擊註冊鎖定的下拉選單(①)。 選擇所需的狀態(開啟/關閉)。 點擊「儲存變更」(②)。 變更註冊鎖定設定並儲存 4(解除鎖定時)選擇「關閉」 若因網域轉移等目的需要解除鎖定,請從下拉選單中選擇 「關閉」(①)。 解除鎖定時請選擇「關閉」 變更後的確認 儲存後,頁面右上方會顯示更新成功的訊息(①)。 確認網域詳細資訊概要欄中的註冊鎖定狀態(②)已更新為所選內容(開啟/關閉)。 確認儲存成功訊息及變更後的狀態 注意事項 一般建議開啟 從安全性角度考量,一般建議將註冊鎖定維持在開啟狀態進行營運。 轉移前請變更為關閉 進行網域轉移時,請在轉移程序前變更為關閉,轉移完成後再重新設為開啟。 可能需要時間反映 根據註冊局端的反映情況,狀態切換可能需要一些時間。若顯示未更新,請嘗試重新整理(刷新)頁面。 疑難排解...

網域轉移

Last Updated: 2026年6月9日

BESTNET 優先支援服務使用契約條款

Last Updated: 2026年6月9日

條款本文 第1條(目的) 本條款針對本公司提供的付費優先技術支援服務「BESTNET 優先支援」,規定本公司與客戶之間締結的合約中雙方應遵守的事項。 第2條(服務內容) 客戶支付本服務費用之時點,即視為本合約成立。 本公司透過以下管道向客戶提供優先技術支援。 BESTNET Client Portal(24小時受理) 專用電話(平日 10:00-18:00 JST) 專用電子郵件地址(24小時受理) 方案概要如下。 Single Ticket:NT$1,977/件・作業上限 2小時・有效期限 6個月 5-Pack:NT$8,876/5件・有效期限 6個月 Monthly:NT$19,769/月・同時開啟 5件・1個月自動續約 本服務的支援範圍如下。 本公司提供・販售的產品・服務及其他公司產品(硬體/軟體/雲)的設定支援、初步排查、規避方案建議 作業系統、中介軟體、SaaS、IaaS 的使用方法及障礙調查 架構變更・升級、API/CLI 操作方法諮詢 下列事項不在本服務範圍內,必要時另行報價後以付費方式處理。 需要製造商專用工具或韌體變更的硬體維修 涉及原始碼修改或實驗室分析的錯誤修正 資料復原、資訊安全事件應對、IR 代理 持續性營運代理及教育・培訓服務 第3條(合約期間) Single Ticket 及 5-Pack 自購買日起經過 6個月後,包含未使用部分均失效。 Monthly 以申請日為起算日,以 1個月為單位自動續約,除非於續約日前 3個工作日在 Portal 上完成解約手續,否則持續有效。 第4條(費用及支付方法) 客戶須以信用卡付款或本公司指定的方式預付所選方案費用。 付款後不予退款,但條文規定的情況除外。 客戶延遲付款時,本公司得催告後停止本服務,並請求遲延損害金。 第5條(協力義務) 客戶須迅速提供調查所需的日誌・重現步驟等資料,並配合本公司的查詢。 因客戶協力不足而導致支援延遲時,本公司不負責任。...

DNS 記錄的更新管理

Last Updated: 2026年6月9日

DNS 管理指南 本文說明如何在客戶入口網站管理(新增、編輯、刪除) DNS 記錄(A / CNAME / MX / TXT 等) 的步驟。 重要 在此畫面編輯的 DNS 記錄要反映至外部,僅限於 目標網域的名稱伺服器(NS)目前指向此 DNS 管理的參照位置時 才會生效。 例如:若名稱伺服器已切換至外部 DNS(Cloudflare / Route53 等),之後會參照外部 DNS 端的設定,因此在本畫面編輯也不會反映至外部。 建議在變更前記錄目前的記錄內容 (螢幕截圖/筆記)。特別是郵件(MX / SPF / DKIM / DMARC)或認證用 TXT,若遺漏移轉會造成重大影響。 CNAME 原則上無法與同一主機名稱的其他記錄(A/MX/TXT 等)共存。 (例如:www 已有 CNAME 時,若以相同名稱新增 A 記錄會產生衝突) DNS 的反映因 TTL 和快取而有時間差。建議驗證期間將 TTL 設短,穩定後再改回適當的值。 免責聲明・支援說明 本步驟彙整了一般營運範例。根據網域架構或外部服務(郵件、各種 SaaS、SSL...

網域聯絡人管理

Last Updated: 2026年6月9日

Domain Contacts 設定指南 如何變更網域聯絡資訊(Domain Contacts) 從客戶入口網站變更目標網域的 Domain Contacts (Registrant Contact / Administrative Contact / Technical Contact / Billing Contact)的操作步驟。 本操作說明書中,網域聯絡資訊的名稱一律以英文 (Registrant Contact 等)表示。 概要 可從網域詳細資訊畫面的「聯絡資訊」變更各種 Domain Contacts。 輸入時,請以英文(羅馬拼音)登錄姓名、地址、公司名稱等資訊。 事前準備 已登入客戶入口網站 目標網域已顯示在入口網站的「網域」清單中 已準備好要輸入的聯絡資訊(姓名、地址、公司名稱等)的英文(羅馬拼音)版本 操作步驟 1 開啟「網域」清單 從左側選單開啟「網域」,顯示網域清單畫面。 2 開啟要變更的網域詳細資訊 在網域清單中,點擊目標網域列右端的 箭頭(→)開啟詳細資訊畫面。 3 開啟「聯絡資訊」 從網域詳細資訊畫面左側選單(「網域的詳細資訊」)點擊 「聯絡資訊」。 4 設定 Registrant Contact(註冊人聯絡資訊) 在「聯絡資訊」區段的Registrant Contact (畫面上顯示為「登錄者の連絡先」)中,選擇設定方式。 Custom(カスタム):手動輸入表單進行設定 Use an existing...

客戶入口網站:新增帳戶餘額(資金)

Last Updated: 2026年6月9日

帳戶儲值指南 在客戶入口網站中,新增可用於未來訂單或發票付款的 「帳戶儲值(資金)」 的步驟說明。 概述 透過客戶入口網站預先為帳戶儲值, 即可新增可用於未來訂單或發票付款的儲值金額。 事前準備 已登入客戶入口網站 已決定欲新增的金額 操作步驟 1 開啟左側選單的「請求」 從客戶入口網站左側選單點擊 「請求」。 2 開啟「新增資金」分頁 從請求畫面上方的分頁點擊 「新增資金」。 3 設定金額與付款方式(閘道) 在 「金額」 輸入欲新增的金額。 選擇 「閘道」(付款方式)。例如:銀行轉帳、PayPal、信用卡付款 等 重要 已儲值的帳戶儲值金額原則上不支援現金提領退款。 關於詳細處理規定,請參閱 帳戶儲值處理規定。 3.1(選用)確認並選擇付款方式候選項目 開啟閘道的下拉選單後,會顯示可選擇的付款方式清單。 4 點擊「+ 新增資金」建立發票 確認輸入內容後,點擊 「+ 新增資金」。 系統將自動建立發票(Invoice)。 5 從建立的發票進行付款/下載PDF 在建立的發票畫面中,點擊 「立即付款!」 進行付款(顯示內容依所選閘道而異)。 如有需要,可從 「下載PDF」 取得發票PDF。 完成確認(確認儲值餘額) 付款完成後,將反映在客戶入口網站上方的 「可用儲值」(餘額顯示)。 若反映需要時間,請稍候片刻後重新載入頁面。 補充說明・注意事項 已儲值的帳戶儲值金額原則上不支援現金提領退款。詳情請參閱 帳戶儲值處理規定。...

頻寬升級

Last Updated: 2026年6月9日

VPS 頻寬升級指南 本操作手冊彙整了從客戶入口網站 增加 VPS 傳輸容量(「每月頻寬上限[GB]」) 的操作步驟。 補充說明 畫面文字與版面配置可能會因服務類型、合約內容、顯示語言而有所不同。 對象 希望從客戶入口網站增加 VPS 每月頻寬上限(GB) 的用戶 希望在提出升級申請後,開立發票(Invoice)並完成付款的用戶 事前準備 能夠登入客戶入口網站 能夠開啟升級對象服務(VPS)的服務詳細資訊畫面 已備妥付款方式(銀行轉帳 / 信用卡 / PayPal 等) 操作步驟 1從服務詳細資訊開啟「升級」 開啟目標 VPS 的 服務詳細資訊畫面。 在畫面右上方的操作選單中開啟 More(圖中①)。 從顯示的選單中點選 升級(圖中②)。 2將每月頻寬上限(GB)變更為希望值並「繼續」 在升級畫面中,從項目清單尋找 每月頻寬上限[GB]。 拖曳 每月頻寬上限[GB] 的滑桿,設定為希望的容量(GB)(圖中①)。 設定完成後,點選右下方的 繼續(圖中②)。 注意 本操作步驟目的為變更「傳輸容量(頻寬)」。 如不變更 RAM / CPU / Disk 等其他項目,請勿觸碰滑桿。 3確認內容與付款方式,並提交升級 在「服務升級」畫面中,確認變更內容(例:每月頻寬上限[GB]:6000 => 24000)(圖中①)。...

虛擬機規模升級

Last Updated: 2026年6月9日

重要:本操作手冊的前提條件是雲端執行個體具有充足的資源餘裕。若雲端執行個體的資源不足,請參閱以下文章事先追加資源。 雲端資源升級 概要 從客戶入口網站變更(擴展)雲端虛擬機器(執行個體)的 CPU 核心數 與 記憶體(RAM) 的操作步驟。 執行擴展後,伺服器會進入任務執行狀態(例:RESETTING),並發生相當於重新啟動/重置的動作。請於計劃停機時段進行作業。 前提條件 已登入客戶入口網站 目標執行個體具有充足的資源餘裕(不足時請參閱開頭連結) 擴展期間將發生擴展對象伺服器的重新啟動,須為可接受影響的時段 操作步驟 1. 在儀表板開啟「BESTNET-CLOUD」 從儀表板的 我的服務 點擊 BESTNET-CLOUD 開啟服務畫面。 2. 從執行個體清單選擇目標 VM 在服務畫面的 執行個體清單 中,點擊欲擴展的 VM(例:DEMO-HOST)的主機名稱。 3. 在伺服器詳細資料中開啟「More」→「擴展」 點擊伺服器詳細資料畫面右上方的 More,從選單中選擇 擴展。 4. 在「擴展 VM」設定 CPU/RAM 並執行 在 擴展 VM 畫面設定所需的 RAM 與 CPU 核心,然後點擊 調整資源分配。 可直接在數值輸入欄輸入,或使用滑桿調整。 例:RAM 2048 MB、CPU 核心 2 5....

客戶入口網站操作步驟(記錄檢視・資源圖表)

Last Updated: 2026年6月9日

Client Portal Guide 客戶入口網站:日誌・使用狀況(資源)確認指南 本手冊說明如何在客戶入口網站上進行日誌瀏覽與 資源圖表(使用狀況)確認。 注意事項: 本手冊使用生成AI等工具製作,因此畫面截圖內的註釋(箭頭・框線・編號等)位置可能與實際畫面略有偏差。 本手冊以理解操作意圖為目的,操作時請優先確認畫面顯示・文字內容。 前提條件 已登入客戶入口網站 已開啟目標服務(例:VPS 等)的詳細畫面 日誌瀏覽 1. 開啟日誌畫面 從服務詳細畫面的選單點擊 「ログ」。 將顯示日誌清單(日期時間/說明/狀態)。 圖1: ①點擊「ログ」 / ②顯示日誌清單 2. 日誌的查看方式 日期:事件發生的日期時間 說明:執行的操作(例:VM Start / VM Stop / VM Configure 等) 狀態:處理結果(例:OK) 圖2: ①確認日誌欄位(「日付」「説明」「ステータス」) 3. 確認過去的日誌 向下捲動清單可確認更早的日誌。 資源圖表(使用狀況)的確認 1. 開啟「使用状況」→「リソース」 在服務詳細畫面的選單點擊 「使用状況」 展開。 從顯示的子選單點擊 「リソース」。 圖3: ①展開「使用状況」 / ②選擇「リソース」 2. 變更顯示期間(統計方法)...

快照管理

Last Updated: 2026年6月9日

Client Portal Guide 客戶入口網站:快照操作指南 本文件整理了在客戶入口網站上對 VPS 進行建立快照、刪除、排程設定的操作步驟。 前提條件 能夠登入客戶入口網站 對目標服務(例:VPS)具有存取權限 快照的建立與保留數量取決於合約方案/上限設定 建立手動快照 1. 開啟快照畫面 在入口網站中開啟目標 VPS 的詳細畫面。 從畫面左側(服務選單)點選「快照」。 從目標 VPS 的詳細畫面開啟快照畫面。 2. 點選「建立新快照」 點選快照清單畫面右側的「建立新快照」。 點選「建立新快照」。 3. 輸入必要資訊並建立快照 在 Snapshot name 輸入快照名稱。 如有需要包含記憶體,請勾選(停止狀態/運作狀態的處理方式因環境而異,請遵循營運規則)。 在說明(選填)輸入用途或建立目的。 點選 Create Snapshot。 輸入必要資訊並建立快照。 4. 確認建立狀況 建立後會在清單中以 Creating 等狀態顯示。 完成後會切換為 Current 等顯示。 管理快照 1. 設定 Pinned 啟用 Pinned(固定) 可能會影響營運上的刪除與自動刪除行為。請遵循營運規則進行設定。 在快照清單中確認目標快照列。 透過 Pinned...

防火牆設定變更

Last Updated: 2026年6月9日

防火牆設定指南 本手順書說明如何從客戶端入口網站,針對 VPS / 伺服器新增、編輯、刪除 防火牆(Firewall)規則, 並根據需要設定預設政策(Input / Output Policy)和日誌記錄設定。 重要 對於出站通訊,可能需要申請許可。 詳情請確認 此處 。 概述 Rules:新增、編輯、刪除允許 / 拒絕規則 Options:設定預設政策(Input / Output Policy)和日誌等級等 Logs:確認 / 下載防火牆日誌 事前準備 已登入客戶端入口網站 可以選擇目標服務(VPS / 伺服器) 了解要允許的通訊需求(例如:HTTPS 443、SSH 22 等),並在必要時掌握允許來源IP(固定全球IP等) 操作步驟 1開啟防火牆畫面 從左側選單的服務開啟目標 VPS / 伺服器。 在伺服器詳細資料畫面的選單中展開網路,點擊防火牆。 在網路下開啟「防火牆」。 2Rules 規則清單的檢視方式 在 Rules 分頁中,會按介面(例如:net0)顯示 IN / OUT 的規則清單。 類型:IN(接收)/ OUT(傳送) Action:ACCEPT(允許)/...

SSH 金鑰註冊與管理

Last Updated: 2026年6月9日

目的 本程序旨在透過使用SSH的公開金鑰認證,實現安全登入雲端主機。執行步驟為: 建立公開金鑰與私密金鑰 → 在雲端註冊公開金鑰 → 使用私密金鑰確認登入。 關於公開金鑰與私密金鑰 公開金鑰(Public Key)與私密金鑰(Private Key)是用於加密及認證的金鑰對。 公開金鑰可以共享,而私密金鑰只能由本人嚴格保管。 公開金鑰(Public Key)的特徵 可公開:可以分發給任何人,不會造成問題。 主要用途: 加密(使用公開金鑰加密的資料,只能用對應的私密金鑰解密) 簽章驗證(驗證使用私密金鑰簽署的內容) 私密金鑰(Private Key)的特徵 絕對保密:請勿與他人共享。洩漏會導致未經授權存取等問題。 主要用途: 解密(解密使用公開金鑰加密的資料) 簽章(建立數位簽章) 建立公開金鑰與私密金鑰(Tera Term) 此處將使用Tera Term的金鑰產生功能來建立公開金鑰與私密金鑰。 建議位元數為4096。 建立步驟 1 啟動Tera Term。 2 若啟動後出現新連線的彈出視窗,請點選[取消]或[×]關閉。 圖1:關閉啟動後的彈出視窗 3 點選畫面上方選單的[設定(S)]。 圖2:開啟[設定(S)] 4 點選[SSH金鑰產生(N)](在此產生金鑰對)。 圖3:開啟SSH金鑰產生 5 在金鑰產生畫面中,將金鑰類型設定為RSA,位元數設定為4096, 然後點選右上方的[產生(G)]。 圖4:使用RSA(4096bit)產生金鑰 6 金鑰產生後,若出現輸入保護私密金鑰的密碼短語,請進行設定。 建議:10個字元以上,包含英文大小寫、數字、符號。 ※不設定也可建立,但請盡可能設定。 圖5:設定私密金鑰的密碼短語 7 分別點選畫面內的公開金鑰/私密金鑰儲存按鈕,儲存金鑰檔案。 ※儲存格式選項(例如:bcrypt KDF等)請依照畫面顯示及運作規則選擇。...

備份與還原

Last Updated: 2026年6月9日

目的 本文件說明如何在客戶入口網站上執行 從備份還原(復原)以及 備份排程設定的步驟。 前提條件 能夠登入客戶入口網站 能夠開啟目標 VPS/VM(服務)畫面 欲還原的備份已建立完成(顯示於列表中) 開啟目標服務畫面 1 登入客戶入口網站。 2 從左側選單開啟服務,選擇目標 VPS/VM。 3 在服務詳細畫面中,操作儲存相關分頁(備份 / 備份排程)。 從備份還原(復原) 1. 開啟備份列表 在服務詳細畫面開啟備份分頁。 點擊欲還原的備份列右側的齒輪(動作)。 2. 執行「還原」 從動作選單選擇還原。 3. 在確認對話框按下 OK 當顯示「確定要還原此備份嗎?」時,點擊OK。 4. 確認還原(ROLLBACK)處理進度 還原被受理後,畫面右上方會顯示「Scheduled restore from backup」等通知。 服務詳細的狀態會變成ROLLBACK,並顯示「伺服器正在執行任務」。 必要時請點擊更新,等待狀態完成。 注意: 「還原」會將伺服器的磁碟狀態還原至備份時點,還原後的變更內容將會遺失。 執行前請確認影響範圍。 從備份取得檔案(File Restore) 若不是要還原整個備份,而是想要 下載備份內的檔案/目錄,請使用File Restore。 (畫面上會以「Download as」進行 zip 下載) 1. 開啟 File Restore...

虛擬機密碼重設

Last Updated: 2026年6月9日

Client Portal Guide 客戶入口網站:VPS 密碼重設指南 本操作手冊說明如何在客戶入口網站上重設 VPS(伺服器)的 root 密碼。 說明: 本操作手冊使用生成式 AI 等工具製作,因此畫面截圖中的註解(箭頭、框線、編號等)位置可能與實際畫面略有偏差。 本手冊旨在協助理解操作流程,實際操作時請以畫面顯示及文字內容為準。 事前準備 已登入客戶入口網站 已開啟目標服務(VPS)的 伺服器詳細資訊 畫面 注意事項 密碼重設可能伴隨 伺服器重新啟動(請依照畫面上的確認訊息操作)。 重設完成後 舊密碼將無法使用。請先記下新密碼再進行連線。 作業期間 SSH / 主控台連線可能會中斷。 密碼重設步驟 1. 點選「Reset Password」(鑰匙圖示) 點選「伺服器詳細資訊」中「密碼」欄位的 鑰匙圖示(Reset Password)。 點選鑰匙圖示(Reset Password)。 2. 在確認對話框中點選「OK」 顯示確認訊息後,請確認內容並點選 OK。 在確認對話框中點選 OK。 3. 等待任務執行中的顯示消失 處理期間會顯示「伺服器正在執行任務」等訊息。 必要時可點選 更新 來重新整理狀態,並等待處理完成。 任務執行中時可點選「更新」來重新整理狀態。 4. 顯示並複製新密碼 處理完成後,「密碼」欄位會設定新密碼。請依照以下步驟確認及取得密碼。 點選 眼睛圖示...

虛擬機重建

Last Updated: 2026年6月9日

這是從客戶端入口網站對 VPS 進行重建(重新安裝)的操作步驟說明。 概述 「重建(Rebuild)」=使用選擇的作業系統範本重新安裝 VPS。 執行後,磁碟上的所有資料將被刪除(無法復原)。 重要: 執行重建後,伺服器上的現有資料將會遺失。如有需要的資料,請務必事先進行備份。 事前準備(重要) 備份 如有需要的資料,請務必在重建前進行備份。 如無備份方式,請先向技術支援諮詢。 重建所需資訊 欲重新安裝的作業系統(例:Ubuntu / Debian / Rocky / Alma / OpenSense 等) 重建後設定的登入密碼(root 密碼) 操作步驟 1. 開啟目標 VPS 的管理畫面 登入客戶端入口網站。 從左側選單的「服務」開啟目標 VPS(例:NVPS663),顯示「伺服器詳細資訊」畫面。 2. 從「More」開啟「重建」 點擊畫面右上方的「More」。 從顯示的選單中點擊「重建」。 3. 選擇作業系統範本 在「重建」頁面開啟「作業系統範本」的下拉選單。 選擇欲重新安裝的作業系統範本。 4. 設定密碼(root) 在「密碼」欄位輸入重建後要使用的密碼。 如有需要,可點擊右側的眼睛圖示切換顯示 / 隱藏進行確認。 5. 執行「VPS 重新安裝」並在確認時按下「OK」 點擊「VPS 重新安裝」。 顯示確認對話框後,確認內容並點擊「OK」。 注意:...

ISO 上傳/掛載

Last Updated: 2026年6月9日

Client Portal Guide 客戶端入口:ISO 上傳與 Boot from ISO 操作指南 本手冊說明如何在客戶端入口上傳 ISO 映像檔, 並將ISO 掛載至 VPS(Boot from ISO)以進行開機的完整流程。 說明: 本手冊使用生成式 AI 等工具製作,畫面截圖中的註解(箭頭、框線、編號等)位置可能與實際畫面略有偏差。本手冊旨在協助理解操作流程,實際操作時請以螢幕顯示與文字內容為準。 前提條件 已登入客戶端入口 可開啟目標 VPS(服務詳細資料畫面) 已在本機電腦準備好要上傳的 ISO 檔案 注意: 執行「Boot from ISO」會重新啟動伺服器。由於會影響運行中的服務,請確保已安排作業時段後再進行操作。 上傳 ISO 1. 開啟 ISO 清單 從目標 VPS 的服務選單中點選「ISOリスト」。 從服務選單開啟 ISO 清單。 2. 開啟上傳對話框 在 ISO 清單畫面點選「ISOのアップロード」。 在對話框中選擇「ファイルのアップロード」分頁,然後點選「ファイルを選択」。 開啟上傳對話框,準備選擇 ISO 檔案。 3. 選擇...

虛擬機主控台

Last Updated: 2026年6月9日

Client Portal Guide 客戶入口網站:控制台(noVNC)操作指南 本操作手冊整理了從客戶入口網站啟動伺服器控制台(noVNC), 並存取作業系統登入畫面的操作步驟。 前提條件 已登入客戶入口網站 能夠開啟目標 VPS 的服務詳細資訊畫面 操作步驟 1. 開啟服務詳細資訊畫面 從左側選單開啟「服務」,並選擇目標伺服器。 確認顯示服務名稱(例:NVPS663)及「伺服器詳細資訊」。 2. 啟動控制台 點擊服務詳細資訊畫面上方的「控制台」。 ① 點擊「控制台」按鈕 點擊後,noVNC 控制台將在新視窗(或新分頁)中啟動。 如果彈出視窗未開啟,請從瀏覽器網址列附近顯示的提示中 允許彈出視窗。 3. 確認登入資訊(使用者名稱・密碼) 用於控制台登入的使用者名稱和密碼 可在服務詳細資訊畫面中確認。 ① 使用者名稱(例:root)/② 密碼(顯示・複製) 使用者名稱:顯示於畫面的「使用者名稱」欄位(例:root)。 密碼:可從密碼欄位右側圖示顯示或複製。 注意:在控制台輸入密碼時,即使輸入也不會顯示在畫面上(這是標準 Linux 規格)。 4. 等待連線完成 控制台啟動後,畫面中央可能會顯示「連線中…」。 在此期間無法操作,請保持等待。 ① 等待「連線中…」消失 5. 登入控制台 連線完成後,控制台將顯示 login: 提示符號。 ① 顯示 login: 後開始登入操作 點擊黑色畫面(控制台區域),將鍵盤輸入焦點放在該處。 在 login:...

虛擬機電源操作

Last Updated: 2026年6月9日

概要 從客戶端入口網站(伺服器詳細資料畫面)執行伺服器電源操作的步驟說明。 目標畫面(伺服器的詳細資料畫面) 從左側選單的服務選擇目標 VPS/雲端, 開啟伺服器的詳細資料畫面(例:NVPS663)。 事前準備・注意事項 關機/重新啟動前,請先停止 OS 上執行中的處理並儲存資料。 強制關閉不執行 OS 的結束處理就切斷電源,有資料損毀的風險。通常請優先使用關機。 操作後可能需要一些時間才會反映。請點選畫面內的更新來更新狀態。 畫面右上顯示「伺服器正在執行工作」期間,請勿同時執行其他電源操作。 關機 伴隨 OS 結束處理的正常關閉電源。 步驟 點選伺服器詳細資料畫面右上的More。 從顯示的選單點選關機。 顯示確認對話框後點選OK。 確認重點 狀態變更為SHUTDOWN等,顯示工作執行中。 完成後狀態變為關閉。 啟動 從電源關閉狀態啟動。 步驟 確認狀態為關閉。 點選畫面右上的啟動。 確認重點 狀態變更為STARTING等。 完成後狀態變為開啟。 重新啟動 重新啟動 OS(VM 的重新啟動操作)。 步驟 確認狀態為開啟。 點選畫面右上的重新啟動。 顯示確認對話框後點選OK。 確認重點 狀態變更為REBOOTING等。 完成後,狀態恢復為開啟。 強制關閉 不執行 OS 的結束處理就切斷電源。僅在正常關機無法停止時才執行。 重要: 強制關閉可能造成資料損毀或檔案系統不一致。 通常請優先使用關機。 步驟 點選狀態欄的電源開關(顯示為開啟的切換開關)。 顯示確認對話框後點選OK。...

OS 範本列表

Last Updated: 2026年6月9日

作業系統範本清單 您可以從以下作業系統範本立即部署虛擬機。本公司的範本以伺服器用途(最小配置/無圖形介面)為基本設定。 重要:標準安全規格(所有範本通用) 本公司範本為了保持初始狀態的安全性與營運的一致性,採用以下標準規格。 1) 作業系統內防火牆(初始設定) 預設情況下,作業系統內的防火牆功能(例如:ufw / firewalld 等)為停用狀態。 初始狀態的存取控制主要由網路側防火牆(本公司控制)執行。 當然,您也可以根據需要在客戶端啟用作業系統防火牆進行營運。 補充說明:啟用作業系統內防火牆時,請注意不要封鎖 SSH 等您自己的管理存取。 2) 網路側防火牆(標準政策) 本公司為了防範濫用(Abuse)並維持基礎設施穩定營運,在網路側套用標準政策。 接收(IN / Inbound) 預設:拒絕(DROP) 初始允許(標準): SSH:TCP/22(IN 允許) ICMP:IN 允許(連線確認・路由控制用途) 初始狀態下,除了 SSH 和 ICMP 以外的接收流量將被封鎖。如需進行網頁公開(80/443)等,請從控制面板的網路防火牆新增允許規則。 傳送(OUT / Outbound) 標準:允許清單(白名單)方式 預設允許的傳送(標準): DNS:UDP/53, TCP/53 NTP:UDP/123 HTTP:TCP/80 HTTPS:TCP/443 QUIC / HTTP3:UDP/443 ICMP:OUT 允許(連線確認・路由控制用途) 除上述以外的傳送通訊原則上會被封鎖。如需新增傳送埠,請透過支援票證申請(視用途、目的地、期間等進行審查,可能為附條件允許)。 補充說明:基於異常偵測、上游要求、攻擊防禦等原因,可能會限制 ICMP 的類型(Type/Code)或通訊條件。 3) SSH 認證(僅限金鑰認證) SSH...

開立工單

Last Updated: 2026年6月9日

Client Portal Guide 客戶入口網站:支援工單新建指南 本操作手冊說明如何從客戶入口網站新建(開啟)支援工單的方法。 提示: 本操作手冊使用生成式 AI 等工具製作,畫面截圖中的註解(箭頭、框線、編號等)位置可能與實際畫面略有偏差。本手冊旨在協助理解操作流程,實際操作時請以畫面顯示內容與文字說明為準。 前提條件 能夠登入客戶入口網站 已準備好詢問內容(主旨/內文) 必要時已準備好附件檔案(螢幕截圖或日誌等) 操作步驟 1. 從左側選單開啟「支援工單」 登入客戶入口網站。 點擊左側選單(說明)內的「支援工單」。 開啟「支援工單」選單。 2. 點擊「新建」 在支援工單列表畫面右側點擊「新建」。 從「新建」開始建立工單。 3. 選擇詢問對象的「部門」 從顯示的「部門」列表中,點擊符合詢問內容的部門。 範例:關於 VPS 的詢問 → BESTNET-CLOUD 選擇符合詢問內容的部門。 4. 輸入主旨和訊息 在主旨中輸入詢問要點。 在訊息中輸入詳細內容(發生日期時間、狀況、重現步驟、錯誤訊息、影響範圍等)。 輸入主旨和訊息。 5. 視需要設定相關服務、CC 及附件檔案 相關服務:選擇對應的服務(例:VPS)(選填)。 其他郵件收件者(CC):若希望通知相關人員,請以逗號分隔輸入電子郵件地址(選填)。 附件:新增螢幕截圖或日誌(選填)。 可附加的副檔名 .jpg / .gif / .zip / .png / .pdf 補充說明 在訊息欄位中可以透過複製貼上的方式貼上螢幕截圖(依環境可能會有不同行為)。...

輕量級零信任營運模型導入指南

Last Updated: 2026年6月9日

※本文根據本公司內部討論、經驗及一般安全性原則彙整而成。並非特定企業、組織的官方見解,也不代表特定廠商的內部實作。 ✅ 免責聲明 本文內容旨在介紹資訊系統的一般設計與營運思維,並不保證對所有組織的安全性與適用性。 實際導入時,建議根據自身組織規模、產業、風險承受度、法規及合約義務等因素,諮詢專家意見並進行內部審查。 對於因依據本文進行之營運、設定、組織變更等所導致的任何損害,作者及所屬組織概不負責。 前言:一人「全知」狀態既強大又危險 在基礎架構、雲端、安全性領域中,「無所不能、無所不知的”神級工程師”」往往備受重視。 然而,這同時也潛藏著以下風險: 該人員離職後營運將無法運作(Bus Factor 為 1) 權限過度集中,誤操作或事件發生時影響致命 從安全性角度來看,形成「內部犯罪風險」高的結構 在大型雲端服務、金融機構、SWIFT 等領域,為避免此問題,「任何人都無法掌控全局的架構」已逐漸成為常識。 不過,同樣做法若直接套用於中小型組織,管理成本將暴增,現場將難以負荷……這也是現實情況。 因此,本文整理了**即使中小型至中型組織也易於導入的「輕量零信任分割模型」**。 模型目標 本模型的目標是達成以下狀態。 ✅ 消除一人「全知且全能操作」的狀態 ✅ 日常營運不會過於複雜 ✅ 緊急時能確實應對(考慮緊急處理) 「零信任」聽起來或許很誇張,但在此只需理解為“人員與系統都僅能存取所需資源”即可。 步驟1:將角色分為 3 類(領域分割) 首先從超簡單的方式開始,將系統分為 3 個領域來思考。 A. 基礎架構負責人 虛擬化平台(VMware / Proxmox / Hyper-V 等) 作業系統(Linux / Windows) 儲存 基本網路 備份平台 B. 應用程式負責人 Web / API 伺服器 中介軟體(nginx...

共同使用條款(網域名稱註冊/SSL憑證發行服務)

Last Updated: 2026年6月9日

使用條款 本規約規定網域名稱註冊服務及 SSL 憑證發行服務的使用條件。 最終更新日 2026年2月19日 適用開始日 2026年2月19日 事業者 BESTNET LLC(以下稱「本公司」) 所在地 宮城縣大崎市田尻大貫字北長根161-1 聯絡方式 一般支援: 支援工單 / Abuse 通報窗口: info@bestnetllc.co.jp 第1條(目的・適用範圍) 本規約規定本公司提供的網域名稱註冊服務及 SSL 憑證發行服務(以下合稱「本服務」)的使用條件。 本服務受上級註冊商、註冊管理機構、憑證授權機構(CA)、ICANN 等第三方制定的規則・政策・程序(以下稱「第三方規則」)的影響。客戶在使用本服務時,應遵守第三方規則。 本規約、本公司的說明(申請畫面・價格表・常見問題等)、第三方規則的內容發生矛盾時,就該網域名稱或 SSL 憑證而言,第三方規則優先適用。 本服務附帶提供 DNS 服務、郵件轉發等附屬服務的情況。附屬服務的提供條件・範圍遵照本公司的說明或另行規定的條件。 客戶進行申請操作或使用本服務時,視為客戶已同意本規約。 第2條(定義) 本規約使用的用語定義如下。 客戶:使用本服務的個人或法人。 網域名稱:在網際網路上使用的字串識別符。 註冊管理機構:管理各頂級網域(TLD)註冊資訊的機構。 上級註冊商:本公司為提供本服務而使用的、與註冊管理機構直接簽約的認證註冊商(包含本公司另行指定的業者)。 SSL 憑證:憑證授權機構(CA)發行的公開金鑰憑證。 憑證授權機構(CA):發行・管理 SSL 憑證的業者。 註冊資訊:指註冊管理機構或憑證授權機構等要求的申請資訊(姓名・名稱、地址、電話號碼、電子郵件地址、組織資訊、認證用資訊等)。 發行完成:SSL 憑證由憑證授權機構發行,客戶可透過本公司的管理畫面等取得的狀態。 註冊完成:網域名稱在註冊管理機構端完成註冊,客戶可確認註冊資訊等的狀態。 第3條(申請・契約成立) 客戶在本服務申請畫面輸入必要事項,按下「同意」「訂購」等按鈕後,完成規定費用的付款手續時,本服務的使用契約即告成立。 本公司合理判斷符合以下各款任一情形時,可不承諾申請,或即使承諾後也可取消。 申請內容有虛假或重大錯誤的情形 判斷屬於反社會勢力等的情形 過去曾因違反本規約等而受到本服務使用停止・解約等處分的情形 依第三方規則不允許註冊・發行等的情形...

頻寬限制升級

Last Updated: 2026年6月9日

目前正在建立中

AgentSeek WebGUI 建置步驟 (Windows 11)

Last Updated: 2026年6月9日

STEP1. 概要流程 啟用 WSL 2 與必要的 Windows 功能 安裝 Docker Desktop(WSL 2 後端) 複製 AgentSeek 儲存庫並準備 Python 虛擬環境 (venv) 使用 Docker Compose 啟動「前端 + Redis + SearxNG」 手動確認 FastAPI 後端 → 使用 NSSM 轉為 Windows 服務 將 BACKEND_URL 變更為 host.docker.internal:8000 以與前端連動 重新啟動測試與營運確認 STEP2. 前提環境檢查 項目 參考版本 確認指令 Windows 11 22H2 以後 winver PowerShell 5.1+ $PSVersionTable.PSVersion...

Ubuntu 24+Firecrawl / Bull Board 升級步驟

Last Updated: 2026年6月9日

(Ubuntu 24 ― 單節點 / systemd / Playwright MS) 前提條件 已在 /home/firecrawl 建置完成,且 systemd 服務 firecrowl-server・firecrowl-workers・firecrowl-playwright 正在運作中 Node.js 20 & pnpm 10 已安裝 Redis 在 localhost:6379 運作中 STEP 0 停止服務 & 備份 sudo systemctl stop firecrowl-server firecrowl-workers firecrowl-playwright cd /home sudo cp -r firecrawl firecrawl_backup_$(date +%Y%m%d) STEP 1 更新儲存庫至最新版本 註冊安全目錄(僅首次) git config --global --add safe.directory...

從 ISO 檔案安裝並設定 OpenSE 虛擬路由器

Last Updated: 2026年6月9日

前提: 使用 Bestnet Cloud 時,可以從標準提供的 ISO 檔案中安裝 OPNsense 虛擬路由器。 本程序記載從虛擬機器建立到 ISO boot 安裝與初期設定的流程。   STEP1. 建立虛擬機器 依照下列順序進行,即可建立 OPNsense 虛擬機器。 1、建立新伺服器 2、輸入任意主機名稱 3、輸入預計設定的密碼(OPNsense 不支援自動設定密碼,需登入 OS 後手動設定) 4、SSH 金鑰管理(OPNsense 不支援 SSH 金鑰自動管理,需手動設定) 5、OS 範本選擇 請選擇 OPNsense-25.1-dvd-amd64.iso 6、配置運算資源 7、interface net0 請配置 PublicIP(s)。 8、請點擊「建立新虛擬機器」。   STEP2. 為 LAN 建立額外的介面 在已建立的虛擬機器概要頁面中,前往「網路」→「介面」,請點擊「新增網路介面」。 接著,從 Public IP(s) 中將要配置的地址改為選擇您合約的雲端實例所配置的私有網路,並請點擊「Assign new IP」。 最後點擊「新增網路介面」即完成。   STEP3. OS 安裝...

將 AI Engine 的 OpenAI 端點替換為 Dify 的 OpenAI 相容 API 端點

Last Updated: 2026年6月9日

STEP1: 更新前務必取得備份 將目前已修改為可運作狀態的 openai.php 儲存為檔案。例如:以 openai.php-dify 等名稱複製至本機。 建議對整個 WordPress 或外掛程式資料夾進行完整備份,以便在發生問題時可以還原。 STEP2: 更新 AI Engine 從 WordPress 管理畫面的「外掛程式」更新 AI Engine (Meow Apps),或透過 SFTP/SSH 等方式覆寫新版本。 更新後請確認外掛程式已啟用。 STEP3: 由於 openai.php 會被初始化,需重新套用 方法A: 手動反映差異 參考修改前(已確認運作)的 openai.php-dify,在新的 openai.php 的對應位置(build_url()、build_headers() 等)進行新增・覆寫修正。 由於 AI Engine 的更新可能新增了變更,請注意不要完全替換。僅手動重現差異部分。 方法B: 使用補丁檔案或 Git 事先使用 diff / git 建立修改內容的補丁。 更新後以 patch < openai.patch 的方式套用,重新進行相同變更。這是半自動化最可靠的方法。 更新後的 openai.php 檔案路徑:...

Dify 外掛程式常駐程序的執行緒洩漏因應措施

Last Updated: 2026年6月9日

  問題概述 發生現象: 當索引大量知識庫文件時,外掛程式守護程序(plugin_daemon)會持續產生無數執行緒,最終在「約 30,000 個」時無法建立新執行緒。 容器日誌中出現 can't start new thread 錯誤,服務凍結。 推測原因: 容器/cgroup v2 的 pids.max(處理程序+執行緒上限)設定為 29958(約 3 萬),超過此值時執行緒建立失敗。 外掛程式守護程序端的執行緒洩漏,或因大量並行處理導致執行緒數在短時間內激增。 嘗試與錯誤: 即使在 Docker Compose 或容器內調整 pids_limit: 0 或 ulimit,由於主機的 cgroup 固定為 29958,因此沒有效果。 確認 /sys/fs/cgroup/system.slice/docker-.scope/pids.max 的實際值後,發現為 29958。 根本解決方案 修正外掛程式守護程序端的執行緒洩漏(套用更新或修補程式)。 將一次處理的文件數分批處理,避免執行緒數過度增長。 當前因應措施 變更主機的 cgroup 設定,將 pids.max 提升至 max(無限制)或較大的值。 同時在 systemd 的 slice 單元(如 system.slice)中設定 TasksMax=infinity,確保重新啟動後不會恢復原值。 因應措施步驟(逐步指南)...

在 Ubuntu 24.04 上安裝 Dify 並啟用 HTTPS

Last Updated: 2026年6月9日

STEP1. 系統前提 Ubuntu 24.04 Docker, Docker Compose 網域(例:test.bestnetllc.co.jp) Let’s Encrypt SSL 憑證 STEP2. OS 和 Docker 的安裝 OS 的更新 sudo apt-get update sudo apt-get upgrade -y sudo apt-get autoremove -y sudo apt-get autoclean sudo reboot Docker 和 Docker Compose 安裝 sudo apt-get update sudo apt-get install -y ca-certificates curl gnupg lsb-release curl -fsSL https://download.docker.com/linux/ubuntu/gpg |...

在 Ubuntu 上將使用 Bolt.new/diy 建立的應用程式投入正式營運

Last Updated: 2026年6月9日

整體流程 準備開發所需的環境 取得原始碼並安裝相依套件 在開發伺服器上確認運作 建立正式環境建置 設定 Nginx 並發布建置完成的檔案 HTTPS 支援(視需要而定) 重新啟動時自動啟動(視需要而定) 以下的操作手冊將提供具體的作業範例。 STEP1. 準備開發環境 STEP1.1 安裝 Node.js 和 npm 若使用 Ubuntu,可透過以下指令安裝 Node.js 和 npm。 sudo apt update sudo apt install -y nodejs npm 安裝後確認版本。 node -v npm -v STEP1.2 準備伺服器 準備 Ubuntu 等 Linux 伺服器,並確保能夠透過 SSH 登入。 (以正式營運為前提)請準備具有 root 或 sudo 權限的使用者。 STEP2. 取得原始碼 STEP2.1...

在 Ubuntu 24 上安裝 FireCrawl

Last Updated: 2026年6月9日

本程序以下列配置為最終目標。 在 Ubuntu 24 上安裝 FireCrowl (API 伺服器 & 工作處理程序) Node.js 安裝於整個系統,全域使用 pnpm 導入 Rust 工具鏈(rustup 等),建置 FireCrawl 的 Rust 製 HTML 轉換函式庫(html-transformer) 安裝 Playwright 的相依套件,並建立自訂的 Playwright 微服務腳本 建立 2 個 FireCrowl 啟動用的 systemd 服務(伺服器用 & 工作處理程序用), 作業系統啟動時自動啟動 可手動執行 sudo systemctl restart firecrowl-server / sudo systemctl restart firecrowl-workers 等指令 (選用) +-----------------+ | Dify | +-----------------+...

在 Rocky Linux 9.3 上安裝 NVIDIA 驅動程式與 CUDA

Last Updated: 2026年6月9日

安裝步驟 STEP1. 新增官方NVIDIA軟體庫 將適用於Rocky Linux 9的NVIDIA官方CUDA軟體庫註冊至系統。執行以下指令後,將會新增CUDA(NVIDIA)軟體庫。 sudo dnf config-manager --add-repo http://developer.download.nvidia.com/compute/cuda/repos/rhel9/$(uname -i)/cuda-rhel9.repo 執行後,/etc/yum.repos.d/中將新增NVIDIA的軟體庫定義檔案,之後即可從此軟體庫安裝套件。 STEP2. 安裝必要套件 安裝NVIDIA驅動程式建置與CUDA使用所需的開發套件。首先啟用EPEL(Extra Packages for Enterprise Linux)軟體庫,以及包含開發系套件的CRB(CodeReady Builder)軟體庫。 這將使dkms等必要元件可供使用。 sudo dnf config-manager --set-enabled crb sudo dnf install -y https://dl.fedoraproject.org/pub/epel/epel-next-release-latest-9.noarch.rpm 接著,安裝與目前執行中核心對應的標頭檔與開發套件,以及開發工具類。 透過以下指令,將安裝核心標頭檔、核心開發套件(kernel-devel)、編譯器(gcc/g++)、DKMS及其他必要工具($(uname -r)將被替換為目前的核心版本)。 sudo dnf install -y kernel-headers-$(uname -r) kernel-devel-$(uname -r) make automake gcc gcc-c++ dkms pciutils elfutils-libelf-devel libglvnd-devel libglvnd-opengl libglvnd-glx bzip2 tar...

BESTNET-VPS 頻寬限制、傳輸量、額外流量費用

Last Updated: 2026年6月9日

最後更新日期:2025-12-19 1. 連接埠速度(頻寬) 各 VPS (虛擬專用伺服器) 的網路為 1Gbps 共享(盡力而為) 由於是共享環境,無法保證持續 1Gbps 2. 每月傳輸量(收發合計) 本服務的傳輸量以 發送+接收的合計(IPv4/IPv6 合算) 計量。 2.1 標準傳輸量上限(收發合計) NVPS-16:6TB / 月 NVPS-32:12TB / 月 NVPS-64:18TB / 月 NVPS-96:24TB / 月 ※ 可能以「1TB=1000GB」顯示(依照管理畫面顯示)。※ 計量對象原則上為透過公共介面連接至網際網路的通訊。 3. 達到 80% 時的通知 當達到每月傳輸量上限的 80% 時,將自動通知至註冊的電子郵件地址。(例:NVPS-16 的情況,約達到 4.8TB 時) 4. 超過上限時的頻寬限制 當超過每月傳輸量上限時,該 VPS (虛擬專用伺服器) 將在 計費期間月底前限制為最大 2.5MB/s。 2.5MB/s ≒ 約相當於...

備份與快照 注意事項

Last Updated: 2026年6月9日

最後更新日期:2025-12-19 1. 需要您了解的事項 備份:從故障、誤操作中恢復的「保險」(保存至不同區域) 快照:更新前的暫時保存、回復用的「檢查點」(主要用於短期用途)快照雖然很方便,但無法取代備份。 2. 標準備份(自動・每日) 2.1 標準規格 每日自動備份:1 代(前一日份) 為標準附帶 提供從備份進行 還原功能 2.2 保存位置與方式 備份採用實體上獨立的運算基礎設施方式 2.3 備份注意事項 備份為盡力服務,不保證所有資料的恢復 備份取得時的應用程式一致性(資料庫的一致性等)取決於客戶的系統配置 重要系統建議在應用程式端進行停止/清除/一致化等處理 還原原則上會恢復至目標時間點,因此還原目標的現有資料將被覆寫 3. 額外備份世代(選配) 額外保存範例:每 1 代 +NT$22 / 月 ※實際價格以合約畫面或客戶入口網站上的升級畫面為準。 範例: 保留 7 代:額外 6 代 → +NT$133/月 保留 14 代:額外 13 代 → +NT$288/月 ※保留世代的上限、套用時機、刪除(輪替)動作以合約畫面・管理畫面顯示為準。※減少保留世代數時,舊的世代可能會被刪除。 4. 快照(手動/營運用) 4.1 標準規格 快照:標準最多 1 個...

將團隊「擬似BMI」化的話題

Last Updated: 2026年6月9日

※本文內容基於筆者個人經驗與觀點,不代表所屬組織或特定廠商的官方見解。此外,這裡介紹的方法不保證對所有組織都有效且安全。實際導入時,請根據貴公司的狀況、合約、法規、安全政策等進行判斷。 前言:最浪費的其實是「認知同步」這個問題 在本公司這種基礎架構、應用程式、儲存混雜的現場工作時,經常會遇到這樣的情況。 「這個最後到底是根據什麼方針決定的?」 「那張工單進展到哪裡了?」 「這個設計,不知道是誰基於什麼前提思考的…」 比起實作時間,更多時間消耗在「認知同步」上的感覺,你有過嗎? 於是突然產生了一個想法, 「如果能把相關工程師的大腦和身體連結起來,作為集合體行動不是最強嗎?」 這已經是偏向科幻的發想了。當然,在現實中透過 Brain Machine Interface (BMI) 將大腦物理連結還是相當遙遠的未來。 不過,如果結合工具、營運和文化,應該能接近「類似連結的狀態」吧?因此,我們針對 10 人以下的團隊,思考了一個「類 BMI 團隊營運模型」。 目標團隊的條件 這次假設的團隊大致如下。 成員:10 人以內 角色:基礎架構、應用程式、儲存混雜(雲和地端都會接觸) 使用工具(範例) GitHub Slack Notion Teams / SharePoint(與其他部門或外部協作用) Nextcloud(檔案共享等) 簡單來說,假設的是**「全員什麼都碰的全端型小團隊」**。 概念:在外部建立團隊的「集合大腦」 希望達成的狀態用一句話來說, 「減少只存在某人腦中的資訊」,將其集中到團隊整體的「外部大腦」。 就是這樣。 代替 BMI, 工具(GitHub / Slack / Notion / 儀表板) 協定(如何流通資訊) 文化(如何行動) 組合這些要素,建立**「類似連結的狀態」**。 工具的角色分擔:將哪裡視為「大腦」 首先,為手邊的工具明確分配角色。 1. GitHub:任務、程式碼與決策的「中樞神經」 Issue...

©2020 BESTNET.LLC . All Rights Reserved.