When Submarine Cables Go Dark: Understanding and Preparing for the Risks of Taiwan's International Internet Disconnection

We collected connection data from 2,179 websites commonly used in Taiwan. The results show that 39.3% are “foreign-dependent,” with foreign resource exposure and relatively high direct failure risk under cable-outage scenarios. Another 49.6% are “cloud-dependent”: no foreign resource requests were observed, but they rely on local nodes of multinational public clouds or CDNs, so their actual availability when international connectivity fails is highly uncertain.

This study provides a scalable, reproducible measurement method for quantifying observable foreign dependencies and comparing dependency structures across websites. The results can inform policy and industry resilience planning and support continued tracking of resilience improvements.

Taiwan is a highly digitalized society; the Internet and the information systems built on it are a critical foundation for how society operates. Digital dependence keeps growing: as of 2024, fixed broadband household penetration reached 74.5%¹; mobile broadband penetration 87.12%; overall Internet usage rose from 67.2% in 2006 to 88.75%².

From waking to sleep, people constantly use networked screens to access and exchange information. The network is embedded in daily life and social activity. Communications, commerce, media, logistics, and public and government services all rely on digital systems online.

High connectivity means any sizable, sustained network outage can significantly impact the economy and society.

When someone opens an app (e.g. Line, the most popular messaging app in Taiwan, with over 98.2% usage rate¹) on a phone and sends a message, a chain of network requests is triggered.

First, the app asks the OS to connect; the device queries the carrier DNS for the target server IP (e.g. Line). After obtaining the address, it opens a TCP/IP connection and sends the request.

Data leaves the phone over wireless to a nearby cell site, then enters the carrier’s fiber backbone and core. Because Line’s main servers are abroad (Japan), traffic is routed to an international gateway—e.g. Tamsui or Toucheng cable landing stations—and crosses submarine cables overseas.

After reaching the destination country, traffic lands again and enters a cloud provider’s data center (e.g. AWS, Google Cloud, Azure). The app server processes the request; the response returns along a similar path and is rendered by the OS and the app.

This often completes in a fraction of a second. Unnoticed by users, data may travel thousands of kilometers round-trip between Taiwan and Japan—or tens of thousands of kilometers to another continent and back.

More importantly, one tap on an app or site can trigger dozens or hundreds of parallel requests, each repeating the above pattern. Most everyday digital services are effectively cross-border systems; “instant” interaction depends heavily on international links and submarine cables.

As noted, many sites and apps used daily depend on foreign resources and international connectivity. Losing external connectivity would likely break most digital services.

As an island, over 99% of Taiwan’s external traffic relies on submarine cables³. Cable resilience therefore directly affects everyday service availability and broader societal resilience.

Submarine cables are multi-layer cables a few centimeters thick on the seabed, or buried one to three meters in shallow water. In busy shallow areas such as the Taiwan Strait, damage often comes from human activity—anchoring, fishing, dredging—and from natural wear, amplifier failure, earthquakes, landslides, and geopolitical risk. Human causes dominate cable damage in Taiwan⁴.

According to the Taiwan Submarine Cable Map (smc.peering.tw), Taiwan is almost always in a state where “at least one cable is impaired”⁵. Cable faults may be a chronic background condition, not rare exceptions.

Availability of all international submarine cables serving Taiwan, 2025/3/18–2026/3/18 (source: Taiwan Submarine Cable Map (smc.peering.tw), cable status timeline).

Taiwan connects globally through fourteen international cables via landing stations at Tamsui, Bali, Toucheng, and Fangshan (another station is under construction in Dawu, Taitung), plus ten domestic cables to Penghu, Kinmen, Matsu, and other outlying islands⁶ (RNAL and FNAL are two systems on one physical cable; MODA counts them separately, yielding fifteen international systems in some counts).

Under normal conditions, the Internet’s meshing, redundancy, diversity, and connectivity let carriers reroute traffic over other cables when a few fail. Quality may drop without users noticing. However, when multiple cables fail together, bandwidth redundancy is quickly exhausted, causing severe congestion or large-scale outages affecting communications, logistics, government operations, and digital systems⁷.

According to repair-time benchmarks published by the Ministry of Digital Affairs⁸, average repair time is about 32 days for international cables and about 110 days for domestic cables linking outlying islands. Disruptions can therefore last for months or even quarters, and contingency planning should assume a monthly rather than daily timescale.

A recent multi-cable failure occurred from 2025-12-25 to 2026-01-03: earthquakes off Yilan damaged six international cables (including EAC1, SJC2, PLCN, F/RNAL, EAC2, Apricot—nearly half of cables)⁴. Users reported slower networks and blocked apps, with repairs not completed until May 2026.

The 2006 Hengchun earthquakes remain a landmark case: on 2006-12-26 at 20:26 and 20:34, two magnitude-7 quakes off southwest Hengchun triggered many aftershocks. Mainland damage was relatively light, but underwater landslides broke four of six external cables at the time.

Taiwan’s international connectivity was severely disrupted. Initial call completion to the U.S. was about 40%; to China and Japan about 10%. China, Hong Kong, Japan, Korea, and Southeast Asia were also hit hard. Google, Yahoo, MSN, Gmail, Wikipedia, and other major services saw major outages across the region, affecting trade and finance.

Eight cable ships joined repairs; full restoration took nearly two months by mid-February 2007⁹. The UN ISDR director called submarine cable damage from the quake a new modern-type disaster¹⁰.

Both events show that even without total blackout, simultaneous multi-cable failure can cause severe congestion and widespread service degradation.

The early 2023 Matsu outage is a real-world case of complete external cable loss for a region.

Two cables linking Matsu to Taiwan were damaged on 2023-02-02 and 2023-02-08 by Chinese fishing vessels, cutting regional Internet and telecom except for very limited microwave capacity (2 Gbps), leaving most residents unable to get online¹¹. One cable (Taiwan–Matsu 3) was repaired after about 50 days at end of March.

Taiwan–Matsu 2 and 3 total about 1 Tbps. After 2023, microwave was expanded to 12 Gbps. When both cables failed again on 2025-01-15 and 2025-01-22, the larger microwave link kept some connectivity¹².

At the beginning of the 2006 incident, Chunghwa Telecom reallocated capacity on the ST-1 communications satellite to support international telephone service, briefly restoring partial availability for international voice calls. If a similar-scale incident happened today, could satellites still serve as a substitute?

Under the Taiwan Space Agency’s (TASA) “B5G LEO communications satellite program”¹³, Taiwan plans to launch two experimental LEO satellites before 2030 with a three-year design life.

Former TASA chair Tsung-Tsong Wu estimated that 24/7 nationwide LEO coverage would require at least 120 satellites, with roughly 40 replacements per year for a three-year lifetime—far above current plans, so it is hard to build substantive backup connectivity on that scale¹⁴.

Bandwidth also differs by orders of magnitude. A modern cable may carry hundreds of Tbps; Apricot is designed for 211 Tbps¹⁵. Starlink capacity was estimated around 20 Gbps in 2023 research—roughly 10,000× less per comparable unit; the full Starlink constellation (~3,300 satellites in 2023) was estimated around 20 Tbps total, comparable to one cable system¹⁶.

Even summing current LEO satellite bandwidth (Gbps class) cannot replace transoceanic cable throughput (Tbps class). TWNIC chair Kenny Huang compared cables to reservoirs and satellites to pipes¹². Satellites can support emergency government or regional links, not national-scale replacement.

In 2006, the main economic impact of lost international connectivity was disrupted international telephone service—finance and select industries—with overseas internet services affecting only a minority of users.

In twenty years, dependence on the Internet has grown sharply. Taiwan’s international bandwidth grew from 147.7 Gbps in 2006 to 10.6 Tbps in 2026—nearly 70×¹⁷. Meanwhile, average cable damage in Taiwan is about 5.1 times per year versus a global average of 0.1–0.2—roughly 25–50× higher risk³.

Deloitte (2016) estimated that a full national Internet outage in a highly digitalized country could cost about USD 23.6 million in GDP per day per ten million people—roughly USD 55 million per day for Taiwan, or about USD 1.7 billion per month, before accounting for semiconductor supply-chain and cross-border finance spillovers¹⁸.

The same work notes that even partial outages or bandwidth reduction hurt productivity, transactions, information access, and confidence.

Taiwan is more Internet-dependent and faces more frequent cable damage risk. A 2006-scale event today would affect far more than niche industries, with broader societal impact and much harder emergency response and alternative routing than in 2006.

Public discussion of cable outages has increased, but often stays at “communications difficulties”—Line/Messenger/WeChat, Google, Gmail, Office 365—similar to 2006 framing.

Academic resilience work often focuses on infrastructure or intermediary layers: cable topology, routing, DNS19²⁰, CDN and cloud centralization. That implies: if infrastructure is up and reachable, services work.

Routing is decentralized and imperfect; failures are routine. Policy constraints mean routing errors, misconfiguration, or node faults can cause large outages without physical cuts. Infrastructure health alone does not equal service availability²¹.

Even with spare cables, traffic reshaping, routing policy, or concentrated paths can still block communication—“physically connected” ≠ “actually reachable”²²; redundancy alone does not guarantee cross-border availability²³.

Modern stacks span infrastructure, logical, and application layers; societal impact exceeds any single operator. Resilience is a public-good problem across layers, operators, and borders⁷.

Indices such as the Internet Resilience Index use national infrastructure, performance, security, and market structure as proxies²⁴ but do not directly measure whether sites people use daily still load when international connectivity is constrained.

Policy analyses focus on national infrastructure, topology, repair capacity, alternatives, and geopolitical risk—emphasizing bandwidth redundancy, path diversity, repair, and cooperation²⁵.

Third-party dependency research (e.g. DNS, CDN, certificate authorities) highlights concentration and single points of failure²⁶: over 89% of sites depend on third parties for critical functions; top three providers support over 90%²⁷; multi-level indirect dependencies can amplify failures²⁸.

Resilience must include service availability under constrained external connectivity and third-party state—not only physical reachability. This study emphasizes “service availability under constrained connectivity”, developing application-layer methods to ask which everyday digital services—and what share—could remain usable when external links fail, and how cable outages may affect network and societal resilience.

The challenge we face is not “will cables break?” but service collapse risk: in a highly digital, cloud-heavy, cross-border-dependent society, when external connectivity is severely impaired, which services keep basic function, which degrade, and which fail outright?

Past debate focused on bandwidth, physical damage, and backup communication methods. Modern services are not “a local server serving static HTML.” A “Taiwan” site or app may run on global cloud regions across datacenters and depend on hosts, CDNs, third-party JavaScript, login, payments, analytics, push, AI APIs, and other external components. Any critical piece abroad or reachable only via foreign paths can fail unexpectedly during cable outages.

Under severely congested or broken international links, repairing or rebuilding systems becomes harder.

Impact cannot be judged only by “how many spare cables remain.” Services may fail due to routing, DNS, congestion, cloud dependencies, or unreachable external assets even when the physical network is not fully down. Beyond connectivity, we need user-facing service availability measurements.

Without understanding real impact, we cannot prepare. This study turns “what happens when cables go dark” into measurable, comparable technical questions—filling an application-layer gap in resilience discourse. Through a test framework, it estimates how commonly used services may load, degrade, or fail when foreign connectivity is lost, providing evidence for backup design, resilience investment, and policy and social readiness.

When an island nation highly dependent on international networks, such as Taiwan, experiences severe degradation, instability, or partial interruption of its external submarine-cable connectivity—and thus loses access to much of the global Internet—to what extent do commonly used domestic websites continue to operate, degrade, or fail?

We aim to systematically test and count international-facing components in service operation—CDNs, third-party APIs, cloud platforms, external libraries—and map dependency structure and potential availability risk for commonly used services under foreign-network isolation.

The work should give government, industry, and civil society concrete evidence on systemic impact of external connectivity loss, supporting resilience strategy for digital services and critical public sectors.

Two core themes:

1. Degree of dependence on foreign-hosted resources
2. Degree of dependence on Taiwan nodes of multinational public clouds and CDNs, and what that implies for resilience

Three concrete questions:

1. Under “Taiwan external connectivity severely impaired or cut,” what share of commonly used sites exhibit foreign resource dependency exposure at thehomepage level?
2. Is dependency on local nodes of multinational public clouds and CDNs concentrated in specific service ecosystems ?
3. Do different site types, such as .gov.tw government websites,.edu.tw education websites, and general services, showsystematic differences in foreign-resource dependency rates?

This study uses a programmatic browser to observe the distribution of resource requests generated while loading each homepage. A homepage is the first user-visible point of interaction with a service and includes some of the front-end resources required for basic rendering and interaction. We treat this observation as a scalable proxy indicator for comparing dependency exposure across a large number of websites. However, it does not include the complete backend architecture or cloud control-plane dependencies and therefore cannot be interpreted directly as overall service availability.

We compiled a high-traffic site list for Taiwan, including domestic and international services commonly used by locals. The target is “sites Taiwanese people use,” instead of “Taiwan sites”—so the list includes Google, Gmail, etc.

The unit of study is “websites” (Web), not direct equivalence to app availability. (OCF has related work on app connectivity resilience.)

There is no authoritative “sites Taiwanese people use” list. We merged:

• Tranco List²⁹ — global top 1M list, from which we use 2,510 entries ending in.tw .
• Cloudflare Radar — Taiwan traffic top 100 list
• AhrefsTop — Taiwan organic search top 100 list
• SimilarWeb — Taiwan top 50 list
• Semrush — Taiwan top 100 list

This campaign used ranking snapshots obtained from each source on 2026-07-20. Before merging, hostnames were lowercased and a leading www. was removed, while other subdomains were preserved. Duplicate hostnames were merged into one entry while retaining the source-specific rankings. The resulting merged_lists_tw.json contains 2,467 sites.

We also use manual_curated_list_tw.json to include 42 manually selected open-source and digital-resilience community cases, including OCF, SITCON, and g0v. Two hostnames overlap with the automatically ranked list.

Together, the two lists contain 2,507 unique websites. The lists and scripts are open source in top-traffic-website-list-taiwan.

Tests used typical Taiwanese residential connectivity:

• Chunghwa Telecom fiber 500M/500M
• Locations: Zhonghe District, New Taipei; Zhongzheng District, Taipei
• DNS: 168.95.1.1
• Environment details recorded in logs for comparison and reproduction

Site availability depends not only on establishing connections, but on fetching dependent resources (JavaScript, CSS, images, APIs). Modern sites combine resources from many domains; together they determine what users see and can do. Prior work uses headless browsers to analyze request behavior and third-party dependencies30²⁷.

Building on dependency-exposure analysis from resource requests, we extend it to the systematic scenario of “international connectivity failure” and its potential impact on service availability.

Backend architecture, data paths, control planes, and internal cloud behavior are not directly observable externally. We do not attempt to map full system dependencies; we focus on observable front-end network requests and build operational metrics from them.

Two core metrics:

1. Foreign Dependency Exposure

   Whether homepage requests include foreign-hosted resources—exposure to foreign networks at the resource layer.

2. Cloud Local Endpoint Exposure

   Whether requests hit Taiwan nodes of multinational public-cloud or CDN providers—exposure to sites hosted on, or dependent on, their local endpoints.

These describe “dependency exposure structure” at the homepage front-end resource layer, not full system architecture or actual failure modes.

We can classify sites into three categories based on the above metrics:

1. Foreign-dependent

   Foreign resource exposure: homepage load directly depends on foreign resources. Such sites are directly exposed to unavailable resources when external connectivity is severely degraded or interrupted, making them the most likely to be affected immediately and the category with the highest direct risk.

2. Cloud-dependent

   No foreign resource exposure, but cloud local endpoint exposure: homepage loads show no foreign resource requests, yet use resources from Taiwan nodes of multinational public-cloud or CDN providers. Sites appear localized, but availability still depends on control planes, origins, authentication, and cache persistence—“surface-local, cross-border uncertainty”.

3. Locally-contained

   No foreign resource exposure and no multinational-cloud local-endpoint exposure. Such sites have a higher chance of local operation, but full-system availability during external outages is not guaranteed.

Tools and projects:

• top-traffic-website-list-taiwan — compile Taiwan commonly used site lists
• web-resilience-test — website resilience testing tool
• web-resilience-test-profile — compile test results into static pages
• resilience.ocf.tw — public lookup site for results

We developed web-resilience-test to open each target homepage site-by-site with a programmatic headless browser and record all resource connections during load.

Next, the tool processes all resource requests collected during page loading. It excludes blob: and other unparsable requests, as well as requests matching the ad-filter rules or the manual exclusion list. It then deduplicates the requests, retaining only one request per hostname within each website; each unique website-hostname pair constitutes one observation.

The tool then uses IPinfo, provider-specific response headers, the LACeS anycast API³¹, and ping RTT to determine the geographic location and classification of each observation.

Finally, the tool aggregates all test results into statistical tables. The detailed workflow follows.

no-global-connection-check.js tests one site:

1. Initialization
   • Environment setup; load exclusion domain list
   • Normalize target URL (e.g. add https:// )
2. Page load and request capture
   • Playwright headless Chromium opens the site
   • Listen to request for all request metadata including headers
3. Retries and errors
   • 4xx responses are treated as test failure and logged
   • Other errors: retry in this order:
     • Headless / non-headless browser
     • URL with/without www. prefix
   • If all four variants still fail, log the error and skip to the next site
4. Request cleanup
   • For each page's request data, perform the following cleanup:
     • Drop blob: requests
     • Exclude unparsable requests
     • Match requests against the configured adblock domain lists to remove advertisements and related unnecessary resources
       • This campaign used LowTechFilter hosts ABP version 2026.0720.1 and a 2026-07-20 snapshot of theAdGuard DNS Filter . Together, the two lists contained 158,521 distinct domain rules
     • This campaign used
     • If the target website's hostname appears in the lists, requests to hostnames with a parent or child relationship to the target are retained to avoid blocking the website's own resources
     • Exclude hostnames on the manual exclusion list. This study lists only the web-font hostname fonts.gstatic.com , because its failure is less likely to affect core website functionality than failures of scripts, APIs, or content resources. Future studies can use the same mechanism to add other exclusions
     • Deduplicate requests by hostname; each unique website-hostname pair is one observation
   • Drop
5. For each page's request data, perform the following cleanup:

6. Domain location

   • For each observation's hostname, call the IPinfo API to obtain its geographic location and ASN information
   • If the result shows country=TW , record it as a domestic connection
   • Compare the ASN against cloud_providers_tw.json registry version 0.1.0, dated 2026-01-05, to determine whether it belongs to the multinational cloud/CDN category. The registry contains 30 international public-cloud, CDN, and hosting providers and excludes Taiwan-only providers
   • If the result shows a country other thanTW and its ASN belongs to one of the following six providers with local Taiwan nodes, apply the advanced classification steps:
     • Google (AS15169, AS396982, AS19527), Cloudflare (AS13335, AS209242), Amazon (AS16509, AS14618), Fastly (AS54113), Akamai (AS16625, AS20940, AS32787), or Microsoft (AS8075)
   • Headers: inspect response headers such as cf-ray ,x-amz-cf-pop ,x-served-by ,x-azure-ref , andx-msedge-ref for known cloud location markers. A value containingTPE indicates a Taiwan node
   • Anycast: if headers are inconclusive, query the LACeS Anycast Census API³¹ to determine whether the endpoint is a local anycast resource; iflocations includes Taiwan andconfidence isconfident , classify it as domestic

   • RTT: if the preceding methods are inconclusive, ping the resource 5× and take the minimum RTT. Classify it as domestic when RTT < 15 ms ; otherwise, retain the foreign classification

     Note: we built the cloud_providers_tw.json ASN registry using complete request data from earlier tests. It is open source for use by other research and projects.

7. For each observation's hostname, call the
8. Classification and resilience metrics
   • Based on the preceding information, classify each unique website-hostname observation as one of: domestic/cloud ,domestic/direct ,foreign/cloud ,foreign/direct
     • “cloud” means the ASN in IPinfo org is listed incloud_providers_tw.json underproviders_intl orproviders_intl_without_known_taiwan_region/pop
   • “cloud” means the ASN in IPinfo
   • Count the total observations in each category for every website and save the results to test-results/<site>.json
9. Based on the preceding information, classify each unique website-hostname observation as one of:
10. Errors
    • Failures are logged to test-results/_error/<site>.error.json
    • Common errors include:
      • Cloudflare challenge : target site uses Cloudflare's challenge protection mechanism to prevent abuse.
      • HTTP 4xx
      • Timeout
11. Failures are logged to

RTT is the final stage of location classification: a target cloud or CDN endpoint enters RTT only when IPinfo, provider-specific response headers, and LACeS cannot determine its location. The test tool pings the endpoint five times and uses the minimum RTT. It is reclassified as an international public-cloud node in Taiwan only when the minimum RTT is below 15 ms; otherwise, it remains classified as foreign.

Across 2,179 successfully tested websites, the browser recorded 262,926 raw HTTP requests. The filtering described above and within-site hostname deduplication produced 19,046 unique website-hostname observations for classification. Of these, 3,640 observations from 976 distinct hostnames across 1,243 websites entered the RTT fallback stage; details are in the table below.

The distribution of the 3,064 measured RTTs is shown below. Each point is one successful measurement; the horizontal axis is an observation index, and the vertical axis is logarithmic. Values are bimodal; the 10–30 ms transition range holds 130 observations (4.2%).

Based on this distribution, we use a relatively conservative < 15 ms threshold within the sparse interval to classify a resource as domestic, reducing the risk of misclassifying a foreign resource as domestic.

Without RTT correction (equivalent to a 0 ms threshold), every resource entering RTT fallback retains its foreign classification, producing 1,370 foreign-dependent websites and 566 cloud-dependent websites. Applying the 15 ms threshold reclassifies 514 websites (23.6%) from foreign-dependent to cloud-dependent, resulting in 856 and 1,080 websites in the two categories, respectively.

The table further tests sensitivity to the selected RTT threshold. Relative to the 15 ms baseline used in this study, a 10 ms threshold moves only 27 websites (1.2%) from cloud-dependent to foreign-dependent, while a 20 ms threshold moves only five websites (0.2%) from foreign-dependent to cloud-dependent. The locally-contained count is unchanged. The aggregate classification therefore differs only slightly across the 10, 15, and 20 ms thresholds.

batch-test.js runs single-site tests over the list and writes test-results/statistic.tsv. From that batch output we derive overall foreign-dependency rates and per-resource resilience status.

We use web-resilience-test-profile to compile individual static pages and host them at https://resilience.ocf.tw/ for public lookup of each site’s resilience (e.g. Will ocf.tw work if cables break?).

At ~2,000 sites, when running with default parallelism (4 parallel tests, 8 parallel static page compilations), it takes about 30–60 minutes to complete. The latest test results are published at web-resilience-test-result and resilience.ocf.tw.

Of 2,507 unique sites tested, 2,179 completed successfully.

• Data as of: 2026-07-21
• Testing site lists:
• Summary of testing results: statistic.tsv@eb30e97
• Public cloud statistics: asn_taiwan_ratio.tsv@eb30e97

Within the measured results, 39.3% are “foreign-dependent,” with foreign resource exposure and high direct failure risk under cable outages; 49.6% are “cloud-dependent”—no foreign resource exposure was observed, but they rely on in-Taiwan nodes of multinational public clouds or CDNs, so availability is highly uncertain. Only 11.2% are “locally-contained,” with no observed exposure and a higher chance of normal operation. Overall, 88.8% of sites warrant further attention as high-risk or high-uncertainty.

Foreign-dependent: sites hosted abroad or whose homepages request foreign resources. They are exposed to international connectivity degradation or interruption and face high failure risk.

Cloud-dependent: no direct foreign resource exposure, but loading pulls resources from Taiwan nodes of multinational public-cloud or CDN providers. Topologically domestic, yet control planes, origins, authentication, or cache persistence may still depend on foreign systems—“localized in appearance, uncertain in availability”.

Locally-contained: no dependency exposure was observed among front-end resources. The site itself appears to be domestic and not hosted on a multinational public cloud, and it does not request foreign resources or resources from domestic nodes of multinational clouds. It therefore has a higher chance of continued operation, although this category does not account for complete backend dependencies and cannot establish that the service will continue operating.

Among Category 2 (cloud-dependent) sites, requests to different international public-cloud nodes in Taiwan break down as follows:

• Google Cloud Platform (Taiwan nodes): 965 sites
• Cloudflare (Taiwan nodes): 480 sites
• Amazon Web Services (Taiwan nodes): 138 sites
• Akamai (Taiwan nodes): 104 sites
• Microsoft Azure (Taiwan nodes): 38 sites
• Fastly (Taiwan nodes): 4 sites

Provider site counts are non-exclusive: one site may use more than one provider, so the rows must not be added to obtain a site total.

Of 1,323 sites with no foreign dependency, 965 use resources from GCP Taiwan nodes (72.9%).

If public-cloud services such as GCP cannot keep local nodes running during external network outages, the impact would be very high. Their resilience is a key factor in whether sites can continue operating during submarine-cable disruptions.

For resources requested from domestic and international nodes of multinational public clouds, we found the following distribution:

A site may request both domestic and international nodes from the same provider, so the two columns overlap and must not be added to obtain a provider total.

For Google cloud resources, measured by request count, 7,393 of 7,456 Google requests were classified as domestic-node requests, or about 99.2%; 63 were international-node requests, or about 0.8%. This shows the practical value of CDN-based data localization, and makes the persistence of mirrored resources on Taiwan nodes a key factor in whether ordinary sites remain available when external links are congested or cut.

Public-cloud services with lower domestic resource shares should be further evaluated for full in-country mirroring, cache persistence, and contingency operations.

For this comparison, global cloud includes the multinational public-cloud and CDN providers compiled for this study, while other/local covers all other providers. A website is counted in a cell when at least one of its observations belongs to that group:

87.7% of sites depend on global-cloud resources: 86.3% depend on resources from domestic global-cloud endpoints, and 34.6% depend on resources from foreign global-cloud endpoints.

Among the 856 sites with foreign resource exposure, most also use domestic resources; only 39 use foreign resources exclusively, accounting for just 1.8% of all 2,179 sites. This shows the practical value of CDN contributions to data localization and benefits for service resilience.

Among the 18,969 unique website-hostname observations with provider information from IPinfo, dependencies are highly concentrated among large providers. Provider labels are normalized from IPinfo ASN organization data. Providers above 5% include Google, Cloudflare, Amazon, Chunghwa Telecom (CHT), and Facebook. Google has the highest observation share at 39.7%, followed by Cloudflare at 16.4% and Amazon at 10.4%.

Per-site inspection shows that Google resources mainly include services such as GTM, while Cloudflare provides infrastructure and services such as cdnjs JavaScript CDN and WAF. These common infrastructure services form key parts of contemporary internet-service resilience.

To assess the resilience of government and education sites, we first looked only at foreign resource connectivity:

• Among the test results, 235 were government sites (gov.tw and*.gov.tw ); 16 had foreign connectivity, or 6.8%.
• 255 were education sites (*.edu.tw ); 34 had foreign connectivity, or 13.3%.

Government and education sites depend less on foreign resources than the overall population. This suggests that public-sector and academic-network environments have a stronger baseline for local availability, although full service resilience still requires checking backend dependencies and real usage workflows.

Based on this study’s findings, we identify the following policy and technical recommendations to improve the resilience of Taiwan’s overall digital services.

Overall, the main risk for websites commonly used in Taiwan does not come only from a small number of fully foreign-hosted services. It is more widely embedded in dependency structures involving foreign resources and Taiwan-based nodes of multinational public clouds. Resilience strategies should therefore go beyond asking whether a service is “in Taiwan,” and further examine whether its resource supply chain, cloud control planes, and critical user journeys can continue operating locally.

1. Support related research to continuously monitor the resilience of commonly used and critical services, and routinely publish both aggregate and per-service results.
2. Support follow-up research to develop deeper resilience testing frameworks for user journeys such as login, transactions, browsing, and search, in order to conduct further availability testing.
3. For Taiwan nodes of heavily used international public-cloud providers such as Google, Cloudflare, Amazon, and Akamai, provide policy requirements and budget support to verify and improve service availability during external network outages.
4. Provide policy requirements and budget support to reduce critical domestic services’ dependence on foreign resources and improve their local resilience.
5. Encourage or require critical domestic services to establish local backup mechanisms or recovery plans, and conduct periodic disconnection drills.
6. Based on local-availability validation, define resilience tiers, such as A: fully usable; B: degraded but usable; C: homepage loads but interactions fail; D: immediate failure, and include them in procurement and acceptance criteria for government and public services.
7. Establish an extreme-case bandwidth-priority plan in advance, given that backup satellite capacity is far below submarine-cable capacity.
8. For highly critical international public-cloud services operated by providers such as Google, Cloudflare, Amazon, and Akamai, contingency plans for external connectivity failures should be developed and regularly exercised.
9. Website builders should consider the resilience risks of using foreign resources. When loading frameworks or libraries, they can prioritize CDN services with Taiwan-based nodes, or establish fallback mechanisms that switch to local resources when a library fails to load, reducing the impact of external connectivity outages.
10. Service developers can prioritize data localization for critical service paths, such as login and checkout, to improve resilience and service quality.

Main limitations:

1. This study observes the source locations of website requests, not full network paths such as traceroute, nor routes from abroad via VPN. Whether “domestic” resources or pages are anycast/CDN nodes still needs further testing.
2. The 15 ms RTT cutoff is a fallback heuristic, not physical proof of endpoint location. Routing changes, congestion, or nearby foreign nodes can affect individual measurements, although the threshold sensitivity analysis shows limited aggregate impact.
3. “Foreign dependency” and “cloud dependency” here refer to front-end observable exposure, not full backend architecture. Even locally-contained sites by front-end metrics may still rely on foreign databases, APIs, or backend services. The 11.2% locally-contained group cannot be assumed to remain available during external outages.
4. Resources and webpages hosted on Taiwan nodes of multinational public-cloud services do not guarantee that the service can operate independently during submarine-cable or international connectivity outages. Observing a Taiwan endpoint shows only that some front-end resources can be obtained domestically. Actual availability may still depend on:
   • Whether control-plane services, including authoritative DNS, configuration, and logging, rely on foreign systems
   • Whether the origin and dynamic content are located abroad
   • Whether cache hit ratio, cache persistence, and cache revalidation require international connectivity
   • Whether identity and access management, token validation, session handling, and other authentication processes rely on foreign services
   • Other foreign dependencies that may affect service availability
5. This study does not perform fault-injection tests that simulate a loss of international connectivity, such as using VPN or DNS techniques to make foreign resources unreachable. As a broad survey of many websites, it estimates potential risk from dependency structures rather than directly observing service degradation during a forced connectivity outage.
6. This study tests homepages only, not full user journeys such as login, transactions, browsing, or search. Results should therefore be treated as “initial availability” indicators based on dependency exposure among resources involved in initial service access, not as measurements of complete service availability.

Suggested follow-ups:

• Combine fault injection with journey-based testing, such as login, transactions, browsing, and search, to observe actual availability.
• Study the resilience of major cloud-service architecture, including control planes, origins, cache defaults, and authentication.
• Use traceroute to analyze full resource paths.
• Analyze the usage and node distribution of common front-end libraries and frameworks, such as jQuery, Bootstrap, Tailwind, React, and Vue, to identify shared foreign-service single points of failure.
• Compare dependency patterns by resource type, such as document, script, image, XHR, font, and stylesheet.
• Identify high-traffic, low-resilience sites.
• Add more Taiwan traffic data, such as the Chrome CrUX user experience dataset.
• Develop a service-criticality framework that classifies services into categories such as government, finance, communications, video streaming, news, e-commerce, social media, and search engines; weights them by security, economic, and social importance; compares resilience across categories; and calculates an overall resilience index.

1. National Communications Commission (NCC), 2025 Communications Market Report (in Chinese),https://commsurvey.ncc.gov.tw/files/file_pool/1/0p336342530469870607/251201%20%20114年通訊傳播市場報告_網站上傳版.pdf↩1↩2
2. TWNIC, 2025 Taiwan Internet Report – Overall Usage (in Chinese),https://report.twnic.tw/2025/TrendAnalysis_internetUsage.html↩
3. CNA, “Experts: Submarine cables are Taiwan’s ‘digital lifeline’; 99% of bandwidth depends on them” (in Chinese), https://www.cna.com.tw/news/aipl/202501100036.aspx↩1↩2
4. Ministry of Digital Affairs, 2025 Analysis and Policy Report on Submarine Cable Damage in Taiwan (in Chinese),https://www-api.moda.gov.tw/File/Get/moda/zh-tw/kj9vSvBw5wUeqla↩1↩2
5. Taiwan Submarine Cable Map, cable status timeline ,https://smc.peering.tw/↩
6. Ministry of Digital Affairs, latest cable status (in Chinese),https://moda.gov.tw/major-policies/subseacable/1747↩
7. Center for Technology, Science, and Energy, American Enterprise Institute, Beyond Infrastructure: Internet Ecosystem Resilience and the Public Good ,https://ctse.aei.org/beyond-infrastructure-internet-ecosystem-resilience-and-the-public-good/↩1↩2
8. Ministry of Digital Affairs, average submarine cable repair times in Taiwan (in Chinese),https://moda.gov.tw/press/bulletin/17998↩
9. OFCA Hong Kong, press release (in Chinese), Internet Archive,https://web.archive.org/web/20070217181311/http://www.ofta.gov.hk/zh/press_rel/2007/Feb_2007_r4.html↩
10. MSN/CNA via Internet Archive, expert on 2006 quake cable damage (in Chinese),https://web.archive.org/web/20070210045300/http://news.msn.com.tw/cna/cna_full_text.asp?yy=07&mm=02&dd=08&name=000030↩
11. Wen Lii, Facebook post (in Chinese),https://www.facebook.com/wen1949/posts/pfbid0C1juirBxeTdoaarQnzXpWBdR7C8xodHPJ3Ctrh93kF7hdeU6547KiC8SwRRvBjwfl↩
12. The Reporter, Undersea cable damage and Taiwan’s digital lifeline (in Chinese),https://www.twreporter.org/a/damaged-undersea-cables-raises-alarm-in-taiwan↩1↩2
13. TASA, LEO satellite (in Chinese),https://www.tasa.org.tw/zh-TW/missions/detail/Beyond-5G-LEO-Satellite↩
14. Taipei Times, TASA to launch six satellites from 2026 ,https://www.taipeitimes.com/News/front/archives/2024/05/13/2003817776↩
15. Federal Communications Commission, PUBLIC NOTICE: Actions Taken Under Cable Landing License Act SCL-00512 ,https://docs.fcc.gov/public/attachments/DA-25-60A1.pdf↩
16. Denys Rozenvasser, Kateryna Shulakova, Estimation of Starlink Global Satellite System Capacity ,https://opendata.uni-halle.de/bitstream/1981185920/103863/1/1_9%20ICAIIT_2023_paper_4290.pdf↩
17. TWNIC, bandwidth registration checking system (in Chinese),https://map.twnic.tw/main02.php↩
18. Cary Stier, The economic impact of disruptions to Internet connectivity (Deloitte, Oct 2016),https://www.deloitte.com/content/dam/assets-shared/legacy/docs/perspectives/2022/economic-impact-disruptions-to-internet-connectivity-deloitte.pdf↩
19. David Conrad, Towards Improving DNS Security, Stability, and Resiliency ,https://www.internetsociety.org/wp-content/uploads/2021/01/bp-dnsresiliency-201201-en_0.pdf↩
20. Lars Kröhnke, Jelte Jansen, Harald Vranken, Resilience of the Domain Name System: A Case Study of the .nl-domain ,https://doi.org/10.1016/j.comnet.2018.04.015↩
21. Jian Wu, Ying Zhang, Z. Morley Mao, Kang G. Shin, Internet Routing Resilience to Failures: Analysis and Implications ,https://conferences.sigcomm.org/co-next/2007/papers/papers/paper25.pdf↩
22. Dan Pei, Lixia Zhang (UCLA), Dan Massey (USC/ISI), A Framework for Resilient Internet Routing Protocols ,https://web.cs.ucla.edu/~lixia/papers/04IEEENetwork.pdf↩
23. Erin L. Murphy, Redundancy, Resiliency, and Repair: Securing Subsea Cable Infrastructure , Center for Strategic and International Studies,https://www.csis.org/analysis/redundancy-resiliency-and-repair-securing-subsea-cable-infrastructure↩
24. Internet Society Pulse, Pulse Internet Resilience Index ,https://pulse.internetsociety.org/en/resilience/#about-the-internet-resilience-index↩
25. Charles Mok, Kenny Huang, Strengthening Taiwan's Critical Digital Lifeline: An Analysis of Taiwan's Undersea Cable Network Resilience , Stanford Global Digital Policy Incubator Cyber Policy Center,https://fsi9-prod.s3.us-west-1.amazonaws.com/s3fs-public/2024-08/undersea-cables-mok_huang-v4.pdf↩
26. Aqsa Kashaf, Jiachen Dou, Margarita Belova, Maria Apostolaki, Yuvraj Agarwal, Vyas Sekar, A First Look at Third-Party Service Dependencies of Web Services in Africa , Carnegie Mellon University, Princeton University,https://netsyn.princeton.edu/sites/g/files/toruqf3201/files/documents/pam23_0.pdf↩
27. Rashna Kumar, Sana Asif, Elise Lee, Fabián E. Bustamante, Third-party Service Dependencies and Centralization Around the World , Northwestern University,https://arxiv.org/abs/2111.12253↩1↩2
28. Aqsa Kashaf, Vyas Sekar, Yuvraj Agarwal, Analyzing Third Party Service Dependencies in Modern Web Services: Have We Learned from the Mirai-Dyn Incident? ,https://doi.org/10.1145/3419394.3423664↩
29. Victor Le Pochat, Tom Van Goethem, Samaneh Tajalizadehkhoob, Maciej Korczyński, and Wouter Joosen, Tranco: A Research-Oriented Top Sites Ranking Hardened Against Manipulation , Proceedings of the 26th Annual Network and Distributed System Security Symposium (NDSS 2019),https://doi.org/10.14722/ndss.2019.23386↩
30. Yasin Alhamwy, Paul Mertens, Oliver Hohlfeld, Poster: Web Dependency Analyzer to Identify Resource Dependencies and their Impact on Rendering ,https://doi.org/10.1145/3646547.3689683↩
31. Remi Hendriks, Matthew Luckie, Mattijs Jonker, Raffaele Sommese, and Roland van Rijswijk-Deij, LACeS: An Open, Fast, Responsible and Efficient Longitudinal Anycast Census System , Proceedings of the 2025 ACM Internet Measurement Conference (IMC '25),https://doi.org/10.1145/3730567.3764484↩1↩2