管理 Microsoft 365 端點
大部分具有多個辦公室位置和連線 WAN 的企業組織都需要設定 Microsoft 365 網路連線能力。 您可以透過防火牆直接傳送所有受信任的 Microsoft 365 網路要求，略過所有額外的封包層級檢查或處理，藉此優化您的網路。 這會降低延遲和您的周邊容量需求。 識別 Microsoft 365 網路流量是為使用者提供最佳效能的第一個步驟。 如需詳細資訊，請參閱 Microsoft 365 網路連線原則。
Microsoft 建議您使用 Microsoft 365 IP 位址和 URL Web 服務存取 Microsoft 365 網路端點，並持續變更這些端點。
無論您如何管理重要的 Microsoft 365 網路流量，Microsoft 365 都需要網際網路連線。 需要連線的其他網路端點會列在 Microsoft 365 IP 位址和 URL Web 服務中未包含的其他端點。
使用 Microsoft 365 網路端點的方式取決於您的企業組織網路架構。 本文概述商業網路架構可與 Microsoft 365 IP 位址和 URL 整合的數種方式。 若要選擇要信任的網路要求，最簡單的方式是在每個辦公室位置使用支援自動化 Microsoft 365 設定的 SD-WAN 裝置。
適用于重要 Microsoft 365 網路流量之本機分支輸出的 SD-WAN
在每個分公司位置，您可以提供設定為將 Microsoft 365 優化端點類別或優化和允許類別的流量直接路由至 Microsoft 網路的 SD-WAN 裝置。 其他網路流量，包括內部部署資料中心流量、一般網際網路網站流量，以及流向 Microsoft 365 預設類別端點的流量，都會傳送至您具有更大量網路周邊的另一個位置。
Microsoft 正與 SD-WAN 提供者合作，以啟用自動化設定。 如需詳細資訊，請參閱Microsoft 365 網路合作夥伴計畫。
使用 PAC 檔案直接路由傳送重要的 Microsoft 365 流量
使用 PAC 或 WPAD 檔案來管理與 Microsoft 365 相關聯但沒有 IP 位址的網路要求。 一般而言，透過 Proxy 或周邊裝置傳送的網路要求會增加延遲。 雖然 TLS 中斷和檢查會產生最大的延遲，但 Proxy 驗證和信譽查閱等其他服務可能會導致效能不佳和不良的使用者體驗。 此外，這些周邊網路裝置需要足夠的容量來處理所有網路連線要求。 建議您略過 Proxy 或檢查裝置，以直接要求 Microsoft 365 網路。
PowerShell 資源庫 Get-PacFile是 PowerShell 腳本，可從 Microsoft 365 IP 位址和 URL Web 服務讀取最新的網路端點，並建立範例 PAC 檔案。 您可以修改指令碼，使它與您現有的 PAC 檔案管理整合。
注意事項
如需直接連線到 Microsoft 365 端點的安全性和效能考慮詳細資訊，請參閱 Microsoft 365 網路連線原則。
圖 1 - 簡單的企業網路周邊
PAC 檔案已在圖 1 的第 1 點部署至 Web 瀏覽器。 使用 PAC 檔案直接輸出重要的 Microsoft 365 網路流量時，您也需要允許連線到網路周邊防火牆上這些 URL 後方的 IP 位址。 若要這麼做，請擷取 PAC 檔案中所指定之相同 Microsoft 365 端點類別目錄的 IP 位址，並根據這些位址建立防火牆 ACL。 防火牆是圖 1 中的第 3 點。
另外，如果您選擇只執行優化類別端點的直接路由，則任何必要的允許您傳送至 Proxy 伺服器的類別端點都必須列在 Proxy 伺服器中，才能略過進一步的處理。 例如，TLS break 和 Inspect 和 Proxy Authentication 與 Optimize 和 Allow 類別端點不相容。 Proxy 伺服器是圖 1 中的第 2 點。
常見的設定是允許，而不處理來自 Proxy 伺服器的所有輸出流量，以取得到達 Proxy 伺服器之 Microsoft 365 網路流量的目的地 IP 位址。 如需 TLS 中斷和檢查問題的相關資訊，請 參閱在 Microsoft 365 流量上使用協力廠商網路裝置或解決方案。
腳本產生的 PAC 檔案有兩種 Get-PacFile 類型。
| 類型 | 說明 |
|---|---|
| 1 |
傳送 [最佳化] 端點流量導向，並將其餘項目傳送到 Proxy 伺服器。 |
| 2 |
傳送 [最佳化] 和 [允許] 端點流量導向，並將其餘項目傳送到 Proxy 伺服器。 此類型也可用來將所有支援的 Microsoft 365 ExpressRoute 流量傳送至 ExpressRoute 網路區段，以及將其他所有流量傳送至 Proxy 伺服器。 |
以下是呼叫 PowerShell 指令碼的簡單範例：
Get-PacFile -ClientRequestId b10c5ed1-bad1-445f-b386-b919946339a7
您可以將許多參數傳遞至腳本：
| 參數 | 說明 |
|---|---|
| ClientRequestId |
這是必要項目，且是傳遞至 Web 服務的 GUID，代表正在進行呼叫的用戶端電腦。 |
| Instance |
Microsoft 365 服務實例，預設為全球。 這也會傳遞至 Web 服務。 |
| TenantName |
您的 Microsoft 365 租使用者名稱。 傳遞至 Web 服務，並在某些 Microsoft 365 URL 中當做可取代的參數使用。 |
| Type |
您要產生的 Proxy PAC 檔案類型。 |
以下是使用更多參數呼叫 PowerShell 腳本的另一個範例：
Get-PacFile -Type 2 -Instance Worldwide -TenantName Contoso -ClientRequestId b10c5ed1-bad1-445f-b386-b919946339a7
Microsoft 365 網路流量的 Proxy 伺服器略過處理
如果 PAC 檔案不用於直接輸出流量，您仍然想要藉由設定 Proxy 伺服器來略過網路周邊的處理。 某些 Proxy 伺服器廠商已啟用此功能的自動化設定，如Microsoft 365 網路合作夥伴計畫中所述。
如果您手動執行此動作，您必須從 Microsoft 365 IP 位址和 URL Web 服務取得優化和允許端點類別資料，並將 Proxy 伺服器設定為略過這些專案的處理。 請務必避免優化和允許類別端點的 TLS 中斷和檢查和 Proxy 驗證。
Microsoft 365 IP 位址和 URL 的變更管理
除了為您的網路周邊選取適當的設定之外，您必須為 Microsoft 365 端點採用變更管理程式。 這些端點會定期變更。 如果您未管理變更，則在新增 IP 位址或 URL 之後，最終可能會導致使用者遭到封鎖或效能不佳。
Microsoft 365 IP 位址和 URL 的變更通常會在每個月的最後一天發佈。 有時候，因為作業、支援或安全性需求，變更會在該排程之外發佈。
發佈需要您因新增 IP 位址或 URL 而採取動作的變更時，您應該會在發佈變更的 30 天后收到通知，直到該端點上有 Microsoft 365 服務為止。 這會反映為生效日期。 雖然我們的目標是此通知期間，但不一定是因為操作、支援或安全性需求所致。 不需要立即採取動作來維護連線能力的變更，例如已移除的 IP 位址或 URL 或較不顯著的變更，不包含預先通知。 在這些實例中，不會提供任何生效日期。 無論提供何種通知，我們都會列出每個變更的預期服務生效日期。
使用 Web 服務變更通知
您可以使用 Microsoft 365 IP 位址和 URL Web 服務來取得變更通知。 建議您每小時呼叫 /version Web 方法一次，以檢查您用來連線到 Microsoft 365 的端點版本。 如果此版本相較於您使用的版本有所變更，則應從 /endpoints Web 方法取得最新的端點資料，並選擇性地從 /changes Web 方法取得差異。 如果您找到的版本沒有任何變更，則不需要呼叫 /endpoints 或 / changes Web 方法。
如需詳細資訊，請參閱 Microsoft 365 IP 位址和 URL Web 服務。
使用 RSS 摘要變更通知
Microsoft 365 IP 位址和 URL Web 服務提供您可以在 Outlook 中訂閱的 RSS 摘要。 針對 IP 位址和 URL，每個 Microsoft 365 服務實例特定頁面上都有 RSS URL 的連結。 如需詳細資訊，請參閱 Microsoft 365 IP 位址和 URL Web 服務。
使用 Power Automate 變更通知和核准檢閱
我們了解，您可能仍需要手動處理每個月會進行的網路端點變更。 您可以使用 Power Automate 建立流程，在 Microsoft 365 網路端點有變更時，透過電子郵件通知您，並選擇性地執行變更的核准程式。 檢閱完成之後，您可以讓流程自動將變更以電子郵件傳送到您的防火牆和 Proxy 伺服器管理小組。
如需 Power Automate 範例和範本的相關資訊，請參閱 使用 Power Automate 接收 Microsoft 365 IP 位址和 URL 變更的電子郵件。
Microsoft 365 網路端點常見問題
請參閱這些關於 Microsoft 365 網路連線的常見問題。
如何提交問題？
選取底部的連結，指出文章是否有説明，並提交任何其他問題。 我們會仔細查看意見反應，並以最常見的問題更新這裡的問題。
如何判斷我的租用戶位置？
判斷租用戶位置的最佳方式是使用我們的資料中心地圖。
我與 Microsoft 的對等互連是否適當？
關於對等互連位置，在與 Microsoft 對等互連中有更詳細的說明。
有了全球超過 2500 個 ISP 對等互連關聯性及 70 個網路節點，從您的網路連接到我們的網路應該會非常流暢。 您不妨花幾分鐘確認您 ISP 的對等互連關聯性是最佳狀態，此處提供一些範例供您了解與我們網路的良好及不佳的對等互連遞交機制。
我發現網路要求的目的地 IP 位址不在已發佈清單上，我需要提供存取權給這些 IP 位址嗎？
我們只提供您應該直接路由傳送至的 Microsoft 365 伺服器 IP 位址。 這不是您會看到網路要求之所有 IP 位址的完整清單。 您會看到對 Microsoft 和協力廠商擁有、未發佈的 IP 位址的網路要求。 這些 IP 位址是以動態方式產生或管理，此方式在變更時不會即時通知。 如果您的防火牆對於這些網路要求無法允許以 FQDN 為基礎的存取，請使用 PAC 或 WPAD 檔案來管理要求。
請參閱與您想要取得詳細資訊的 Microsoft 365 相關聯的 IP 嗎？
- 使用 CIDR 計算工具 (例如用於 IPv4 或 IPv6 的這些) 檢查 IP 位址是否包含在更大的發佈範圍中。 例如，40.96.0.0/13 會包括 IP 位址40.103.0.1，儘管 40.96 不符合40.103。
- 使用 whois 查詢查看合作夥伴是否擁有該 IP。 如果是 Microsoft 所擁有，則可能是內部合作夥伴。 許多合作夥伴網路端點都會列為屬於 預設 類別，而不會發佈 IP 位址。
- IP 位址可能不是 Microsoft 365 或相依性的一部分。 Microsoft 365 網路端點發佈不包含所有 Microsoft 網路端點。
- 檢查憑證。 使用瀏覽器，使用HTTPS:// < 連線到 IP 位址IP_ADDRESS >並檢查憑證上列出的網域，以瞭解哪些網域與 IP 位址相關聯。 如果它是 Microsoft 擁有的 IP 位址，而不是在 Microsoft 365 IP 位址清單中，則 IP 位址很可能與 Microsoft CDN 相關聯 ，例如 MSOCDN.NET 或其他沒有已發佈 IP 資訊的 Microsoft 網域。 如果您發現憑證上的網域確實是我們宣稱有列出 IP 位址的網域，請通知我們。
某些 Microsoft 365 URL 會指向 CNAME 記錄，而不是 DNS 中的 A 記錄。 我需要對 CNAME 記錄執行什麼動作？
用戶端電腦需要包含一或多個 IP 位址的 DNS A 或 AAAA 記錄， () 連線到雲端服務。 Microsoft 365 中包含的某些 URL 會顯示 CNAME 記錄，而不是 A 或 AAAA 記錄。 這些 CNAME 記錄是媒介，而且鏈結中可能有數個。 它們最終一律會解析為 IP 位址的 A 或 AAAA 記錄。 例如，請考慮下列一系列的 DNS 記錄，這些記錄最終會解 析為IP 位址IP_1：
serviceA.office.com -> CNAME: serviceA.domainA.com -> CNAME: serviceA.domainB.com -> A: IP_1
這些 CNAME 重新導向是 DNS 的一般部分，並且對用戶端電腦且對 Proxy 伺服器都是透明的。 它們用於負載平衡、內容傳遞網路、高可用性和服務事件風險降低。 Microsoft 不會發佈中繼 CNAME 記錄，它們隨時都可能會變更，而且您不應該在 Proxy 伺服器中設定它們。
Proxy 伺服器會驗證初始 URL，在上述範例中為 serviceA.office.com，而此 URL 會包含在 Microsoft 365 發佈中。 Proxy 伺服器會要求 IP 位址的該 URL DNS 解析，並接收回IP_1。 它不會驗證中繼 CNAME 重新導向記錄。
Microsoft 不建議使用硬式編碼設定或使用以間接 Microsoft 365 FQDN 為基礎的允許清單，且不受 Microsoft 支援。 已知會造成客戶連線問題。 封鎖 CNAME 重新導向或不正確解析 Microsoft 365 DNS 專案的 DNS 解決方案，可以透過啟用 DNS 遞迴的 DNS 轉寄站或使用 DNS 根提示來解決。 許多協力廠商網路周邊產品會原生整合建議的 Microsoft 365 端點，以使用 Microsoft 365 IP 位址和 URL Web 服務，在其設定中包含允許清單。
為什麼 Microsoft 網域名稱內會有 nsatc.net 或 akadns.net 等名稱？
Microsoft 365 和其他 Microsoft 服務會使用 Akamai 和 MarkMonitor 等數個協力廠商服務來改善您的 Microsoft 365 體驗。 為了讓您獲得最佳體驗，我們未來可能會變更這些服務。 協力廠商網域可能會裝載內容，例如 CDN，或裝載服務，例如地理流量管理服務。 目前使用中的部分服務包括：
當您看到包含*.nsatc.net的要求時，MarkMonitor正在使用中。 這個服務提供網域名稱保護與監控功能，以防範惡意行為。
當您看到對*.exacttarget.com的要求時，ExactTarget正在使用中。 這個服務提供電子郵件連結管理與監控功能，以防範惡意行為。
當您看到包含下列其中一個 FQDN 的要求，就表示 Akamai 使用中。 這個服務提供地理位置 DNS 及內容傳遞網路服務。
*.akadns.net
*.akam.net
*.akamai.com
*.akamai.net
*.akamaiedge.net
*.akamaihd.net
*.akamaized.net
*.edgekey.net
*.edgesuite.net
我必須為 Microsoft 365 提供最小連線能力
由於 Microsoft 365 是一套建置來透過網際網路運作的服務，因此可靠性和可用性承諾是以許多可用的標準網際網路服務為基礎。 例如，DNS、CRL 和 CDN 等標準網際網路服務必須能夠連線，才能使用 Microsoft 365，就如同使用大部分新式網際網路服務必須能夠連線一樣。
Microsoft 365 套件分為主要服務區域。 這些區域可以選擇性地啟用連線，而且有一個通用區域，這是所有區域的相依性，而且一律是必要的。
| 服務區域 | 描述 |
|---|---|
| Exchange |
Exchange Online 和 Exchange Online Protection |
| SharePoint |
SharePoint Online 和商務用 OneDrive |
| 商務用 Skype Online 和 Microsoft Teams |
商務用 Skype 和 Microsoft Teams |
| 通用 |
Microsoft 365 專業增強版、瀏覽器中的 Office、Microsoft Entra識別碼和其他常見的網路端點 |
除了基本網際網路服務之外，還需要一些只用於整合功能的協力廠商服務。 雖然整合需要這些服務，但 Microsoft 365 端點一文中會將它們標示為選擇性。 這表示，如果無法存取端點，服務的核心功能會繼續運作。 任何必要的網路端點都已將必要屬性設定為 true。 任何選擇性的網路端點都會將必要屬性設定為 false，而且 notes 屬性會詳細說明當連線遭到封鎖時，您應該預期的遺漏功能。
如果您嘗試使用 Microsoft 365，但發現無法存取協力廠商服務，您想要 確保本文中標示為必要或選擇性的所有 FQDN 都可透過 Proxy 和防火牆來允許。
如何封鎖對 Microsoft 消費者服務的存取權限？
租使用者限制功能現在支援封鎖所有 Microsoft 消費者應用程式的使用， (MSA 應用程式) 例如 OneDrive、Hotmail 和 Xbox.com。 這項功能會使用 login.live.com 端點的個別標頭。 如需詳細資訊，請 參閱使用租使用者限制來管理 SaaS 雲端應用程式的存取權。
我的防火牆需要 IP 位址，且無法處理 URL。 如何?為 Microsoft 365 設定？
Microsoft 365 不會提供所有必要網路端點的 IP 位址。 某些僅提供 URL，且分類為預設。 預設類別中需要的 URL 應該允許透過 Proxy 伺服器。 如果您沒有 Proxy 伺服器，請查看如何針對使用者在網頁瀏覽器的網址列中輸入的 URL 設定 Web 要求;使用者也不會提供 IP 位址。 不提供 IP 位址的 Microsoft 365 預設類別 URL 應以相同方式設定。
相關文章
Microsoft 365 IP 位址和 URL Web 服務
意見反應
即將登場：在 2024 年，我們將逐步淘汰 GitHub 問題作為內容的意見反應機制，並將它取代為新的意見反應系統。 如需詳細資訊，請參閱：https://aka.ms/ContentUserFeedback。
提交並檢視相關的意見反應