• HOME
  • ตั้งค่า Cloudflare กับ WordPress: Nameserver, SSL, IP จริง และ WAF

2026年11月12日

  • シェア
  • ツイート

    • 2026年11月12日

    ตั้งค่า Cloudflare กับ WordPress: Nameserver, SSL, IP จริง และ WAF

    もくじ

    บทความนี้เป็นฉบับปรับให้เหมาะกับท้องถิ่นจากต้นฉบับภาษาญี่ปุ่น อ่านต้นฉบับภาษาญี่ปุ่น

    การติดตั้ง Cloudflare กับ WordPress ทำตามลำดับดังนี้ ① เพิ่มเว็บไซต์ใน Cloudflare แล้วเปลี่ยน Nameserver ของโดเมน ② ตั้งโหมดการเข้ารหัส SSL/TLS เป็น Full (strict) ③ กู้คืน IP จริงของผู้เข้าชมที่ฝั่งเซิร์ฟเวอร์ ④ ป้องกันหน้าล็อกอินด้วย Custom rules ของ WAF แม้แผนฟรีก็ใช้ CDN, SSL, การป้องกัน DDoS และ Custom rules (สูงสุด 5 กฎ) ได้

    บทความนี้อธิบายการตั้งค่าแต่ละส่วนและสิ่งที่ควรตรวจสอบหลังเปลี่ยนมาใช้ ชื่อและตำแหน่งของหน้าจอใน Cloudflare อาจเปลี่ยนแปลงได้ จึงเขียนตามเอกสารทางการ (developers.cloudflare.com) ณ พฤศจิกายน 2026

    สิ่งที่ควรตัดสินใจก่อนเริ่มทำ

    • การจัดการ DNS จะย้ายมาอยู่ที่ Cloudflare ผู้ให้บริการจดทะเบียนโดเมน (registrar) ยังเหมือนเดิม แต่การแก้ไขระเบียน DNS จะทำในหน้าจอของ Cloudflare
    • ระเบียน DNS สำหรับอีเมล (MX เป็นต้น) ให้ตั้งเป็นไม่ผ่านพร็อกซี สิ่งที่ผ่าน Cloudflare มีเฉพาะการสื่อสารของเว็บ (HTTP/HTTPS) เท่านั้น
    • ตรวจสอบว่าต้นทาง (origin คือเซิร์ฟเวอร์ที่วาง WordPress) มีใบรับรอง SSL ที่ใช้งานได้ หากใช้ HTTPS ได้อยู่แล้ว เช่นด้วย Let's Encrypt ก็ไม่ต้องทำอะไรเพิ่ม
    • หากเปิด DNSSEC ไว้ที่ registrar ให้ปิดก่อนเปลี่ยน Nameserver เพราะถ้าระเบียน DS เก่าค้างอยู่ การแปลงชื่อโดเมนจะล้มเหลว

    ขั้นตอนที่ 1: เพิ่มเว็บไซต์และเปลี่ยน Nameserver

    1. สร้างบัญชี Cloudflare แล้วเพิ่มโดเมนใน Dashboard เลือกแผน Free ได้
    2. Cloudflare จะอ่านระเบียน DNS ปัจจุบันมาแสดงเป็นรายการ ให้ตรวจดูว่ามีตกหล่นหรือไม่ เนื่องจากบางระเบียนอ่านไม่ได้ จึงควรเทียบกับหน้าจัดการ DNS ปัจจุบันและเพิ่มส่วนที่ขาดด้วยมือ
    3. ระเบียน A (หรือ AAAA, CNAME) ของเว็บไซต์ให้เปิดสถานะพร็อกซี (ก้อนเมฆสีส้ม) ส่วน MX และระเบียน A สำหรับเมลเซิร์ฟเวอร์ให้ปิด (DNS only, ก้อนเมฆสีเทา)
    4. Cloudflare จะแสดงชื่อ Nameserver 2 ชื่อ ซึ่งอยู่ในรูป 〇〇.ns.cloudflare.com และกำหนดให้แยกตามบัญชี ให้ใช้ 2 ชื่อที่ขึ้นบนหน้าจอของตนเอง ไม่ใช่ชื่อที่เขียนไว้ในบทความอื่น
    5. ในหน้าจัดการของ registrar ให้เปลี่ยน Nameserver ของโดเมนเป็น 2 ชื่อนั้น

    ตรวจสอบว่าเปลี่ยนสำเร็จหรือไม่ด้วยคำสั่งต่อไปนี้ การมีผลอาจใช้เวลาหลายชั่วโมง

    # ตรวจว่า Nameserver เป็นของ Cloudflare ทั้ง 2 ชื่อหรือไม่
dig NS example.com +short

# ตรวจว่าผ่าน Cloudflare หรือไม่ (จะได้ server: cloudflare และ cf-ray กลับมา)
curl -sI https://example.com | grep -iE '^(server|cf-ray):'

    เมื่อสถานะของโดเมนในหน้าจอ Cloudflare เป็นใช้งานอยู่ (Active) ถือว่าการเปลี่ยนเสร็จสมบูรณ์

    ขั้นตอนที่ 2: ตั้ง SSL/TLS เป็น Full (strict)

    SSL/TLS ของ Cloudflare มีโหมดที่กำหนดว่าจะเข้ารหัสการสื่อสารระหว่างผู้เข้าชมกับ Cloudflare และระหว่าง Cloudflare กับต้นทางอย่างไร

    โหมด ระหว่าง Cloudflare กับต้นทาง การใช้กับ WordPress
    Off ไม่เข้ารหัส ไม่ใช้
    Flexible HTTP (ไม่เข้ารหัส) ไม่ใช้ เป็นสาเหตุของการรีไดเรกต์วนซ้ำและ mixed content
    Full HTTPS (ไม่ตรวจสอบใบรับรอง) ใช้ชั่วคราวระหว่างรอเตรียมใบรับรอง
    Full (strict) HTTPS (ตรวจสอบใบรับรอง) ให้ใช้โหมดนี้

    เปลี่ยนการตั้งค่าได้ที่หน้า Overview ของ SSL/TLS ใน Dashboard ของ Cloudflare ค่าเริ่มต้น "Automatic SSL/TLS" คือกลไกที่เลือกโหมดปลอดภัยให้อัตโนมัติในขอบเขตที่ต้นทางรองรับ การเลือก Full (strict) เองไว้ล่วงหน้าจะไม่ทำให้ระบบทำงานในโหมดที่ไม่ได้ตั้งใจ ใบรับรองของต้นทางใช้ได้ทั้งของผู้ออกใบรับรองสาธารณะ (เช่น Let's Encrypt) หรือใบรับรอง Origin CA ที่ Cloudflare ออกให้

    เหตุผลที่ควรเลี่ยง Flexible มีดังนี้ ในโหมด Flexible คำขอจะไปถึงต้นทางด้วย HTTP ทำให้ WordPress หรือเซิร์ฟเวอร์ตอบกลับว่า "มาด้วย HTTP จึงเปลี่ยนเส้นทางไป HTTPS" แล้ว Cloudflare ก็ไปดึงต้นทางด้วย HTTP อีก วนซ้ำไปเรื่อย ๆ (เบราว์เซอร์จะแสดง ERR_TOO_MANY_REDIRECTS) ส่วน Full (strict) คำขอไปถึงต้นทางด้วย HTTPS จึงไม่ต้องเพิ่มโค้ดฝั่ง WordPress เพื่อดู X-Forwarded-Proto แล้วเขียนทับ $_SERVER['HTTPS']

    นอกจากนี้ให้ตรวจสอบว่า "ที่อยู่ WordPress (URL)" (WordPress Address) และ "ที่อยู่ไซต์ (URL)" (Site Address) ใน "ตั้งค่า (Settings) → ทั่วไป (General)" ของ WordPress ขึ้นต้นด้วย https:// หากรูปภาพหรือไฟล์อื่นยังเป็น http:// ให้ดูวิธีแก้ mixed content

    ขั้นตอนที่ 3: กู้คืน IP จริงของผู้เข้าชม

    เมื่อผ่าน Cloudflare ต้นทางของการเชื่อมต่อที่ไปถึงเซิร์ฟเวอร์ (REMOTE_ADDR) จะเป็น IP address ของ Cloudflare หากปล่อยไว้ ล็อกการเข้าถึง IP ของความเห็น และปลั๊กอินจำกัดการล็อกอิน จะมองผู้เข้าชมทุกคนเป็น IP ของ Cloudflare Cloudflare ส่ง IP ของผู้เข้าชมมาในเฮดเดอร์ CF-Connecting-IP จึงต้องตั้งค่าให้เชื่อเฮดเดอร์นี้เฉพาะเมื่อต้นทางการเชื่อมต่อเป็น Cloudflare เท่านั้น

    หากเขียนทับ REMOTE_ADDR ด้วยค่าในเฮดเดอร์โดยไม่ตรวจสอบต้นทางการเชื่อมต่อ ผู้ที่เข้าถึงต้นทางโดยตรงโดยไม่ผ่าน Cloudflare จะอ้าง IP อะไรก็ได้ผ่านเฮดเดอร์ ด้วยเหตุนี้ จึงไม่ควรใช้โค้ดในบทความเก่าที่เพียงแต่ "ถ้ามี HTTP_CF_CONNECTING_IP ให้กำหนดเข้า REMOTE_ADDR"

    รายการ IP address ของ Cloudflare เผยแพร่ไว้ที่ https://www.cloudflare.com/ips/ รายการนี้เปลี่ยนแปลงได้ จึงควรตรวจทานเป็นระยะ

    กรณีใช้ Nginx

    ใช้ ngx_http_realip_module ระบุช่วง IP ของ Cloudflare ทั้งหมดในบล็อก http หรือ server

    # ช่วง IP ของ Cloudflare (ณ พฤศจิกายน 2026 ตรวจสอบล่าสุดได้ที่ cloudflare.com/ips)
set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
set_real_ip_from 103.22.200.0/22;
set_real_ip_from 103.31.4.0/22;
set_real_ip_from 141.101.64.0/18;
set_real_ip_from 108.162.192.0/18;
set_real_ip_from 190.93.240.0/20;
set_real_ip_from 188.114.96.0/20;
set_real_ip_from 197.234.240.0/22;
set_real_ip_from 198.41.128.0/17;
set_real_ip_from 162.158.0.0/15;
set_real_ip_from 104.16.0.0/13;
set_real_ip_from 104.24.0.0/14;
set_real_ip_from 172.64.0.0/13;
set_real_ip_from 131.0.72.0/22;
set_real_ip_from 2400:cb00::/32;
set_real_ip_from 2606:4700::/32;
set_real_ip_from 2803:f800::/32;
set_real_ip_from 2405:b500::/32;
set_real_ip_from 2405:8100::/32;
set_real_ip_from 2a06:98c0::/29;
set_real_ip_from 2c0f:f248::/32;

real_ip_header CF-Connecting-IP;
    sudo nginx -t && sudo systemctl reload nginx

    กรณีใช้ Apache (Debian / Ubuntu)

    ใช้ mod_remoteip สร้างไฟล์ /etc/apache2/conf-available/remoteip.conf แล้วระบุช่วง IP ของ Cloudflare ใน RemoteIPTrustedProxy

    RemoteIPHeader CF-Connecting-IP
RemoteIPTrustedProxy 173.245.48.0/20 103.21.244.0/22 103.22.200.0/22 103.31.4.0/22
RemoteIPTrustedProxy 141.101.64.0/18 108.162.192.0/18 190.93.240.0/20 188.114.96.0/20
RemoteIPTrustedProxy 197.234.240.0/22 198.41.128.0/17 162.158.0.0/15 104.16.0.0/13
RemoteIPTrustedProxy 104.24.0.0/14 172.64.0.0/13 131.0.72.0/22
RemoteIPTrustedProxy 2400:cb00::/32 2606:4700::/32 2803:f800::/32 2405:b500::/32
RemoteIPTrustedProxy 2405:8100::/32 2a06:98c0::/29 2c0f:f248::/32
    sudo a2enmod remoteip
sudo a2enconf remoteip
sudo apache2ctl configtest
sudo systemctl restart apache2

    หากต้องการให้ล็อกการเข้าถึงแสดง IP จริง ให้เปลี่ยน %h เป็น %a ใน LogFormat (combined) ของ /etc/apache2/apache2.conf

    กรณีแก้การตั้งค่าเซิร์ฟเวอร์ไม่ได้ (wp-config.php)

    หากแก้การตั้งค่าของเว็บเซิร์ฟเวอร์ไม่ได้ เช่นบนโฮสติ้งแบบเช่า ให้ตัดสินแบบเดียวกันใน wp-config.php โดยวางไว้ก่อนบรรทัด require_once ABSPATH . 'wp-settings.php'; จะใช้ค่าของ CF-Connecting-IP (ที่เป็น IP address ที่ถูกต้อง) เฉพาะเมื่อต้นทางการเชื่อมต่ออยู่ในช่วง IP ของ Cloudflare

    <?php
// ใช้ CF-Connecting-IP เป็น IP ของผู้เข้าชมเฉพาะเมื่อผ่าน Cloudflare
$cf_ranges = [
    '173.245.48.0/20', '103.21.244.0/22', '103.22.200.0/22', '103.31.4.0/22',
    '141.101.64.0/18', '108.162.192.0/18', '190.93.240.0/20', '188.114.96.0/20',
    '197.234.240.0/22', '198.41.128.0/17', '162.158.0.0/15', '104.16.0.0/13',
    '104.24.0.0/14', '172.64.0.0/13', '131.0.72.0/22',
    '2400:cb00::/32', '2606:4700::/32', '2803:f800::/32', '2405:b500::/32',
    '2405:8100::/32', '2a06:98c0::/29', '2c0f:f248::/32',
];

function cf_ip_in_range(string $ip, string $cidr): bool
{
    [$net, $bits] = explode('/', $cidr);
    $ip_bin  = inet_pton($ip);
    $net_bin = inet_pton($net);
    if ($ip_bin === false || $net_bin === false || strlen($ip_bin) !== strlen($net_bin)) {
        return false;
    }
    $bits  = (int) $bits;
    $bytes = intdiv($bits, 8);
    if ($bytes > 0 && substr($ip_bin, 0, $bytes) !== substr($net_bin, 0, $bytes)) {
        return false;
    }
    $rest = $bits % 8;
    if ($rest === 0) {
        return true;
    }
    $mask = (0xFF << (8 - $rest)) & 0xFF;
    return (ord($ip_bin[$bytes]) & $mask) === (ord($net_bin[$bytes]) & $mask);
}

if (!empty($_SERVER['HTTP_CF_CONNECTING_IP']) && !empty($_SERVER['REMOTE_ADDR'])) {
    foreach ($cf_ranges as $range) {
        if (cf_ip_in_range($_SERVER['REMOTE_ADDR'], $range)) {
            $visitor = filter_var($_SERVER['HTTP_CF_CONNECTING_IP'], FILTER_VALIDATE_IP);
            if ($visitor !== false) {
                $_SERVER['REMOTE_ADDR'] = $visitor;
            }
            break;
        }
    }
}

    wp-config.php มี <?php อยู่แล้วตั้งแต่ต้น จึงไม่ต้องคัดลอก <?php บรรทัดแรก ให้วางตั้งแต่บรรทัดที่ 2 เป็นต้นไป และสำรองข้อมูล wp-config.php ก่อนวาง

    ขั้นตอนที่ 4: ป้องกันหน้าล็อกอินด้วย Custom rules ของ WAF

    Custom rules ของ WAF ใน Cloudflare สร้างได้สูงสุด 5 กฎบนแผนฟรี และเลือกการดำเนินการอื่นนอกจาก Log ได้ (Block, Managed Challenge เป็นต้น) วิธีสร้างคือที่หน้า Security rules ใน Dashboard เลือก "Create rule" แล้วเลือก "Custom rules" ระบุเงื่อนไข (Field, Operator, Value) และการดำเนินการ แล้วกด "Deploy"

    ตัวอย่างที่ 1: เปิดหน้าล็อกอินและหน้าผู้ดูแลให้เฉพาะ IP ของตนเอง

    เป็นตัวอย่างสำหรับกรณีที่มี IP คงที่ที่บ้านหรือที่ทำงาน เขียนเป็นนิพจน์ได้ดังนี้ (ให้แทน 203.0.113.10 และ 198.51.100.0/24 ด้วย IP ของตนเอง)

    (http.request.uri.path eq "/wp-login.php" or starts_with(http.request.uri.path, "/wp-admin/"))
and http.request.uri.path ne "/wp-admin/admin-ajax.php"
and not ip.src in {203.0.113.10 198.51.100.0/24}

    ตั้งการดำเนินการเป็น Block ส่วน /wp-admin/admin-ajax.php ถูกตัดออกจากเงื่อนไข เพราะฟีเจอร์ของหน้าสาธารณะ เช่นฟอร์มติดต่อหรือการเลื่อนโหลดต่อเนื่อง อาจเรียกใช้ขณะที่ผู้ใช้ยังไม่ได้ล็อกอิน

    ตัวอย่างที่ 2: กรณีไม่มี IP คงที่ ให้คัดกรองด้วยประเทศและ Managed Challenge

    (http.request.uri.path eq "/wp-login.php" or http.request.uri.path eq "/xmlrpc.php")
and not ip.src.country in {"JP"}

    การตัดสินตามประเทศใช้ ip.src.country (รหัส 2 ตัวอักษรตาม ISO 3166-1) ส่วน ip.geoip.country ในบทความเก่าเลิกแนะนำแล้ว สำหรับการดำเนินการ ในช่วงแรกให้ตั้งเป็น Managed Challenge ก่อน ดูใน Security events ว่ามีการเข้าถึงที่ถูกต้องติดอยู่หรือไม่ แล้วจึงเปลี่ยนเป็น Block หากจำเป็น เอกสารของ Cloudflare เองก็แนะนำวิธีนี้ xmlrpc.php ใช้ตอนโพสต์จาก Jetpack หรือแอปบนสมาร์ตโฟน จึงควรตรวจสอบว่าใช้อยู่หรือไม่ก่อนใส่ในเงื่อนไข

    การจำกัดตามประเทศเป็นมาตรการเสริมที่หลบเลี่ยงได้ด้วย VPN เป็นต้น ควรใช้ร่วมกับการยืนยันตัวตนสองขั้นตอนและการจำกัดจำนวนครั้งที่ล็อกอิน วิธีตัดสินประเทศฝั่ง Nginx อธิบายไว้ในวิธีจำกัดการเข้าถึงตามประเทศด้วย Nginx GeoIP2

    ขั้นตอนที่ 5: พฤติกรรมเริ่มต้นของแคชและการล้างแคชเมื่อเผยแพร่

    โดยค่าเริ่มต้น Cloudflare ไม่แคช HTML สิ่งที่แคชคือไฟล์สถิตที่ตัดสินจากนามสกุล เช่น รูปภาพ CSS JavaScript และฟอนต์ และจะไม่แคชการตอบกลับที่มีเฮดเดอร์ Set-Cookie ดังนั้นหากไม่ได้ตั้งค่าอะไรเพิ่ม หน้าผู้ดูแลและหน้าล็อกอินจะไม่ถูก Cloudflare แคช

    หากต้องการแคชถึง HTML ให้ขยายขอบเขตด้วย Cache Rules แต่ต้องยกเว้น /wp-admin/, /wp-login.php, หน้าตัวอย่าง (preview) และการแสดงผลของผู้ใช้ที่ล็อกอินอยู่ ออกจากเป้าหมาย หากยกเว้นผิดพลาด หน้าจอสำหรับผู้ดูแลอาจไปแสดงให้ผู้อื่นเห็นได้ หากไม่มั่นใจ การใช้ค่าเริ่มต้นไว้ปลอดภัยกว่า

    หากแก้ไข CSS หรือรูปภาพแล้วการแสดงผลไม่เปลี่ยน ให้ล้างแคช (purge) จากการตั้งค่าแคชใน Dashboard หากต้องการล้างแคชอัตโนมัติทุกครั้งที่เผยแพร่หรืออัปเดตเรื่อง ให้เรียก API ของ Cloudflare ก่อนอื่นสร้าง API token ที่มีสิทธิ์ "Cache Purge" เท่านั้นใน Cloudflare จากนั้นเขียนลงใน wp-config.php เป็นค่าคงที่ร่วมกับ Zone ID (แสดงในหน้า Overview ของโดเมน)

    define( 'CF_ZONE_ID', 'รหัสโซน' );
define( 'CF_API_TOKEN', 'โทเคน API' );

    วางโค้ดต่อไปนี้ใน functions.php ของ child theme หรือในปลั๊กอินเล็ก ๆ ที่สร้างเอง (ใช้ Code Snippets เป็นต้นก็ได้)

    <?php
// เมื่อเผยแพร่หรืออัปเดตเรื่อง ให้ล้างแคชของเรื่องนั้นและหน้าแรกออกจาก Cloudflare
function cf_purge_urls(array $urls): bool
{
    if (!defined('CF_ZONE_ID') || !defined('CF_API_TOKEN')) {
        return false;
    }

    $response = wp_remote_post(
        'https://api.cloudflare.com/client/v4/zones/' . CF_ZONE_ID . '/purge_cache',
        [
            'headers' => [
                'Authorization' => 'Bearer ' . CF_API_TOKEN,
                'Content-Type'  => 'application/json',
            ],
            'body'    => wp_json_encode(['files' => array_values($urls)]),
            'timeout' => 15,
        ]
    );

    if (is_wp_error($response)) {
        error_log('Cloudflare purge failed: ' . $response->get_error_message());
        return false;
    }

    $result = json_decode(wp_remote_retrieve_body($response), true);
    return !empty($result['success']);
}

add_action('publish_post', function (int $post_id): void {
    if (wp_is_post_revision($post_id) || wp_is_post_autosave($post_id)) {
        return;
    }
    cf_purge_urls([get_permalink($post_id), home_url('/')]);
});

    publish_post ทำงานเมื่อเผยแพร่เรื่อง และเมื่ออัปเดตเรื่องที่เผยแพร่แล้ว purge_cache ของ API นอกจาก files ที่ระบุ URL แล้ว ยังมี purge_everything ที่ล้างทั้งหมด แต่การล้างทั้งหมดจะทำให้ไฟล์สถิตทุกไฟล์ต้องดึงใหม่ จึงไม่ใช้ทุกครั้งที่เผยแพร่เรื่อง

    สิ่งที่ควรตรวจสอบหลังเปลี่ยนมาใช้

    • ผลของ curl -sI มี server: cloudflare และ cf-ray และเบราว์เซอร์แสดงสัญลักษณ์กุญแจ
    • ล็อกอินหน้าผู้ดูแลได้ บันทึกเรื่องและอัปโหลดสื่อได้
    • ความเห็นใหม่และล็อกการเข้าถึงบันทึก IP ของผู้เข้าชม ไม่ใช่ IP ของ Cloudflare
    • ได้รับอีเมลจากฟอร์มติดต่อ (ระเบียน MX ไม่ได้ผ่านพร็อกซี)
    • หากสร้าง Custom rules ของ WAF ไว้ ให้เปิด wp-login.php จากสัญญาณที่ไม่ได้อนุญาต (เช่น เครือข่ายมือถือของสมาร์ตโฟน) แล้วตรวจว่ามีการบล็อกหรือ Challenge

    ปัญหาที่พบบ่อย

    เกิด ERR_TOO_MANY_REDIRECTS

    ตรวจสอบว่าโหมด SSL/TLS เป็น Flexible หรือไม่ ติดตั้งใบรับรองที่ต้นทางแล้วเปลี่ยนเป็น Full (strict) ก็จะหาย

    เข้าหน้าผู้ดูแลไม่ได้

    อาจเป็นเพราะเงื่อนไขของ Custom rules ใน WAF ไม่รวม IP หรือประเทศของตนเอง ให้ปิดกฎชั่วคราวจาก Dashboard ของ Cloudflare ตรวจใน Security events ว่าติดกฎใด แล้วจึงแก้นิพจน์

    ทุกการเข้าถึงดูเหมือนมาจาก IP เดียวกัน

    แสดงว่ายังกู้คืน IP จริงในขั้นตอนที่ 3 ไม่สำเร็จ ถ้าใช้ Nginx ให้ตรวจช่วงของ set_real_ip_from และ real_ip_header ถ้าใช้ Apache ให้ตรวจว่า remoteip เปิดใช้งานอยู่

    สรุป

    • เปลี่ยน Nameserver เป็น 2 ชื่อที่กำหนดให้บัญชีของตนเอง และไม่ผ่านพร็อกซีกับระเบียนสำหรับอีเมล เช่น MX
    • SSL/TLS ใช้ Full (strict) ส่วน Flexible เป็นสาเหตุของการรีไดเรกต์วนซ้ำและ mixed content
    • กู้คืน IP จริงโดยเชื่อ CF-Connecting-IP เฉพาะเมื่อต้นทางการเชื่อมต่ออยู่ในช่วงของ Cloudflare
    • หน้าล็อกอินให้คัดกรอง IP หรือประเทศด้วย Custom rules ของ WAF และในช่วงแรกให้ลองด้วย Managed Challenge ก่อน
    • HTML ไม่ถูกแคชโดยค่าเริ่มต้น การล้างแคชเมื่อเผยแพร่ทำด้วย API token ที่มีสิทธิ์ "Cache Purge" เท่านั้น

    บทความที่เกี่ยวข้อง

    อ้างอิง: Restoring original visitor IPs (Cloudflare), Encryption modes (Cloudflare), Custom rules (Cloudflare WAF), Default cache behavior (Cloudflare)

    Views: 4

    มีคำถามเกี่ยวกับ WordPress ไหม ผู้เผยแพร่เว็บไซต์นี้อยู่ที่ญี่ปุ่นและตอบเป็นภาษาญี่ปุ่น ติดต่อ (ภาษาญี่ปุ่น)

    お気軽にご相談ください

    お見積りへ お問い合わせへ
    閉じる
    ▲