[Docs] Fix links with broken anchors (#17059)

---------

Co-authored-by: hyperlint-ai[bot] <154288675+hyperlint-ai[bot]@users.noreply.github.com>

src/content/changelogs/r2.yaml

@@ -1,5 +1,5 @@
 ---
-link: "/r2/reference/changelog/"
+link: "/r2/platform/changelog/"
 productName: R2
 productLink: "/r2/"
 productArea: Developer platform
@@ -16,8 +16,8 @@ entries:
       - When an `OPTIONS` request against the public entrypoint does not include an `origin` header, an `HTTP 400` instead of an `HTTP 401` is returned.
   - publish_date: "2024-02-06"
     description: |-
-      - The response shape of `GET /buckets/:bucket/sippy` has changed. 
-      - The `/buckets/:bucket/sippy/validate` endpoint is exposed over APIGW to validate Sippy's configuration. 
+      - The response shape of `GET /buckets/:bucket/sippy` has changed.
+      - The `/buckets/:bucket/sippy/validate` endpoint is exposed over APIGW to validate Sippy's configuration.
       - The shape of the configuration object when modifying Sippy's configuration has changed.
   - publish_date: "2024-01-30"
     description: |-
@@ -30,7 +30,7 @@ entries:
       - Sippy is available for Google Cloud Storage (GCS) beta.
   - publish_date: "2023-12-11"
     description: |-
-      - The `x-id` query param for `S3 ListBuckets` action is now ignored. 
+      - The `x-id` query param for `S3 ListBuckets` action is now ignored.
       - The `x-id` query param is now ignored for all S3 actions.
   - publish_date: "2023-10-23"
     description: |-

src/content/compatibility-dates/dynamic-dispatch-tunnel-exceptions.md

@@ -11,4 +11,4 @@ enable_flag: "dynamic_dispatch_tunnel_exceptions"
 disable_flag: "dynamic_dispatch_treat_exceptions_as_500"
 ---
 
-Previously, when using Workers for Platforms' [dynamic dispatch API](/cloudflare-for-platforms/workers-for-platforms/get-started/dynamic-dispatch/) to send an HTTP request to a user Worker, if the user Worker threw an exception, the dynamic dispatch Worker would receive an HTTP `500` error with no body. When the `dynamic_dispatch_tunnel_exceptions` compatibility flag is enabled, the exception will instead propagate back to the dynamic dispatch Worker. The `fetch()` call in the dynamic dispatch Worker will throw the same exception. This matches the similar behavior of [service bindings](/workers/runtime-apis/bindings/service-bindings/#service-bindings) and [Durable Objects](/durable-objects/).
+Previously, when using Workers for Platforms' [dynamic dispatch API](/cloudflare-for-platforms/workers-for-platforms/get-started/dynamic-dispatch/) to send an HTTP request to a user Worker, if the user Worker threw an exception, the dynamic dispatch Worker would receive an HTTP `500` error with no body. When the `dynamic_dispatch_tunnel_exceptions` compatibility flag is enabled, the exception will instead propagate back to the dynamic dispatch Worker. The `fetch()` call in the dynamic dispatch Worker will throw the same exception. This matches the similar behavior of [service bindings](/workers/runtime-apis/bindings/service-bindings/) and [Durable Objects](/durable-objects/).

src/content/compatibility-dates/no-cfbotmanagement-default.md

@@ -14,6 +14,6 @@ disable_flag: "cf_botmanagement_default"
 
 This flag streamlines Workers requests by reducing unnecessary properties in the `request.cf` object.
 
-With the flag enabled - either by default after 2023-08-01 or by setting the `no_cf_botmanagement_default` flag - Cloudflare will only include the [Bot Management object](/bots/reference/bot-management-variables/#bot-management-variables) in a Worker's `request.cf` if the account has access to Bot Management.
+With the flag enabled - either by default after 2023-08-01 or by setting the `no_cf_botmanagement_default` flag - Cloudflare will only include the [Bot Management object](/bots/reference/bot-management-variables/) in a Worker's `request.cf` if the account has access to Bot Management.
 
 With the flag disabled, Cloudflare will include a default Bot Management object, regardless of whether the account is entitled to Bot Management.

src/content/compatibility-dates/python-workers.md

@@ -10,4 +10,4 @@ enable_date: "2024-01-29"
 enable_flag: "python_workers"
 ---
 
-This flag enables first class support for Python. [Python Workers](/workers/languages/python/#python) implement the majority of Python's [standard library](/workers/languages/python/stdlib), support all [bindings](/workers/runtime-apis/bindings), [environment variable](/workers/configuration/environment-variables), and [secrets](/workers/configuration/secrets), and integration with JavaScript objects and functions via a [foreign function interface](/workers/languages/python/ffi).
+This flag enables first class support for Python. [Python Workers](/workers/languages/python/) implement the majority of Python's [standard library](/workers/languages/python/stdlib), support all [bindings](/workers/runtime-apis/bindings), [environment variable](/workers/configuration/environment-variables), and [secrets](/workers/configuration/secrets), and integration with JavaScript objects and functions via a [foreign function interface](/workers/languages/python/ffi).

src/content/docs/cache/troubleshooting/always-online.mdx

@@ -4,44 +4,46 @@ pcx_content_type: troubleshooting
 head:
   - tag: title
     content: Always Online - Troubleshooting
-
 ---
 
 Observe the following best practices when enabling Always Online with Internet Archive integration.
 
-* **Allow requests from the Internet Archive IP addresses.** Origin servers receive requests from the Internet Archive IPs. Make sure you are not blocking requests from the Internet Archive IP range:  `207.241.224.0/20` and `208.70.24.0/21`.
-* **The Internet Archive does not consider your origin server’s cache-control header.** When the Internet Archive is crawling sites, it will crawl sites regardless of their cache-control, since the Internet Archive does not cache assets, but archives them.
-* **Consider potential conflicts with Cloudflare features that transform URIs.** Always Online with Internet Archive integration may cause issues with Cache Rules and other Cloudflare features that transform URIs due to the way the Internet Archive crawls pages to archive. Specifically, some redirects that take place at the edge may cause the Internet Archive's crawler not to archive the target URL. Before enabling Origin Cache Control, review [how Cloudflare caches resources by default](/cache/concepts/default-cache-behavior/) as well as any Cache Rules you have configured so that you can avoid these issues. If you experience problems, disable Always Online.
-* **Do not block Known Bots or Verified Bots via a WAF custom rule.** If you block either of these bot lists, the Internet Archive will not be able to crawl.
+- **Allow requests from the Internet Archive IP addresses.** Origin servers receive requests from the Internet Archive IPs. Make sure you are not blocking requests from the Internet Archive IP range: `207.241.224.0/20` and `208.70.24.0/21`.
+- **The Internet Archive does not consider your origin server's cache-control header.** When the Internet Archive is crawling sites, it will crawl sites regardless of their cache-control, since the Internet Archive does not cache assets, but archives them.
+- **Consider potential conflicts with Cloudflare features that transform URIs.** Always Online with Internet Archive integration may cause issues with Cache Rules and other Cloudflare features that transform URIs due to the way the Internet Archive crawls pages to archive. Specifically, some redirects that take place at the edge may cause the Internet Archive's crawler not to archive the target URL. Before enabling Origin Cache Control, review [how Cloudflare caches resources by default](/cache/concepts/default-cache-behavior/) as well as any Cache Rules you have configured so that you can avoid these issues. If you experience problems, disable Always Online.
+- **Do not block Known Bots or Verified Bots via a WAF custom rule.** If you block either of these bot lists, the Internet Archive will not be able to crawl.
 
 Do not use Always Online with:
 
-* API traffic.
-* An [IP Access rule](/waf/tools/ip-access-rules/) or a [WAF custom rule](/waf/custom-rules/) that blocks the United States or
-* Bypass Cache cache rules. Always Online ignores Bypass Cache cache rules and serves Always Online cached assets.
+- API traffic.
+- An [IP Access rule](/waf/tools/ip-access-rules/) or a [WAF custom rule](/waf/custom-rules/) that blocks the United States or
+- Bypass Cache cache rules. Always Online ignores Bypass Cache cache rules and serves Always Online cached assets.
 
 ## Limitations
 
 There are limitations with the Always Online functionality:
 
 1. Always Online is not immediately active for sites recently added due to:
-   * DNS record propagation, which can take 24-72 hours
-   * Always Online has not initially crawled the website
+   - DNS record propagation, which can take 24-72 hours
+   - Always Online has not initially crawled the website
 2. Cloudflare cannot show private content behind logins or handle form submission (POSTs) if your origin web server is offline.
 
-Always Online does not trigger for HTTP response codes such as [404](/support/troubleshooting/http-status-codes/4xx-client-error/#404-not-foundrfc7231httpstoolsietforghtmlrfc7231), [503](/support/troubleshooting/cloudflare-errors/troubleshooting-cloudflare-5xx-errors/#error-503-service-temporarily-unavailable), or [500](/support/troubleshooting/cloudflare-errors/troubleshooting-cloudflare-5xx-errors/#error-500-internal-server-error) errors such as database connection errors or internal server errors.
+Always Online does not trigger for HTTP response codes such as [404](/support/troubleshooting/http-status-codes/4xx-client-error/#404-not-foundrfc7231-), [503](/support/troubleshooting/cloudflare-errors/troubleshooting-cloudflare-5xx-errors/#error-503-service-temporarily-unavailable), or [500](/support/troubleshooting/cloudflare-errors/troubleshooting-cloudflare-5xx-errors/#error-500-internal-server-error) errors such as database connection errors or internal server errors.
 
 ## Frequently asked questions
 
 1. How can I know if a page has been crawled?
-   * You can go to the [Internet Archive](https://web.archive.org/) and search for the page URL to see if it has been crawled or not.
-   * You can also check this via the [Internet Archive Availability API](https://archive.org/help/wayback_api.php).
+
+   - You can go to the [Internet Archive](https://web.archive.org/) and search for the page URL to see if it has been crawled or not.
+   - You can also check this via the [Internet Archive Availability API](https://archive.org/help/wayback_api.php).
 
 2. Why were not pages x, y, and z crawled?
-   * Since Cloudflare only requests to crawl the most popular pages on the site, it is possible that there will be missing pages. If you really want to archive a page, then you can visit the [Internet Archive](https://web.archive.org/save) save page and ask them to crawl a particular page.
+
+   - Since Cloudflare only requests to crawl the most popular pages on the site, it is possible that there will be missing pages. If you really want to archive a page, then you can visit the [Internet Archive](https://web.archive.org/save) save page and ask them to crawl a particular page.
 
 3. What IP addresses do we need to allowlist to make sure crawling works?
-   * IP Range: `207.241.224.0/20` and `208.70.24.0/21`. Note that this ip range belongs to Internet Archive and NOT Cloudflare, since it is the Internet Archive that does the crawling.
+
+   - IP Range: `207.241.224.0/20` and `208.70.24.0/21`. Note that this ip range belongs to Internet Archive and NOT Cloudflare, since it is the Internet Archive that does the crawling.
 
 4. What user agent should the origin expect to see?
-   * Currently the Internet Archive uses: `Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/605.1.15 (KHTML, like Gecko) Chrome/89.0.4389.82 Safari/605.1.15`.
+   - Currently the Internet Archive uses: `Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/605.1.15 (KHTML, like Gecko) Chrome/89.0.4389.82 Safari/605.1.15`.

src/content/docs/cloudflare-one/connections/connect-devices/warp/configure-warp/route-traffic/warp-architecture.mdx

@@ -174,7 +174,7 @@ S -- No --> U["Virtual interface<br> (172.16.0.2)"] --> G[Cloudflare Gateway]
 
 #### Virtual interface
 
-Virtual interfaces allow the operating system to logically subdivide a physical interface, such as a network interface controller (NIC), into separate interfaces for the purposes of routing IP traffic. WARP's virtual interface is what maintains the WireGuard/MASQUE connection between the device and Cloudflare. By default, its IP address is hardcoded as `172.16.0.2`. You can use [**Override local interface IP**](/cloudflare-one/connections/connect-devices/warp/configure-warp/warp-settings/#override-local-interface-ip) to assign unique IPs per device.
+Virtual interfaces allow the operating system to logically subdivide a physical interface, such as a network interface controller (NIC), into separate interfaces for the purposes of routing IP traffic. WARP's virtual interface is what maintains the WireGuard/MASQUE connection between the device and Cloudflare. By default, its IP address is hardcoded as `172.16.0.2`. You can use [**Override local interface IP**](/cloudflare-one/connections/connect-devices/warp/configure-warp/warp-settings/#override-local-interface-ip-) to assign unique IPs per device.
 
 To view a list of all network interfaces on the operating system:
 

src/content/docs/cloudflare-one/connections/connect-devices/warp/configure-warp/warp-sessions.mdx

@@ -7,7 +7,7 @@ sidebar:
 
 import { Render, Badge } from "~/components";
 
-Cloudflare Zero Trust enforces WARP client reauthentication on a per-application basis, unlike legacy VPNs which treat it as a global setting. You can configure WARP session timeouts for your [Access applications](#configure-warp-sessions-in-access) or as part of your [Gateway policies](#configure-warp-sessions-in-gateway).
+Cloudflare Zero Trust enforces WARP client reauthentication on a per-application basis, unlike legacy VPNs which treat it as a global setting. You can configure WARP session timeouts for your [Access applications](#configure-warp-sessions-in-access-) or as part of your [Gateway policies](#configure-warp-sessions-in-gateway).
 
 <Render file="warp/warp-sessions-intro" />
 

src/content/docs/cloudflare-one/connections/connect-devices/warp/configure-warp/warp-settings/index.mdx

@@ -131,7 +131,7 @@ Configures the protocol used to route IP traffic from the device to Cloudflare G
 **Value**:
 
 - **WireGuard**: (default) Establishes a [WireGuard](https://www.wireguard.com/) connection to Cloudflare. The WARP client will encrypt traffic using a non-FIPs compliant cipher suite, `TLS_CHACHA20_POLY1305_SHA256`. When switching from MASQUE to WireGuard, users may lose Internet connectivity if their Wi-Fi network blocks the [ports and IPs](/cloudflare-one/connections/connect-devices/warp/deployment/firewall/#warp-ingress-ip) required for WireGuard to function.
-- **MASQUE** <InlineBadge preset="beta" />: Establishes an HTTP/3 connection to Cloudflare. To use MASQUE, [Override local interface IP](/cloudflare-one/connections/connect-devices/warp/configure-warp/warp-settings/#override-local-interface-ip) must be `Enabled`. The WARP client will encrypt traffic using TLS 1.3 and a [FIPS 140-2](https://csrc.nist.gov/pubs/fips/140-2/upd2/final) compliant cipher suite, `TLS_AES_256_GCM_SHA384`.
+- **MASQUE** <InlineBadge preset="beta" />: Establishes an HTTP/3 connection to Cloudflare. To use MASQUE, [Override local interface IP](/cloudflare-one/connections/connect-devices/warp/configure-warp/warp-settings/#override-local-interface-ip-) must be `Enabled`. The WARP client will encrypt traffic using TLS 1.3 and a [FIPS 140-2](https://csrc.nist.gov/pubs/fips/140-2/upd2/final) compliant cipher suite, `TLS_AES_256_GCM_SHA384`.
 
 For more details on WireGuard versus MASQUE, refer to our [blog post](https://blog.cloudflare.com/zero-trust-warp-with-a-masque).
 

src/content/docs/cloudflare-one/connections/connect-networks/private-net/warp-connector.mdx

@@ -81,7 +81,7 @@ All WARP Connector and WARP client devices in your Zero Trust organization have
 2. Enable **Proxy**.
 3. Enable **Warp to Warp**. This allows Cloudflare to route traffic to the CGNAT IP space.
 4. Next, go to **Settings** > **WARP Client**.
-5. Enable [**Override local interface IP**](/cloudflare-one/connections/connect-devices/warp/configure-warp/warp-settings/#override-local-interface-ip).
+5. Enable [**Override local interface IP**](/cloudflare-one/connections/connect-devices/warp/configure-warp/warp-settings/#override-local-interface-ip-).
 6. [Check your Split Tunnel configuration](/cloudflare-one/connections/connect-networks/private-net/cloudflared/#3-route-private-network-ips-through-warp) and ensure that the CGNAT IP space (`100.96.0.0/12`) routes through WARP.
 
    For example, if you are using **Exclude** mode, delete `100.64.0.0/10` from the list and re-add `100.64.0.0/11` and `100.112.0.0/12`.

src/content/docs/cloudflare-one/faq/teams-troubleshooting.mdx

@@ -106,7 +106,7 @@ Certain web browsers (such as Chrome and Microsoft Edge) load and cache root cer
 
 ## I see `Access api error auth_domain_cannot_be_updated_dash_sso`.
 
-This error appears if you try to change your [team domain](/cloudflare-one/faq/teams-getting-started-faq/#whats-a-team-domain/team-name) while the [Cloudflare dashboard SSO](/cloudflare-one/applications/configure-apps/dash-sso-apps/) feature is enabled on your account.
+This error appears if you try to change your [team domain](/cloudflare-one/faq/teams-getting-started-faq/#whats-a-team-domainteam-name) while the [Cloudflare dashboard SSO](/cloudflare-one/applications/configure-apps/dash-sso-apps/) feature is enabled on your account.
 Cloudflare dashboard SSO does not currently support team domain changes. Contact your account team for more details.
 
 ## WARP on Linux shows `DNS connectivity check failed`.

src/content/docs/ddos-protection/managed-rulesets/http/index.mdx

@@ -29,6 +29,7 @@ You can adjust the behavior of the rules in the managed ruleset by modifying the
 
 - Certain actions or sensitivity levels may not be available to all Cloudflare plans.
 - Currently, you can only define account-level configurations (or overrides) for the HTTP DDoS Attack Protection managed ruleset via API.
+
 :::
 
 To adjust rule behavior, do one of the following:
@@ -43,18 +44,17 @@ For more information on the available configuration parameters, refer to [Manage
 
 Cloudflare HTTP DDoS Protection can also initiate mitigation based on the origin health. Floods of requests that cause a high number of zone errors (default sensitivity level is 1,000 errors per second) can initiate mitigation to alleviate the strain on the zone.
 
-| Rule ID | Description | 
-| --- | --- |
+| Rule ID                            | Description                                           |
+| ---------------------------------- | ----------------------------------------------------- |
 | `dd42da7baabe4e518eaf11c393596a9d` | HTTP requests causing a high number of origin errors. |
 
 :::note
-
-This rule is available for zones on any plan. 
+This rule is available for zones on any plan.
 :::
 
 The rule is adaptive for zones on the Pro, Business, or Enterprise plan. It performs an additional check for better detection accuracy: the errors-per-second rate must also be at least five times the normal traffic levels.
 
-All HTTP errors in the 52x range (Internal Server Error) and all errors in the 53x range excluding [530](/support/troubleshooting/cloudflare-errors/troubleshooting-cloudflare-5xx-errors/#530error) are considered when factoring in the error rate.
+All HTTP errors in the 52x range (Internal Server Error) and all errors in the 53x range excluding [530](/support/troubleshooting/cloudflare-errors/troubleshooting-cloudflare-5xx-errors/#error-530) are considered when factoring in the error rate.
 
 ## Availability