Cloudflare ვებსაიტებისთვის და გეიმ სერვერებისთვის: რას აპროქსირებს

Cloudflare-ის proxy - ნარინჯისფერი ღრუბელი DNS ჩანაწერის გვერდით - HTTP-სა და HTTPS-ს ატარებს პორტების კონკრეტულ სიაზე და სხვა არაფერს. ვებსაიტის წინ რომ დააყენებ, იღებ ქეშირებას, უფასო სერტიფიკატს, ვებ firewall-ს და დამალულ origin მისამართს. თუ მას Minecraft სერვერზე, Ark სერვერზე ან სხვა ნებისმიერზე მიუთითებ, რომელიც საკუთარ პროტოკოლს საკუთარ პორტზე ლაპარაკობს, კავშირი უბრალოდ ჩავარდება, რადგან Cloudflare-ს წასაკითხი HTTP მოთხოვნა არ აქვს. ეს ერთი წინადადება Cloudflare-ის შესახებ დასმული კითხვების დაახლოებით ოთხმოც პროცენტს პასუხობს, ხოლო ამ პოსტის დანარჩენი ნაწილი დეტალია: რომელი პორტები, რომელი პარამეტრები, რომელი შეცდომები და რას არასოდეს იცავს ნარინჯისფერი ღრუბელი, როგორც არ უნდა იყოს კონფიგურირებული.

რას ცვლის სინამდვილეში ნარინჯისფერი ღრუბელი#

Cloudflare შენი ავტორიტეტული DNS ჰოსტია და თითოეულ ჩანაწერს გადამრთველი აქვს. Grey cloud - "DNS only" - ნიშნავს, რომ Cloudflare მოთხოვნას შენი რეალური მისამართით პასუხობს და განზე დგება. ნარინჯისფერი ღრუბელი ნიშნავს, რომ ის თავისი ერთ-ერთი anycast მისამართით პასუხობს, ამ მისამართზე ტრაფიკს ყველაზე ახლო Cloudflare-ის მონაცემთა ცენტრი ამუშავებს, და შემდეგ ის თავის კავშირს ამყარებს შენს სერვერთან.

ყველაფერი დანარჩენი ამ ჩანაცვლებიდან გამომდინარეობს:

• dig www.example.com აბრუნებს Cloudflare-ის მისამართს, მაგალითად 104.21.x.x ან 172.67.x.x, და არასოდეს შენსას.
• TTL ველი Auto-ზე დაბლოკილია, რადგან Cloudflare აკონტროლებს მას.
• შენი origin კავშირებს მხოლოდ Cloudflare-ის დიაპაზონებიდან ხედავს, ამიტომ ვიზიტორის მისამართი header-იდან უნდა მოვიდეს.
• ყველაფერი, რაც მოთხოვნას ამოწმებს ან ცვლის - ქეშირება, firewall, გადამისამართებები, შეკუმშვა - მხოლოდ დაპროქსირებულ ჩანაწერებზე შეიძლება მოხდეს.

ზონა თითქმის ყოველთვის შერეული გამოდის: www და apex ნარინჯისფერია, play და mail - ნაცრისფერი. ეს კომპრომისი არ არის, ეს სწორი კონფიგურაციაა. DNS ჩანაწერები ახსნილი გიხსნის ჩანაწერების ტიპებს, თუ A/CNAME/SRV განსხვავება შენთვის ახალია.

პორტები, რომლებსაც აპროქსირებს, და ყველაფერი დანარჩენი#

დაპროქსირებული ჩანაწერი კავშირს მხოლოდ Cloudflare-ის მხარდაჭერილ პორტებზე იღებს. ყველაფერი დანარჩენი უარყოფილია ან timeout-ს იღებს, სწორედ ამიტომ არის "ნარინჯისფერი ღრუბელი ჩავრთე და ჩემი საიტი 3000 პორტზე გაჩერდა" ყოველკვირეული კითხვა.

შეამჩნიე, რა არ არის იქ: 25 (SMTP), 3306, 5432, 22, 25565, 27015 და ყველა UDP პორტი, რაც კი არსებობს. Proxy HTTP reverse proxy-ა. ის წყვეტს TLS-ს, კითხულობს მოთხოვნას, წესებს იყენებს და გადააგზავნის. პროტოკოლი, რომელსაც ვერ კითხულობს, პროტოკოლია, რომლის დაპროქსირებაც არ შეუძლია.

Cloudflare-ს ნედლი TCP-სთვის პროდუქტიც აქვს - Spectrum - ფასიანი დანამატი: ნებისმიერი TCP აპლიკაცია Business და Enterprise გეგმებზე, Minecraft-ის მხარდაჭერით უფრო დაბალ დონეებზეც. ფასები და გეგმების საზღვრები იცვლება, ამიტომ დაგეგმვამდე მიმდინარე გეგმის გვერდი შეამოწმე და პატიოსნად შეადარე უბრალოდ ნორმალური ჰოსტის ფასს.

გეიმ სერვერები და ნარინჯისფერი ღრუბელი#

ამ თავისთვის მოდის ხალხი, ამიტომ ყველაფერი პირდაპირ.

თამაშის ტრაფიკი უფასო Cloudflare proxy-ში ვერ გაივლის. თამაშების უმეტესობა UDP-ს იყენებს, რომელსაც HTTP proxy საერთოდ არ ატარებს. თამაშები, რომლებიც TCP-ს იყენებენ - მაგალითად Minecraft Java 25565-ზე - პორტს იყენებენ, რომელიც მხარდაჭერილ სიაში არ არის. ნარინჯისფერი ღრუბლის ჩართვა თამაშის ჩანაწერზე ორიდან ერთ შედეგს იძლევა: კლიენტი ვერ უკავშირდება, ან უკავშირდება Cloudflare-ის ვებ edge-ს და handshake-ის ნაცვლად HTTP შეცდომას იღებს.

თამაშის სერვერის ჩანაწერი ნაცრისფერი რჩება. ეს ნორმალურია და ყველა ჰოსტი სწორედ ამას ელოდება:

Type   Name    Content          ProxyA      play    203.0.113.10     DNS onlySRV    _minecraft._tcp.play     DNS only

SRV ჩანაწერების დაპროქსირება საერთოდ შეუძლებელია - Cloudflare გადამრთველს არც შემოგთავაზებს - და თუ hostname, რომელზეც SRV ჩანაწერი მიუთითებს, თავად არის ნარინჯისფერ ღრუბელში, ძებნა Cloudflare-ზე გადაიწყვეტა და კავშირი ჩავარდება. როგორც SRV, ისე A ჩანაწერი, რომელზეც ის მიუთითებს, DNS only უნდა იყოს. SRV ჩანაწერები Minecraft-ისთვის გიხსნის ფორმატს, ხოლო დომენის მიბმა გეიმ სერვერზე - ჩვეულებრივ A ჩანაწერს.

ორი შედეგი გამომდინარეობს, და მეორე არასასიამოვნოა.

პირველი, Cloudflare გეიმ სერვერის მისამართს არ მალავს. ნაცრისფერი ჩანაწერი მას აქვეყნებს, რადგან უნდა გამოაქვეყნოს - კლიენტმა შენს მანქანას პირდაპირ უნდა მიაღწიოს. ნებისმიერს, ვისაც DNS-ის წაკითხვა შეუძლია, ეს მისამართი შეუძლია წაიკითხოს, მათ შორის მას, ვინც მასზე თავდასხმას გეგმავს.

მეორე, შენს ვებსაიტზე ნარინჯისფერი ღრუბელი იმავე მისამართზე მყოფ გეიმ სერვერს არაფრით იცავს. თუ შენი ვებ ჩანაწერები დაპროქსირებულია, თამაშის ჩანაწერი კი არა, არაფერი დაგიმალავს: play-ის A ჩანაწერი იმავე IP-ს ამხელს, რომელზეც ვებსაიტია. ეს origin მისამართის გაჟონვის ყველაზე გავრცელებული გზაა.

გეიმ სერვერს ნამდვილად იცავს ფილტრაცია მის ზემოთ, ქსელში, რომელზეც შენი ჰოსტი მუშაობს. RE:NODE-ზე ფორმულირება განზრახ ვიწროა: upstream ფილტრაცია, რომელიც აშკარა მოცულობით ნაკადებს, ასევე reflection-სა და დაზიანებულ ტრაფიკს ჩამოაგდებს. თავდასხმები, რომლებიც რეალურ მოთამაშეებს ჰგავს, არ ფილტრება, რადგან ამ მომენტში თამაშის ცოდნის გარეშე მათი რეალური მოთამაშეებისგან გარჩევა შეუძლებელია. ჰოსტი, რომელიც ნებისმიერი თავდასხმისას უდანაკარგო მუშაობას გპირდება, გყიდის წინადადებას და არა სერვისს - რას ვაკეთებთ თავდასხმებისას უფრო გრძელი ვერსიაა, ხოლო DDoS თავდასხმები გეიმ სერვერებზე ახსნილი თავდასხმის ტიპებს განიხილავს.

SSL რეჟიმები, სერტიფიკატები და გადამისამართების ციკლები#

SSL/TLS-ში არის რეჟიმის პარამეტრი, რომელიც წყვეტს, როგორ ესაუბრება Cloudflare შენს origin-ს, და არასწორის არჩევა ორ ძალიან გავრცელებულ ჩავარდნას იწვევს.

Flexible ხაფანგია. ვიზიტორები HTTPS-ს ხედავენ, მაგრამ კავშირი Cloudflare-დან შენს სერვერამდე უბრალო HTTP-ია საჯარო ინტერნეტში, ამიტომ ბოქლომი ვიზიტორს არასწორ რამეს ეუბნება. ის ასევე ქმნის კლასიკურ ERR_TOO_MANY_REDIRECTS-ს: Cloudflare აგზავნის HTTP მოთხოვნას, შენი სერვერი HTTP-ს HTTPS-ზე გადაამისამართებს, Cloudflare ამ გადამისამართებას თავისკენვე მიჰყვება, და ასე უსასრულოდ. თუ საიტი Cloudflare-ის ჩართვისთანავე ციკლში ვარდება, მიზეზი ესაა - გადადი Full (strict)-ზე.

Full (strict)-ს origin-ზე ვალიდური სერტიფიკატი სჭირდება. ან ის, რომელსაც შენი ჰოსტი უკვე გასცემს, ან უფასო Cloudflare Origin CA სერტიფიკატი, რომელსაც მხოლოდ Cloudflare ენდობა და შეიძლება თხუთმეტ წლამდე გაიცეს. ორივე მუშაობს; ჰოსტის გაცემული დასამახსოვრებლად ნაკლებია.

მართულ ჰოსტზე ის, რაც ტკივილს იწვევს, სერტიფიკატის განახლებაა. HTTP-01 ვალიდაციამ შენს origin-ს 80 პორტზე უნდა მიაღწიოს /.well-known/acme-challenge/-ზე, და firewall-ის წესი, გადამისამართება ან Flexible რეჟიმი ყველა შეუძლია ჩუმად შეაჩეროს. RE:NODE-ზე აპლიკაციისა და ვებ გეგმები მოიცავს proxy სლოტს, რომელიც სერტიფიკატს ავტომატურად გასცემს და ანახლებს 21-დღიან ფანჯარაში, რაც ნიშნავს, რომ Cloudflare-ში შენ მიერ დაყენებულით დაბლოკილი განახლება დღეს არ ჩავარდება - ორი თვის შემდეგ ჩავარდება, როცა არსებული სერტიფიკატი ვადას გაივლის. თუ Cloudflare-ს ჰოსტის მიერ მართული სერტიფიკატის წინ აყენებ, ჩანაწერი განახლების დასასრულებლად საკმარის ხანს დატოვე ნაცრისფერი, ან ჰოსტი DNS ვალიდაციაზე გადაიყვანე, თუ ის მას გთავაზობს. HTTPS და Let's Encrypt ახსნილი გიხსნის, როგორ მუშაობს ვალიდაცია.

ორი პარამეტრი ღირს ჩართვად, როცა Full (strict) უკვე მუშაობს: Always Use HTTPS, რომელიც HTTP-დან HTTPS-ზე გადამისამართებას edge-ზე აკეთებს, რომ შენს სერვერს უბრალო მოთხოვნა არასოდეს ეჩვენოს, და Automatic HTTPS Rewrites, რომელიც შენს საკუთარ HTML-ში mixed-content მითითებებს ასწორებს.

ქეშირება: რა ქეშირდება ნაგულისხმევად და რა არა#

ნაგულისხმევად Cloudflare სტატიკურ რესურსებს ფაილის გაფართოებით ქეშირებს - სურათები, CSS, JavaScript, შრიფტები - და HTML-ს არა. WordPress საიტისთვის ან ნებისმიერი დინამიური აპლიკაციისთვის ეს ნიშნავს, რომ ყოველი გვერდის ნახვის ძვირი ნაწილი მაინც შენს სერვერამდე აღწევს. ხალხი მუდმივად უკვირს ეს, რადგან ფიქრობდნენ, რომ ნარინჯისფერი ღრუბელი საიტს სწრაფს ხდის.

HTML-ის დასაქეშირებლად ქმნი Cache Rule-ს, რომელიც აყენებს "Eligible for cache"-ს (ძველი Page Rules-ის "Cache Everything"-ის შემცვლელი), და შემდეგ უნდა მოაგვარო შესული მომხმარებლის შემთხვევა. ერთი ვიზიტორის dashboard-ის edge-იდან ყველასთვის მიწოდებით მონაცემთა გაჟონვას ქმნი ერთი ჩარჩოთი. წესები, რომლებიც ამას უსაფრთხოს ინახავს:

• ქეში გამოტოვე, როცა სესიის cookie არის - wordpress_logged_in_*, PHPSESSID, შენი framework-ის cookie-ს სახელი.
• ქეში მთლიანად გამოტოვე admin ბილიკებისთვის და ნებისმიერი API-სთვის, რომელიც თითო მომხმარებლის მონაცემებს აბრუნებს.
• დასაწყისში მოკლე edge TTL დააყენე და გაზარდე, როცა დაიჯერებ.

უფრო სუფთა მიდგომა ისაა, რომ შენი საკუთარი header-ები წარმართავდეს. Cache-Control: public, max-age=31536000, immutable ჰეშირებულ რესურსების სახელებზე და Cache-Control: private, no-store პერსონალურ ყველაფერზე პოლიტიკაა, რომელიც ყველა CDN-ზე მუშაობს და არა ერთი მომწოდებლის dashboard-ზე. HTTP ქეშირების header-ები ახსნილი header-ების ნაკრებს სათანადოდ განიხილავს.

ორი ოპერაციული შენიშვნა. Development Mode ქეშს სამი საათით ტოვებს და თავისით ითიშება, რაც გჭირდება თემის რედაქტირებისას. და გაასუფთავე URL-ით და არა ყველაფერი - დატვირთულ საიტზე სრული გასუფთავება ყველა მოთხოვნას ერთდროულად შენს origin-ზე აგზავნის, რაც საკუთარი ხელით გამოწვეული დატვირთვის მწვერვალია.

უსაფრთხოების პარამეტრები, რომლებიც ღირს და ორი, რომლებიც ტეხავს#

ნამდვილად სასარგებლოები, პატარა საიტზე მნიშვნელობის მიხედვით:

• Managed WAF წესები. უფასო გეგმებს ქვენაკრები აქვთ და ის ავტომატური სისულელის დიდ რაოდენობას PHP-მდე მისვლამდე აჩერებს.
• Rate limiting. უფასო გეგმებს ერთი წესი აქვთ. დახარჯე login endpoint-ზე - სწორედ იქ მიდის credential stuffing.
• ქვეყნით ან ASN-ით დაბლოკვა, თუ შენი აუდიტორია მართლა რეგიონულია. უხეშია, მაგრამ კონკრეტული პრობლემის წინააღმდეგ ეფექტური.
• ბილიკით დაბლოკვა. /wp-login.php, /xmlrpc.php და /.env მოთხოვნები ყველგანიდან, შენი მისამართის გარდა, დაბლოკვას არაფერი უჯდება და თავდამსხმელის გახსნის მოძრაობის უმეტესობაა.

ორი, რომელიც ტეხავს და რომელსაც ხალხი რთავს და ავარიას პარამეტრს არ უკავშირებს:

Bot Fight Mode აჩენს გამოწვევას ყველაფერზე, რასაც ბრაუზერად არ თვლის. მათ შორის შენი გადახდის პროვაიდერის webhook-ები, შენი GitHub deploy hook, შენი uptime მონიტორი, შენი მობილური აპი და შენი RSS მკითხველები. სიმპტომი არის 403, რომელიც შენს ლოგებში არასოდეს ჩნდება, რადგან შენი სერვერისთვის არავის უკითხავს. თუ რაიმე machine-to-machine ტრაფიკი გაქვს, გამორთული დატოვე ან ეს ბილიკები გამორიცხე.

Under Attack mode ყველა ვიზიტორს ხუთწამიან შუალედურ გვერდს აჩვენებს გატარებამდე. ის ნაკადის წინააღმდეგ მუშაობს და ყველა API კლიენტსა და ყველა WebSocket handshake-ს ტეხავს, სანამ ჩართულია. ეს საგანგებო გადამრთველია და არა კონფიგურაცია - გამორთე, როცა საგანგებო მდგომარეობა მთავრდება. თავად WebSocket-ები ყველა გეგმაზე ნორმალურად პროქსირდება; მათ გამოწვევა კლავს, ხოლო WebSocket-ები reverse proxy-ს უკან განიხილავს მეორე idle-timeout ქცევას, რომელიც უნდა ელოდო.

ვიზიტორის რეალური მისამართის დანახვა#

დაპროქსირების შემდეგ ყველა კავშირი Cloudflare-იდან მოდის. შენი access ლოგი მათი დიაპაზონებით ივსება, IP-ით rate limiting ყველას ერთდროულად ზღუდავს, და ნებისმიერი გეოლოკაცია, რასაც აკეთებ, მონაცემთა ცენტრს ზომავს.

რეალური მისამართი მოდის CF-Connecting-IP-ში და ასევე X-Forwarded-For-ს ემატება. nginx-ში აღადგინე, რომ ლოგებმა, rate limit-ებმა და აპლიკაციის კოდმა სიმართლე დაინახოს:

# Repeat set_real_ip_from for every range published at cloudflare.com/ipsset_real_ip_from 173.245.48.0/20;set_real_ip_from 103.21.244.0/22;real_ip_header CF-Connecting-IP;

ეს header არასოდეს ენდო წყაროსგან, რომელიც Cloudflare არ არის. ის ჩვეულებრივი მოთხოვნის header-ია, ამიტომ ნებისმიერს, ვინც შენს origin-თან პირდაპირ უკავშირდება, შეუძლია მასში რაც უნდა ის ჩაწეროს - სწორედ ამიტომ არის set_real_ip_from სია მნიშვნელოვანი. მართულ ჰოსტზე nginx-ს ჩვეულებრივ ვერ ცვლი, მაგრამ იგივე ლოგიკა ვრცელდება header-ზე, რომელსაც შენი პლატფორმა გაძლევს: RE:NODE-ზე proxy სლოტი კლიენტის ორიგინალ მისამართს X-Forwarded-For-ში გადასცემს, და თუ ჯაჭვში Cloudflare-იც არის, ეს header ხდება სია, სადაც ყველაზე მარცხენა ჩანაწერი ვიზიტორია და ყოველი ნახტომი წინას ამატებს.

ამის მეორე ნახევარი firewall-ია, რომელიც 80-სა და 443-ზე კავშირებს მხოლოდ Cloudflare-იდან იღებს, რომ ვერავინ გვერდი ვერ აუაროს proxy-ს შენს მისამართზე პირდაპირ დაკავშირებით. შენს საკუთარ VDS-ზე ეს რამდენიმე ufw წესია და Authenticated Origin Pulls. გაზიარებულ, კონტეინერზე დაფუძნებულ ჰოსტზე ეს ზოგადად არ არის ის, რასაც აკონტროლებ, რაც რეალური შეზღუდვაა და ღირს ცოდნად და არა ვარაუდად.

Cloudflare-ის შეცდომის გვერდების წაკითხვა#

Cloudflare-ის ხუთასეული შეცდომები კონკრეტულია და თითოეული სისტემის სხვადასხვა ნახევარზე მიუთითებს. ეს ცხრილი ბევრ გამოცნობას გვაშორებს:

განსხვავება, რომელიც უნდა გაითავისო, 521-სა და 522-ს შორისაა. უარყოფილი კავშირი ნიშნავს, რომ რაღაცამ "არა" უპასუხა - პორტი დახურულია ან reject-ით გაფილტრული. Timeout ნიშნავს, რომ არაფერს უპასუხია, რაც დატვირთულ სერვერზე მოთხოვნების რიგის გადავსებას ნიშნავს, ხოლო გაფილტრულზე - პაკეტების ჩამოგდებას. შენი საკუთარი ლოგების შემოწმება მაშინვე პასუხობს: თუ მოთხოვნისთვის ჩანაწერი არ არის, ის არასოდეს მისულა.

524 ცალკე ხსენებას საჭიროებს, რადგან ის სინამდვილეში შეცდომა არ არის. მოთხოვნა, რომელიც დაახლოებით 100 წამზე მეტ ხანს გრძელდება, edge-ზე წყდება, და ქვედა გეგმებზე ეს ლიმიტი კონფიგურირებადი არ არის. მუშაობა, რომელიც წუთებს გრძელდება, საერთოდ არ უნდა მოხდეს მოთხოვნის შიგნით - ის რიგში უნდა ჩადგეს და polling-ით გადაამოწმო. ფონური დავალებები პატარა სერვერზე გიხსნის, როგორ გადაიტანო.

რას არ გააკეთებს Cloudflare შენთვის#

მოკლე, პატიოსანი სია, რადგან მარკეტინგი ამას თავისით არ ამბობს.

• ის შენს ელფოსტას არ უმასპინძლებს. MX ჩანაწერები DNS only უნდა იყოს, და თუ შენი საფოსტო სერვერი ვებ სერვერთან მისამართს იზიარებს, ეს MX ჩანაწერი შენს origin-ს აქვეყნებს. Cloudflare-ის Email Routing ფოსტას გადააგზავნის; ის საფოსტო ყუთი არ არის. RE:NODE ელფოსტასაც არ უმასპინძლებს.
• ის მისამართს არ მალავს, რომელიც უკვე გაჟონა. DNS-ის ძველმა ისტორიამ, ნაცრისფერმა ქვედომენმა, სერტიფიკატის გამჭვირვალობის ლოგის ჩანაწერმა ან აპლიკაციამ, რომელიც გამავალ მოთხოვნებს აკეთებს, ყველამ შეიძლება გასცეს. Proxy-ს ჩართვის შემდეგ origin მისამართის შეცვლა ერთადერთი რეალური გამოსწორებაა.
• ის ნელ აპლიკაციას სწრაფს არ ხდის. დაუქეშირებელი HTML მაინც შენი სერვერიდან მოდის, შენი სერვერის სისწრაფით. თუ მონაცემთა ბაზის მოთხოვნას 800 ms სჭირდება, მას 800 ms სჭირდება ნარინჯისფერი ღრუბლით წინ.
• ის არა-HTTP სერვისებს არ ფარავს. მონაცემთა ბაზები, SSH, თამაშის პორტები და ფოსტა მას მთლიანად გვერდს უვლიან, და თითოეული შენს მანქანამდე პირდაპირი გზაა, რომელსაც შენმა firewall-მა უნდა გაუმკლავდეს.
• ის შეუზღუდავ ატვირთვებს არ იღებს. უფასო და Pro გეგმები მოთხოვნის ტანს 100 MB-ით ზღუდავენ. დიდი ფაილების ატვირთვა სხვაგან უნდა წავიდეს, ან ნაცრისფერი hostname-ით.
• ის backup-ებს, განახლებებს ან firewall-ს არ ცვლის. ის ტრაფიკს მის მოსვლამდე ფილტრავს; ყველაფერი ამის შემდეგ ისევ შენია.

იმისთვის გამოყენებული, რაც არის - HTTP edge ვებსაიტის წინ - ის შესანიშნავია, უფასოა და ოცი წუთი სჭირდება დასაყენებლად. გეიმ სერვერის ფარად გამოყენებული, ეს გაუგებრობაა, რომელიც შუადღეს ჯდება.

FAQ#

შემიძლია Cloudflare-ის proxy Minecraft სერვერისთვის გამოვიყენო?

უფასო გეგმაზე არა. Minecraft Java იყენებს TCP 25565-ს, რომელიც დაპროქსირებულ პორტებს შორის არ არის, და proxy მხოლოდ HTTP-ს იგებს. დატოვე ჩანაწერი DNS only, ან შეხედე Spectrum-ს, რომელიც ფასიანი დანამატია Minecraft-ის მხარდაჭერით.

მალავს ნარინჯისფერი ღრუბელი ჩემი გეიმ სერვერის IP მისამართს?

არა. ჩანაწერი, რომელსაც თამაშის კლიენტი იყენებს, DNS only უნდა იყოს, ამიტომ განსაზღვრებით შენს რეალურ მისამართს აქვეყნებს. თუ შენი ვებსაიტი დაპროქსირებულია, მაგრამ იმავე მისამართს იზიარებს, თამაშის ჩანაწერი ორივეს ამხელს.

რატომ დაიწყო ჩემმა საიტმა ციკლში გადამისამართება Cloudflare-ის ჩართვის შემდეგ?

SSL რეჟიმი Flexible-ია, ამიტომ Cloudflare შენს origin-ს უბრალო HTTP-ით ეკითხება, შენი origin HTTPS-ზე გადაამისამართებს, და Cloudflare გადამისამართებას საკუთარ თავს მიჰყვება. გადადი Full (strict)-ზე origin-ზე ვალიდური სერტიფიკატით.

მხარდაჭერილია WebSocket-ები?

დიახ, ყველა გეგმაზე, ჩასართავი პარამეტრის გარეშე. უმოქმედო კავშირები დაახლოებით 100 წამის შემდეგ იხურება, ამიტომ heartbeat ყოველ 30 წამში გააგზავნე, და bot გამოწვევები WebSocket ბილიკს მოაშორე.

რატომ ხედავს ჩემი სერვერი Cloudflare-ის IP-ს და არა ვიზიტორისას?

იმიტომ, რომ კავშირს Cloudflare ამყარებს და არა ვიზიტორი. წაიკითხე CF-Connecting-IP, ან გაუწყე შენს proxy-ს, მისგან რეალური მისამართი აღადგინოს, და ეს header მხოლოდ მაშინ ენდე, როცა კავშირი Cloudflare-ის გამოქვეყნებული დიაპაზონიდან მოდის.

ცვლის Cloudflare იმას, რასაც ჩემი ჰოსტი თავდასხმებზე აკეთებს?

არა, და ვერც შეძლებს, რადგან ის მხოლოდ იმ ტრაფიკს ხედავს, რომელიც proxy-ში გადის. ფილტრაცია სერვერის ზემოთ მაინც მნიშვნელოვანია ყველაფრისთვის დანარჩენისთვის - თამაშის პორტები, მონაცემთა ბაზის პორტი და ყველაფერი DNS-only ჩანაწერზე.