從我們佩塔提夸和內坦亞節點（AS206446）的 TCP 檢測，嘗試對指定埠的 SYN-ACK 交握，並測量連線時間。這從以色列電信業者基礎設施驗證埠級可達性——適用於確認應用埠對以色列使用者是否開放，以及診斷來自該地區的連線問題報告。TCP 檢測反映實際防火牆規則和路由行為，不像基於 ICMP 的 Ping。

來自以色列的預期 TCP 交握時間：至法蘭克福地區目標約 52–60 ms、至阿姆斯特丹約 58–66 ms、至倫敦約 63–70 ms、至美國東岸約 128–138 ms。這些反映了沒有排隊延遲的基礎電纜 RTT。比這些基準完成更快的 TCP 檢測，表明目標透過 Anycast 路由至本地或區域邊緣——例如，Cloudflare 前置的服務將在本地特拉維夫 PoP 在 5 ms 以內完成 TCP 交握。

從以色列的 TCP 失敗而歐洲埠可到達，通常由以下原因造成：防火牆或安全群組封鎖中東或非歐盟 ASN、GeoIP 策略限制以色列 IP 空間，或雲端供應商區域限制。與我們的土耳其和阿聯酋地區節點比對，有助確定封鎖是否特定於以色列或適用於更廣泛的中東 IP 範圍。

以色列的網際網路基礎設施集中在特拉維夫都會區，全國主要的 IX 設施、資料中心和電信業者機房均位於此。IIX（以色列網際網路交換中心）運營主要對等互連架構，供國內 ISP、內容供應商和 CDN PoP 使用。ISUOG 作為次要 IX。兩者均位於特拉維夫都會走廊，以色列電信業者和主機代管基礎設施的大部分均實體設於此。我們的探測節點所在的佩塔提夸和內坦亞，兩城市相距約 15 公里，均在此都會集中區內。

以色列的國際連線幾乎完全透過海底電纜出境。FLAG 和 SEA-ME-WE 電纜系統在海法和特拉維夫上岸，透過地中海提供前往歐洲的主要容量。次要路徑透過西奈半島的埃及陸上路由。特拉維夫至法蘭克福的路徑在路由良好的電纜容量上約 50–60 ms。特拉維夫至倫敦約 60–68 ms。特拉維夫至紐約透過跨大西洋電纜約 125–135 ms。這些 RTT 與南歐位置相當，使以色列在歐洲 CDN 基礎設施的有用範圍內。

主要以色列電信業者包括運營主要國內固定線路骨幹的 Bezeq International（AS8551）、Partner Communications（AS12400）、HOT Telecom（AS5486）和 Cellcom。商業 ISP 和主機代管市場由包括 CLOUD LEASE（AS206446）在內的其他業者服務，CLOUD LEASE 託管我們兩個探測節點。AS206446 是在佩塔提夸和內坦亞有存在的雲端主機代管和主機代管業者，兩者都透過以色列國內骨幹連接，並向 IIX 和國際閘道進一步過境。

以色列的固定線路平均寬頻速度在該地區最高，由廣泛的光纖部署和競爭性的 ISP 定價驅動。以色列市場的對等互連狀況對其地理位置而言異常良好——透過海底電纜靠近歐洲，以及積極參與 IIX，意味著許多歐洲 CDN 邊緣以與南歐使用者相當的延遲服務以色列。Akamai、Cloudflare 和 AWS 均在特拉維夫地區維護邊緣 PoP。

我們在以色列運營兩個探測節點——一個在佩塔提夸，一個在內坦亞——均透過 CLOUD LEASE（AS206446）。在同一 AS 和都會區有兩個節點，意味著結果通常一致，但同時執行兩者可確認沒有任何節點有本地路由異常。對於有 Anycast 或 GeoDNS 的目標，鑑於兩個節點的地理接近性和共享上游，兩者應返回相同或幾乎相同的結果。