Cloudflare

提供: First Wiki
ナビゲーションに移動 検索に移動

Cloudflare (cloudflare.com) は、分散型サービス拒否攻撃（DDoS）防御機能を統合した商用コンテンツ配信ネットワークです。 このサービスは、ウェブサイトへのリバースプロキシおよびドメインネームサーバーとして機能するため、ホスティングプロバイダーがネイティブIPv6を提供していない場合に、有用なIPv6移行メカニズムを提供できます。

他のリバースプロキシと同様にユーザーとMediaWikiの間に自身を配置するサーバーには設定上の問題が生じます。 Cloudflareには、何をキャッシュすべきか（および古いコンテンツをいつ破棄すべきか）を指示する必要があります。 Likewise, MediaWiki (or Apache) needs to be aware of any intervening trusted proxies to ensure that the user's IP address (and not that of Cloudflare's servers) is listed in Special:RecentChanges or logged by Extension:CheckUser. 同様に、MediaWiki（またはApache）は、ユーザーのIPアドレス（CloudflareサーバーのIPアドレスではなく）が[[特別:最近の更新]に表示されるか、Extension:CheckUserによって記録されることを保証するため、中間にある信頼できるプロキシの存在を認識する必要があります。

Advantages and limitations

Cloudflareは現在、転送データ量（メガビット/秒、ギガバイト、テラバイト単位）ごとに課金していません（2025年現在）。基本的なサービスは、一部制限付きで無料です。同じ変更のないコンテンツ（帯域幅コストの80%以上を占めることが多い画像など）に対して大量のリクエストを受けるサイトの場合、トラフィックの多いドメインをCloudflareのようなサービスの背後（プロキシ）に配置することで、運用コストを大幅に削減できます。オリジンサーバーへのリクエストが減るため、場合によってはサイトの表示速度が向上することもあります。

Cloudflare環境下では個別ページ閲覧カウンターが機能しません。ほとんどのリクエストがオリジンサーバーに到達せず、個々のWikiサイト所有者はCloudflareのログにアクセスできないためです。Cloudflareはサイト訪問者数を示す分析機能を提供しますが、ページ単位での計測はできません。

サイトコンテンツはCloudflareサーバーで復号化され再暗号化されます。これは潜在的な「中間者攻撃」の脆弱性となります。

Cloudflareはドメイン全体のDNSを管理します。freedns.afraid.orgのようなサービスで個々のサブドメインをユーザー間で共有している場合や、DNSプロバイダーとして機能することを前提とした他のサービスを利用している場合、これは問題となる可能性があります。CloudflareはWeb向けDDoS保護を提供しますが、メールやその他のサービスには適用されません。自身のドメインを指すMXレコードを削除しない限り、これらのレコード内のアドレスは依然として基盤となるオリジンサーバーを特定し、DDoS攻撃や悪用を仕掛けるために利用される可能性があります。

Cloudflareはお客様のサイトを複数の国に配置された複数のエニーキャストサーバーの背後で提供します。これは、地理的にユーザーに近いことでサイトの表示速度が向上する場合に利点となりますが、誹謗中傷観光の標的となっているサイトや政治的に敏感な問題を取り扱うサイトにとっては法的リスクとなる可能性があります。Cloudflareによるコンテンツ検閲は稀ですが、本拠地の政治情勢から完全に隔離されているわけではありません。Cloudflareがコンテンツを理由にサイトを削除した事例には、Switter（性労働者向けマイクロブログサイト）やDaily Stormer（極右政治サイト）が含まれます。同様に、ウィキリークスのようなサイトは、米国情報機関に関する機密情報を扱う場合、データ経路に米国サーバーを置きたくないかもしれません。Cloudflareがインフラを他国（ロシアを含む）に拡大するにつれ、潜在的に影響を受ける政府の数も増加します。自国では合法だが、Cloudflareサーバー設置国の一つ以上では違法な活動を扱うサイトは、このサービスの利用を避け、コンテンツ配信ネットワークを自国に維持することを望むかもしれません。

Cloudflareは中国ではうまく機能しません。グレートファイアウォールがCloudflareサーバーからのトラフィックを頻繁にブロックするためです。

無料・有料を問わず、あらゆるサードパーティサービスには、今日無料でも明日には高額な有料サービスに変わるリスク、速度低下や不安定化、あるいはサービス終了のリスクが伴います。将来的に「フリーミアム」のCloudflareサービスが終了した場合に備え、ドメイン登録のDNS設定を元のサービス（または別のプロバイダー）に戻せるよう準備しておきましょう。

Integration with MediaWiki

MediaWikiのキャッシュ戦略は、オープンソースのリバースプロキシサーバーと連携するよう設計されています（キャッシュプロキシを参照）。 単一サーバー構成では、次のように機能します：

Outside world ⇔
Server

Squid/Varnish accelerator
w.x.y.z:80

⇔

Apache webserver
127.0.0.1:80

匿名ユーザーがページをリクエストすると、Squid/Varnishは既にキャッシュされたコピーがあるかどうかを確認した。利用可能なコピーがあれば、オリジンサーバーに問い合わせることなく直接提供された。なければ、リクエストはApacheとMediaWikiに渡された。

This saved significant amounts of processor time (as MediaWiki was no longer repeatedly regenerating the same HTML for frequently-read pages) but had various impacts on MediaWiki server configuration:

  • The address of the Squid/Varnish proxy had to be kept out of Special:RecentChanges, instead using the user's IP address from the X-Forwarded-For header.
  • The proxy servers had to be notified when a page was changed, so they could discard the outdated version.This was done from LocalSettings.php with entries like:
$wgUseCdn = true;
$wgCdnServers = [ '<your IPv4 address>' ];
$wgCdnServersNoPurge = [ '127.0.0.1' ];
  • For setups with MediaWiki 1.33 or older, replace Cdn with Squid.
  • The proxy had to avoid caching dynamic content which frequently or pseudo-randomly changes, such as special pages or output from some extensions such as Extension:DynamicPageList or Extension:RandomSelection.
  • Pages displaying a "You have new messages" banner or similar flags could not be cached
  • Pages for logged-in users (as they contain login names or identifying info) could not be cached
  • Protection against image hotlinking had to move out of Apache and onto whichever server was facing the user
  • IPv6 and HTTPS support also moved onto whichever server was facing the user.

MediaWiki sends HTTP headers (such as "cache-control: private" if something should not be cached, or an expiry time if something can be cached for a limited time) which are recognised by Squid/Varnish. Squid/Varnish sends "X-forwarded-for:" to indicate the IP of a user to a MediaWiki installation behind a Squid/Varnish proxy. MediaWiki also sends HTTP PURGE requests to notify Squid/Varnish that an item has changed and needs to be discarded.

As MediaWiki was designed to work with Squid/Varnish, the MediaWiki installation and the cache are tightly integrated.

Cloudflare in some cases provides a function which could serve a similar role, but implements it in a non-standard or incompatible manner. <translate> MediaWiki can operate behind Cloudflare, but there are some configuration issues to be addressed.

Anonymous IP user identification

If a user connects directly to a MediaWiki installation (on Apache), the user's IP address is reported by PHP in <tvar name=1>テンプレート:Phpi</tvar> and no further configuration is required to get the information into <tvar name=2>Special:RecentChanges</tvar>

As MediaWiki typically blocks abuse by IP address, showing Cloudflare as the address in Special:Recentchanges will interfere with efforts to selectively block [[<tvar name=1>Special:MyLanguage/Manual:Combatting spam</tvar>|spam]] and [[<tvar name=2>Special:MyLanguage/Manual:Combating vandalism</tvar>|vandalism]].

Apache: mod_remoteip

Cloudflare recommends the use of <tvar name=1>mod_remoteip</tvar> for configuring Apache to correctly report original IP addresses of incoming requests.</translate> <translate> Detailed instructions on how to reconfigure Apache, for several operating systems, exist [<tvar name=url>https://developers.cloudflare.com/support/troubleshooting/restoring-visitor-ips/restoring-original-visitor-ips/</tvar> here].</translate> <translate> Note that Cloudflare no longer recommends the use of <tvar name=1>mod_cloudflare</tvar> for this purpose.</translate>

<translate>

MediaWiki: <tvar name=1>$wgUseCdn</tvar> and <tvar name=2>$wgCdnServersNoPurge</tvar>

Since version 1.23, MediaWiki has supported providing the list of trusted proxies in CIDR notation, so the list of Cloudflare IP ranges can be passed directly to MediaWiki for validation.</translate> <translate> See [<tvar name=url>https://www.cloudflare.com/ips/</tvar> Cloudflare: IP Ranges].</translate>

<syntaxhighlight lang="php"> $wgUseCdn = true; $wgCdnServersNoPurge = [ <list of Cloudflare ranges> ]; </syntaxhighlight>

<translate> As Cloudflare provides the client IP in the <tvar name=1>X-Forwarded-For</tvar> header, simply filling these values makes MediaWiki recognize them correctly.</translate> <translate> See [<tvar name=url>https://support.cloudflare.com/hc/en-us/articles/200170986</tvar> Cloudflare: Cloudflare HTTP headers].</translate>

<translate> This is the recommended configuration for MediaWiki >= 1.34 (presumably for people who can't use mod_remoteip, which is sufficient on its own).</translate> <translate> In older versions the equivalent variables were <tvar name=1>$wgUseSquid</tvar> and <tvar name=2>$wgSquidServersNoPurge</tvar>.</translate>

<translate> As the list of Cloudflare IP ranges varies over time, you will need to check periodically in order to update this setting.

Squid/Varnish

If a MediaWiki installation is behind Squid/Varnish, MediaWiki must be configured to use the <tvar name=1>テンプレート:Inline-code</tvar> header and a list of trusted proxies configured in <tvar name=2>$wgCdnServers</tvar> or <tvar name=3>$wgCdnServersNoPurge</tvar>.

Any existing local caching servers (such as Squid or Varnish) will need to be removed when using <tvar name=1>テンプレート:Inline-code</tvar>; otherwise, <tvar name=2>テンプレート:Inline-code</tvar> will see Squid's address (which it doesn't recognise as a trusted proxy) and pass the request unchanged, at which point MediaWiki replaces the address of Squid with the next address upstream... Cloudflare.</translate> <translate> You can also try adding Squid to the list of trusted proxies by using the <tvar name=1>CloudflareRemoteIPTrustedProxy</tvar> directive.</translate>

<translate>

Cache control

Cache Control Basics

By default, MediaWiki sets certain HTTP headers (such as <tvar name=1>テンプレート:Inline-code</tvar> for logged-in users, or <tvar name=2>テンプレート:Inline-code</tvar> for cacheable pages) to control whether its dynamically-generated content is cached and when it should expire.</translate> <translate> For purely static content, such as image files, the headers are generated by the web server.</translate>

<translate> Cloudflare respects these by default; see [<tvar name=url>https://support.cloudflare.com/hc/en-us/articles/200169266-Does-Cloudflare-honor-my-Expires-and-Cache-Control-headers-for-static-content-</tvar> here].</translate>

<translate> You can check whether a given page is being cached by Cloudflare by looking at the headers returned from the server (i.e. in your browser's developer mode) and looking for the <tvar name=1>テンプレート:Inline-code</tvar> header; <tvar name=2>テンプレート:Inline-code</tvar> means "your webserver told me not to cache this".</translate>

<translate> MediaWiki's defaults in this regard are extremely conservative, however.</translate> <translate> By default, it basically says "no don't cache anything at all except images and CSS files" to upstream cache providers.</translate> <translate> If your goal is to use Cloudflare's cache to serve your site when your server goes down, this is not at all helpful.</translate>

<translate> To have MediaWiki allow Cloudflare to cache most pages (i.e. most stuff that isn't *fully* dynamic), you need to set the following in <tvar name=1>LocalSettings.php</tvar>:</translate>

<syntaxhighlight lang="php"> $wgUseCdn = true; // used to be $wgUseSquid = true; </syntaxhighlight>

<translate> If you do that, then a Cloudflare "Cache Everything" page rule will actually cache most stuff; without that LocalSettings change, it'll just be ignore unless you also override Origin Cache Control, which is not a great idea because you'll cache too much.</translate>

<translate>

Cloudflare Cache Control Overrides

From My Websites → settings → Page rules it is possible to create three rules per domain (more for paid users).</translate> <translate> Each matches a pattern (such as *example.org/wiki/* for all wiki pages on example.org and its subdomains, in standard view) and allows configuration of:</translate>

  • Custom caching - <translate> allows the cache control headers to be overridden, "Cache everything" is the most aggressive and may be OK for static image files but certainly not wanted for anything else.</translate> <translate> <tvar name=1>Special:Recentchanges</tvar> or other dynamic content should use the least aggressive settings.</translate>
  • Edge cache expire TTL - <translate> in "cache everything" mode, overrides the time after which Cloudflare requests a new copy of a page or file from the origin server.</translate> <translate> If used on anything but static content (images), this will cache things which shouldn't be cached as it can override cache control directives from the origin server.</translate>[1]
  • Browser cache expire TTL - <translate> indicates the time after which the user's browser should request a new copy of a page from <tvar name=1>Cloudflare</tvar></translate>

There's also an "Always Online" (which causes Cloudflare to serve cached copies of your pages if the origin server is down) and an "Origin Cache Control" (which tells Cloudflare to honour cache control headers sent by the origin server, such as the "no-cache" on pages served to logged-in users).

<translate> It's best to cache static image files aggressively ("cache everything" would be valid for images, were a means provided to purge them when a new version is uploaded). Ordinary wiki pages should use settings which respect cache-control headers ("standard, origin cache control on" is OK, "cache everything" is problematic) and special: pages should not be cached or cached only briefly (so that they remain current).</translate>

<translate> For example, these settings:</translate>

  1. /load.php?*
    <translate> Always Online: On, Cache Level: Cache Everything, Browser Cache TTL: a year, Edge Cache TTL: a month</translate>
  2. /wiki/*:*
    <translate> Cache Level: Bypass</translate>
  3. /wiki/*
    <translate> Always Online: On, Cache Level: Standard, Origin Cache Control: On</translate>

<translate> would cause:</translate>

  1. <translate> <tvar name=1>load.php</tvar> to always be cached (which could easily reduce load on the origin server by 25-50%, as <tvar name=2>load.php</tvar> serves CSS/JS which is constantly loaded on every page).</translate> <translate> Default settings are overridden to aggressively keep these pages in cache for the maximum amount of time.</translate>
  2. <translate> wiki pages outside mainspace (such as <tvar name=1>Special: Talk: Project:</tvar>) to never be cached, so that <tvar name=2>Special:RecentChanges</tvar> and the like show current data</translate>
  3. <translate> lastly, wiki pages in mainspace (which weren't matched by the previous rule) are cached as directed by the origin server (MediaWiki gives them a long expiry time with a "must-revalidate" status; pages served to logged-in users or displaying "you have new messages" banners must honour "no-cache" so they won't be served to subsequent visitors).</translate>

<translate> These settings presume that the standard/default behaviour for Cloudflare will cache obvious static files <tvar name=1>(.jpg .png .gif)</tvar> but that <tvar name=2>Cloudflare</tvar> needs to be explicitly told to cache output from load.php (which it otherwise would have mistaken for highly dynamic, variable content).</translate>

<translate> They are fairly aggressive, and may exhibit a couple of flaws:</translate>

  • Logged-in users may still be served cached mainspace pages in normal view as if they were logged out. While Cloudflare mentions a Bypass Cache on Cookie setting which could detect MediaWiki's login cookies and serve a fresh page to all logged-in users, that setting is only available on the most expensive paid plans, which (at hundreds of dollars per domain per month) are not a reasonable alternative for most small sites. If you do have the necessary plan though, make sure to set テンプレート:Phpi and テンプレート:Phpi to false if you have Extension:UniversalLanguageSelector installed, to prevent Cloudflare from caching translated interfaces.
  • Uploads which replace an image by overwriting with another of the same name will not be detected; Cloudflare presumes this to be static content and caches aggressively. The standard MediaWiki+cache proxy setup allows MediaWiki to send a テンプレート:Inline-code message to discard the outdated content; extensions such as CloudflarePurge allow MediaWiki to send an equivalent purge message to Cloudflare's proprietary API.

Effectively, it's possible to reduce load on origin servers by up to 75% by caching content with Cloudflare, but this comes with a risk of serving outdated pages or images.

Splitting Your Site

If you really want Cloudflare to cache most everything (i.e. you're relying on Cloudflare's Always Online feature, which means you need to cache aggressively as Cloudflare can't show a page to the world unless it's cached), but you also want editors to be able to do their job, a somewhat extravagant option is to make a second website, using the same back-end database, and give it a different URL, and have Cloudflare only cache the main site.

You can then use redirects to push editors to the "live" site, the one that Cloudflare isn't caching. The following works reasonably well for this in Apache:

On the normal site:

<syntaxhighlight lang="apache"> 

 # Send editors and people looking for special pages to the live site
 RewriteCond %{QUERY_STRING}           Special:
 RewriteRule .*                        https://live.mysite.com$0 [R=302,L]

</syntaxhighlight>

On the "live" site:

<syntaxhighlight lang="apache"> 

 # Push non-editors to the cached site; don't send people on
 # Special pages back, though, because we send people from the
 # other site to here on Special pages and we don't want a loop.
 RewriteCond %{HTTP_COOKIE}            !mediawiki_session
 RewriteCond %{QUERY_STRING}           !Special:
 RewriteRule .*                        https://www.mysite.com$0 [R=302,L]

</syntaxhighlight>

Example page rules on the Cloudflare side to go with such a configuration:

<syntaxhighlight lang="apache">

  • mysite.com/*Special:*

Cache Level: Bypass

  • mysite.com/*Talk:*

Cache Level: Bypass

  • mysite.com/*

Always Online: On, Cache Level: Cache Everything </syntaxhighlight>

HTTP purge

When new content is uploaded to a MediaWiki, the wiki software will request that each cache server (as configured in テンプレート:Wg) discard the outdated version of the page or image. This notification is not sent to third-party web proxies (such as those listed in Extension:TrustedXFF) and appears to be hard-coded in SquidPurgeClient.php in core MediaWiki code with no hooks to allow an extension to change this behaviour.

The message, as sent by MediaWiki, looks like: PURGE http://wiki.example.org/images/0/01/Some_image_recently_replaced.jpg

Squid will honour this request if it comes from a trusted IP address. Cloudflare will likely not.

There is a means to manually request one outdated file be discarded (from 'My Websites' settings for one domain → Cloudflare Settings → Cache Purge, click "purge single file" and enter URL of file to purge) but this is cumbersome and wildcards are not supported.[2]

Cloudflare's API provides a function which can purge an individual file,[3] but there is currently nothing available to invoke this API automatically from MediaWiki. As a result, a wiki behind Cloudflare will continue to display outdated versions of content until the data expires from cache normally. See bugzilla:62356.

Cloudflare does not offer a direct equivalent to Squid's テンプレート:Inline-code parameter, which controls how long an error code returned for a URL from an origin server remains in cache (negative caching) until the request is retried. If Cloudflare does "cache everything" with a long time-to-live, it may be necessary to manually purge URL's where Cloudflare has stored an error message but the error has since been corrected upstream.

Mobile pages using MobileFrontend extension

Extension:MobileFrontend provides a configuration in which mobile browsers are autodetected. This can play havoc with external caching schemes; while Varnish may be configured to auto-detect a mobile browser and serve a different version of the page, the Cloudflare cache may be blissfully unaware that this is happening – or even serve the wrong version. It's best to turn off auto-detection and serve the mobile version from a different subdomain (ie: mobile.www.example.org for the mobile version, if the desktop site is www.example.org).

To turn off Mediawiki's mobile browser auto-detection, try:

<syntaxhighlight lang="php"> $wgServer = "//www.example.org"; $wgCanonicalServer = "https://www.example.org"; $wgMobileUrlCallback = fn ( $domain ) => "mobile.$domain"; $wgMFAutodetectMobileView = false; </syntaxhighlight>

This puts the mobile and desktop versions on separate subdomains.

Cloudflare can then be configured to provide mobile browser autodetection on their servers. Unfortunately, Cloudflare only provides this autodetection for the base domain (テンプレート:Inline-code) and the www. subdomain (テンプレート:Inline-code); any handheld mobile devices which visit these two portions of the site will be automatically redirected to some other subdomain (such as テンプレート:Inline-code) of the same domain. Any other subdomains (such as テンプレート:Inline-code or テンプレート:Inline-code) can be given mobile versions (テンプレート:Inline-code or テンプレート:Inline-code) but mobile browsers will not be autodetected by Cloudflare on anything but the base domain or the www subdomain. Visitors to テンプレート:Inline-code will instead need to click on the "mobile version" or "desktop version" links at the bottom of each webpage to select the desired version (an awkward limitation if you're serving multiple language wikis (or an entire wiki family) as subdomains of one main domain).

From the performance ("speed") tab on Cloudflare's web dashboard for each individual site, go to "Mobile Redirect", select a subdomain which contains the mobile version (for example, テンプレート:Inline-code), select "keep path" and turn the feature "on".

In the DNS and the Apache webserver configurations, the desktop and mobile sites point to the same MediaWiki installation; MediaWiki then examines the URL to determine whether Cloudflare is requesting the mobile version.

If MediaWiki doesn't correctly force the mobile subdomain into always-mobile mode, modifying ./extensions/MobileFrontend/includes/MobileContext.php to insert this additional check at the beginning of the usingMobileDomain() function may help: <syntaxhighlight lang="php"> 

       public function usingMobileDomain() {
               if (isset($_SERVER['SERVER_NAME']))
                  if ((substr($_SERVER['SERVER_NAME'],0,2)=='m.') || (substr($_SERVER['SERVER_NAME'],0,7)=='mobile.'))
                       return true;

</syntaxhighlight> ...with the rest of the code unchanged. This should only be needed if traffic is reaching your m. or mobile. subdomain from clients which aren't being detected as mobile browsers.

If mobile users can no longer visit the normal desktop view through the desktop view link at the bottom of the page, modifying ./extensions/MobileFrontend/includes/MobileContext.php to change the cookies name and value may help:

At the top of the MobileContext class: <syntaxhighlight lang="php"> public const STOP_MOBILE_REDIRECT_COOKIE_NAME = '__cf_mob_redir'; </syntaxhighlight>

At the middle of the setStopMobileRedirectCookie() function: <syntaxhighlight lang="php"> $this->getRequest()->response()->setCookie( self::STOP_MOBILE_REDIRECT_COOKIE_NAME, '0', $expiry, [ 'domain' => $this->getStopMobileRedirectCookieDomain(), 'prefix' => , 'secure' => (bool)$stopMobileRedirectCookieSecureValue, ] ); </syntaxhighlight>

At the middle of the shouldDisplayMobileViewInternal() function: <syntaxhighlight lang="php"> $stopMobileRedirect = $this->getStopMobileRedirectCookie(); if ( $stopMobileRedirect == '0' ) { return false; } </syntaxhighlight>

This method would require you to click the link twice to actually redirect to the desktop view, though.

Image hotlinking

Many web-based forums are infamous for encouraging users to link directly to images hosted on other sites. Their site appears to be displaying the image, but is using bandwidth that the 'hot-linked' target site's operators must pay for. A common defense is for Apache webmasters to deploy テンプレート:Inline-code to look at the テンプレート:Inline-code (sic) line of each request and reject any that hotlink images (.jpg, .png, .gif et al.) for use on pages on some other site.

With any form of caching server, the origin servers are no longer user-facing. Any anti-hotlinking code needs to be removed from the origin webserver (such as Apache); anti-hotlink protection is available on Cloudflare if needed.

HTML document comments

MediaWiki will normally add comments such as テンプレート:Inline-code to HTML output for troubleshooting purposes; if a site has multiple Apache's delivering the same content, this is invaluable in determining which server is causing a specific issue. Cloudflare is prone to "optimising" delivered webpages by stripping these comments, a function which may need to be turned off at times for debugging purposes.

HTTPS

Cloudflare may be used as a transition mechanism to convert between (insecure) http: and (secure) https: – while this does not provide end-to-end encryption (as it leaves Cloudflare's server in a "man-in-the-middle as a service" position) it's better than no https: at all.

All versions of MediaWiki from 1.18 onward support protocol-relative URLs, so that replacing a link like http://wiki.example.org with merely //wiki.example.org when loading images and resources will work properly in both HTTP and HTTPS. This change is not specific to Cloudflare, but affects any MediaWiki site available in both HTTP and HTTPS.

IPv6

All current MediaWiki versions are able to log an IPv6 user address to Special:RecentChanges if one is provided. No changes to MediaWiki's LocalSettings.php is required, although MediaWiki (and any extensions which rely on user IPs, such as CheckUser) needs to be a currently-supported version as some older (pre-MW1.19) revisions were buggy in logging IPv6 user addresses to Special:RecentChanges

IPv6 support is enabled on whichever server is facing the user; Apache for a stand-alone install, Squid/Varnish for sites using these as a reverse proxy, Cloudflare's server for sites where Cloudflare is user-facing. There is no requirement that the communication from the user-facing server back to Apache support both IPv4 and IPv6 and no benefit to enabling both for any back-end link.

My websites → settings → Cloudflare settings → Automatic IPv6 may be set to "full" for each domain to enable IPv6 for your site.

No other configuration is required for IPv6.

Preventing account creation and editing spam via Cloudflare

The following Cloudflare formula seems to be working for a small MediaWiki installation, as of this writing, for preventing custom bots that attempt to do signups and MediaWiki spam.

On the free version Cloudflare, go into Rules/Configuration Rules for the hosting domain, and add the rule: 

(http.request.uri contains "action=edit") or (http.request.uri contains "Special:") or (http.request.uri contains "User:") or (http.request.uri contains "diff=")

With the corresponding action "Security Level: I'm Under Attack". This tips off Cloudflare that bots which hammer on URLs containing these phrases, need additional sanity checks before being passed to the live site. Your mileage mary vary; test this formula thoroughly before deploying.

See also

「https://wiki.fatyas.com/w/index.php?title=Cloudflare&oldid=1479」から取得