استخبارات IP

اكتشاف iCloud Private Relay وCloudflare WARP، ثم تمريرهما

اكتشف iCloud Private Relay بقائمة مخارج Apple المكوّنة من 285,091 صفًّا واستعلامات الواجهة الحية، واعرف لماذا لا توجد قائمة عامة لـ Cloudflare WARP، ودع مستخدمي المرحِّل يمرّون.

بقلمفريق GeoIPHubتاريخ النشر12 أكتوبر 2026مدة القراءةقراءة في 18 دقيقة

نزّلنا قائمة Apple الساعة 09:40 بالتوقيت العالمي في 12 أكتوبر 2026. وكانت تضم 285,091 بادئة، منها 41,734 IPv4 و243,357 IPv6، موزعة على 235 رمز دولة. وداخل النطاق 104.28.0.0/16 التابع لـ Cloudflare يوجد 19,723 عنوانًا من أصل 65,536 على القائمة. والـ 45,813 الباقية ليست عليها، لذا فإن قاعدة تُكتب على ذلك النطاق، أو على شبكة Cloudflare كلها، لا تستطيع التمييز بين مستخدم Private Relay وأي حركة أخرى موجَّهة عبرها.

نحلّل أدناه ملف Apple ونقدّم مطابِقًا مختبَرًا بلغة Python لـ IPv4 وIPv6. ونشرح ما يمكن وما لا يمكن معرفته عن WARP، ونعرض استعلامات حقيقية لعناوين مرحِّل، منها موضعان يختلف فيهما تحديدنا الجغرافي عن تحديد Apple. وينتهي المقال بجدول سياسة. ولمجموعة أوسع من إشارات أدوات إخفاء الهوية، ابدأ بـ كيف يعمل اكتشاف VPN والبروكسي.

تنشر Apple كل بادئة لمخارج المرحِّل، لذا فالمطابقة التامة ممكنة.

كيف تكتشف iCloud Private Relay: طابِق قائمة Apple نفسها

تنشر Apple كل بادئة لمخارج Private Relay في ملف CSV واحد، لذا فإن المطابقة التامة تخبرك بأن عنوان IP مخرج مرحِّل. ويوجّه دليل Apple لمشغِّلي الشبكات والخوادم الخوادم إلى تلك القائمة، أو إلى علم من مزود:

"يمكن لخادمك التعرف على حركة Private Relay باستخدام قائمة عناوين IP الخاصة بـ Private Relay أعلاه، أو بالتحقق من كيفية تصنيفها لدى مزود قاعدة بيانات geo IP الخاص بك."

وتذكر الصفحة نفسها الحقول التي ينبغي البحث عنها: "قد تشمل الحقول الأخرى ذات الصلة: 'is_relay' أو 'is_hosting' أو 'privacy_service' أو 'privacy_proxy'." أي أن Apple تتوقع منك استخدام قائمتها أو حقل مثل الذي تعيده واجهتنا.

وهذه القائمة نظيفة أيضًا على نحو لا تتصف به معظم قوائم IP. فتقول نظرة Apple العامة على Private Relay في ديسمبر 2021 إن عناوين IP الخاصة بالمرحِّل "لا تُستخدم ولا تُشارَك لأي غرض سوى تقديم خدمة Private Relay." فلا آثار جانبية للمطابقة التامة. لا أحد غيرهم تخرج حركته من تلك العناوين.

ما في ملف CSV لمخارج Apple

يوجد الملف في https://mask-api.icloud.com/egress-ip-ranges.csv. نزّلناه وحلّلنا كل صف باستخدام وحدة ipaddress في Python.

المقياس	القيمة (جُلب في 2026-10-12، 09:40 بالتوقيت العالمي)
الصفوف (البادئات)	285,091
بادئات IPv4	41,734
بادئات IPv6	243,357
عناوين IPv4 المغطاة	105,647
رموز الدول المتميزة	235
الأعمدة	5: البادئة والدولة والمنطقة والمدينة وحقل أخير فارغ
حجم الملف	12,047,231 بايت
البادئات المتداخلة	لا يوجد

كل صف سطر بصيغة geofeed. وهذان صفان حقيقيان من الملف:

GeoIPHub API

172.224.226.0/27,GB,GB-EN,London,
104.28.46.99/32,ZM,,Lusaka,

يحتوي الصف الثاني على منطقة فارغة، لذا يجب أن يقبل المحلِّل لديك الحقول الفارغة. وهناك فخ في العدّ: يطبع wc -l القيمة 285,090، أي أقل بواحد، لأن الملف لا ينتهي بسطر جديد. فاعدّ الصفوف المحلَّلة بدلًا من ذلك.

الاستعلام الدوري عن الملف رخيص. فقد أعاد الخادم ETag بالقيمة "6acc40fb-b7d37f"، وأجاب طلبنا الشرطي بـ 304 Not Modified. ولا تذكر Apple عدد مرات تحديث القائمة، لذا لن نخمّن. اختر جدول تحديث يناسبك.

لماذا لا تكفي قاعدة ASN أو /16

يتشارك مخرج المرحِّل الشبكات مع حركة أخرى. ففي 104.28.0.0/16 يوجد 19,723 عنوانًا من أصل 65,536 على قائمة Apple، والباقي ليس عليها. وتقول نظرة Apple العامة إن المرحِّل الثاني "تشغّله جهات شريكة من أكبر شبكات توصيل المحتوى (CDN) في العالم." والمرحِّلات الثلاثة التي أخذنا عينة منها تقع على اثنتين منها، Cloudflare (AS13335) وAkamai (AS36183).

وحجب AS13335 يصيب أكثر بكثير من مستخدمي المرحِّل. ووضعه في قائمة السماح يُدخل أكثر بكثير من المرحِّلات. إن مطابقة البادئة هي الأداة الدقيقة، ويمكنك فحص أي عنوان IP بحثًا عن VPN أو مرحِّل لترى كيف يُصنَّف عنوان منفرد.

لماذا لا يُعد عنوان المرحِّل عنوان VPN

يخفي Private Relay عنوان IP للمستخدم عن الموقع لكنه يبقيه في منطقته الحقيقية، ويغطي بعض الحركة فقط، ويقتصر على أجهزة Apple الموثَّقة ذات الحسابات المدفوعة. ولهذا لا ينبغي تسجيله كما يُسجَّل VPN.

يقسّم التصميم المعرفة بين مرحِّلين تديرهما شركتان مختلفتان. تدير Apple الأول، وهو يرى عنوان المستخدم لكنه لا يرى الموقع. وتدير جهة شريكة الثاني، وهو يرى الموقع لكنه لا يرى المستخدم. وتقول صفحة Apple لمشغِّلي الشبكات إنه بهذه الطريقة لا يستطيع أي طرف منفرد، بما في ذلك Apple، رؤية تفاصيل تصفح المستخدم.

القفزة	ترى عنوان IP للمستخدم	ترى أي موقع
iPhone أو iPad أو Mac الخاص بالمستخدم	نعم	نعم
المرحِّل الأول (Apple)	نعم	لا
المرحِّل الثاني (شبكة شريكة، مثل Cloudflare أو Akamai)	لا	نعم
خادمك	لا، عنوان المرحِّل فقط	هو الموقع

أربعة أسطر من صفحة Apple لمشغِّلي الشبكات تغيّر الطريقة التي ينبغي أن تعامل بها هذه العناوين:

النطاق. "يحمي Private Relay تصفح المستخدمين للويب في Safari، واستعلامات حل DNS، وحركة تطبيقات http غير الآمنة." فعنوان المرحِّل لا يعني جلسة Safari. فتطبيق يجري طلبات http عادية يصل بالطريقة نفسها.
المنطقة. "يحافظ Private Relay على المنطقة التي يوجد فيها المستخدم، فيمكن لخادمك الوثوق بالمنطقة المخصصة لعنوان IP الذي يراه." وتضيف نظرة 2021 العامة أنه "لا يسمح للمستخدمين بتقديم أنفسهم على أنهم متصلون من بلد أو منطقة مختلفة."
التحقق. "تتحقق جميع الاتصالات التي تستخدم Private Relay من أن العميل iPhone أو iPad أو Mac ومن أن العميل لديه اشتراك iCloud+ صالح."
الثبات. "يبقى عنوان IP للمرحِّل ثابتًا خلال جلسة التصفح بينما يتفاعل المستخدم مع موقعك."

أما VPN فيتيح للمستخدم اختيار أي بلد ويغطي الجهاز كله. وCloudflare صريحة بشأن منتجها: "من الناحية التقنية، WARP هو VPN"، كما كتبت عندما أطلقت WARP. ونعود إلى WARP أدناه.

وثمة فخ عملي: بعض مخارج المرحِّل تقع في مراكز بيانات، فقد تُفعَّل أعلام الاستضافة. إذ يعيد استعلامنا عن 172.224.226.1، وهو مرحِّل على قائمة Apple، القيمة is_hosting: true. وهذا هو سبب ظهور المرحِّلات كعناوين IP لمراكز البيانات، ولماذا يصيب حجب الاستضافة الشامل عملاء Apple.

طابِق عنوان IP مع قائمة Apple بلغة Python

حمّل ملف CSV في نطاقات أعداد صحيحة مرتبة، قائمة واحدة لكل إصدار IP، وابحث فيها بحثًا ثنائيًّا. حدّثه بطلب شرطي، واحتفظ بآخر نسخة سليمة إذا فشل التنزيل أو بدا خاطئًا.

هذا هو السكربت نفسه الذي شغّلناه في 2026-10-12 على Python 3.9.6. ويستخدم المكتبة القياسية فقط.

GeoIPHub API

"""Match an IP against Apple's iCloud Private Relay egress list. Standard library only."""
import bisect, csv, ipaddress, os, tempfile, time, urllib.error, urllib.request

URL = "https://mask-api.icloud.com/egress-ip-ranges.csv"
CSV_PATH, ETAG_PATH, MIN_ROWS = "egress.csv", "egress.etag", 100_000

def load(path):
    """Parse the CSV into one sorted range list per IP version, then validate it."""
    ranges = {4: [], 6: []}
    with open(path, newline="") as f:
        for row in csv.reader(f):
            if len(row) != 5:
                raise ValueError(f"bad row: {row}")
            net = ipaddress.ip_network(row[0], strict=False)
            ranges[net.version].append((int(net.network_address), int(net.broadcast_address), *row[:4]))
    index = {}
    for version, rs in ranges.items():
        rs.sort()
        if any(b[0] <= a[1] for a, b in zip(rs, rs[1:])):
            raise ValueError(f"overlapping IPv{version} prefixes")
        index[version] = ([r[0] for r in rs], rs)
    return index, len(ranges[4]) + len(ranges[6])

def refresh(index=None, rows=0):
    """Fetch a new copy only if it changed. On any failure, keep serving the last good one."""
    headers = {}
    if index and os.path.exists(ETAG_PATH):
        headers["If-None-Match"] = open(ETAG_PATH).read().strip()
    fd, tmp = tempfile.mkstemp(dir=".", suffix=".part")
    os.close(fd)
    try:
        with urllib.request.urlopen(urllib.request.Request(URL, headers=headers), timeout=60) as resp:
            with open(tmp, "wb") as out:
                out.write(resp.read())
            etag = resp.headers.get("ETag", "")
        new_index, new_rows = load(tmp)
        if new_rows < max(MIN_ROWS, 0.9 * rows):
            raise ValueError(f"only {new_rows} rows, keeping the old file")
        os.replace(tmp, CSV_PATH)  # atomic swap
        with open(ETAG_PATH, "w") as f:
            f.write(etag)
        print(f"downloaded new list: {new_rows:,} prefixes")
        return new_index, new_rows
    except urllib.error.HTTPError as e:
        print("not modified, keeping current list" if e.code == 304 else f"refresh failed: {e}")
    except Exception as e:
        print(f"refresh failed: {e}")
    finally:
        if os.path.exists(tmp):
            os.remove(tmp)
    return index, rows

def match(index, ip):
    """Return Apple's row for a relay egress IP, or None."""
    try:
        addr = ipaddress.ip_address(ip.strip())
    except (ValueError, AttributeError):
        return None
    if addr.version == 6 and addr.ipv4_mapped:
        addr = addr.ipv4_mapped  # ::ffff:104.28.46.99 becomes 104.28.46.99
    starts, rs = index[addr.version]
    n = int(addr)
    i = bisect.bisect_right(starts, n) - 1
    if i >= 0 and n <= rs[i][1]:
        return dict(zip(("prefix", "country", "region", "city"), rs[i][2:]))
    return None

if __name__ == "__main__":
    t0 = time.time()
    index, rows = load(CSV_PATH) if os.path.exists(CSV_PATH) else (None, 0)
    index, rows = refresh(index, rows)
    print(f"{rows:,} prefixes ready in {time.time() - t0:.1f}s")
    for ip in ["104.28.46.99", "172.224.226.1", "2a02:26f7:c880::1", "::ffff:104.28.28.41",
               "162.159.192.1", "102.129.235.17", "not-an-ip"]:
        print(f"{ip:22} {match(index, ip)}")

نزّل التشغيل الأول، الساعة 09:41 بالتوقيت العالمي، الملف وطبع:

GeoIPHub API

downloaded new list: 285,091 prefixes
285,091 prefixes ready in 12.8s
104.28.46.99           {'prefix': '104.28.46.99/32', 'country': 'ZM', 'region': '', 'city': 'Lusaka'}
172.224.226.1          {'prefix': '172.224.226.0/27', 'country': 'GB', 'region': 'GB-EN', 'city': 'London'}
2a02:26f7:c880::1      {'prefix': '2a02:26f7:c880::/54', 'country': 'GB', 'region': 'GB-EN', 'city': 'London'}
::ffff:104.28.28.41    {'prefix': '104.28.28.41/32', 'country': 'AU', 'region': 'AU-SA', 'city': 'Adelaide'}
162.159.192.1          None
102.129.235.17         None
not-an-ip              None

العنوان 162.159.192.1 عنوان اتصال WARP، و102.129.235.17 خادم VPN تجاري، لذا لا ينبغي أن يطابق أيٌّ منهما، ولم يطابق. كما اختبرنا مسارات الفشل:

ملف لم يتغير. أرسل التشغيل الثاني الـ ETag المحفوظ وتلقى 304 وطبع "not modified, keeping current list". واستغرق تحميل الملف المحلي وفهرسته 4.3 ثانية، فابنِ الفهرس مرة واحدة عند بدء التشغيل لا مع كل طلب.
تنزيل سيئ. وجّهنا URL إلى مسار غير موجود (أجاب خادم Apple بـ 400). وبصورة منفصلة، رفعنا الحد الأدنى لعدد الصفوف فوق العدد الحقيقي. وفي المرتين سجّل السكربت الفشل وحذف ملفه المؤقت واستمر في الإجابة من النسخة القديمة.
العناوين المُعيَّنة. طابق ::ffff:104.28.28.41 صفّه في IPv4. وكثيرًا ما تسجّل الخوادم ثنائية المكدس عملاء IPv4 بهذه الصيغة.

ولأن الملف لا يحتوي بادئات متداخلة، يكفي بحث ثنائي واحد لكل استعلام. ويرفض المحمِّل أي ملف مستقبلي فيه تداخلات، ثم يعود التحديث إلى آخر نسخة سليمة.

كيف تكتشف Cloudflare WARP، ولماذا لا توجد قائمة

لا يمكنك مطابقة WARP مع قائمة عامة، لأن Cloudflare لا تنشر واحدة. ولا يمكن التعرف على WARP إلا عبر مزود يضع تسميات على النطاقات التي يعرفها، أو على جهاز المستخدم نفسه.

إن توثيق سياسات الخروج لدى Cloudflare واضح في ذلك: "لا تنشر Cloudflare نطاقات IP لخروج عميل Cloudflare One." أما "نطاقات WARP IP" المتداولة في مواضيع المنتديات فهي شيء آخر. ويقول دليل جدار الحماية لدى Cloudflare عن 162.159.192.0/24: "يُستخدم عنوان IP هذا لعميل WARP الاستهلاكي (1.1.1.1 مع WARP) ولا يلزم لخدمات Zero Trust." وهنا يتصل تطبيق WARP. ولا يرى خادم الويب لديك تلك العناوين كعناوين عملاء أبدًا.

هل يحصل الموقع على عنوان المستخدم الحقيقي بطريقة أخرى؟ ليس في التصفح العادي. تقول الأسئلة الشائعة عن WARP لدى Cloudflare: "يستبدل 1.1.1.1 + WARP عنوان IP الأصلي الخاص بك بعنوان IP من Cloudflare يمثّل موقعك التقريبي بثبات ودقة. ويحدث هذا سواء أكان الموقع على شبكة Cloudflare أم لا."

وتوثّق الأسئلة الشائعة نفسها تسريبين. "لا يمرّر WARP حركة WebRTC عبر البروكسي." وأيضًا: "إذا منحت موقعًا إذنًا بالوصول إلى الميكروفون أو الكاميرا، فستتجاوز الحركة WARP وسيظهر عنوان IP الأصلي الخاص بك."

وعلى الجهاز نفسه، يطبع https://www.cloudflare.com/cdn-cgi/trace حقل warp=. وعلى جهازنا، الذي لا يشغّل WARP، كانت القيمة warp=off. ولا يراها إلا الشخص الذي يفتح تلك الصفحة، فهي تفيد فريق دعم يصلح اتصال عميل. ولا تفيد خادمًا يسجّل زائرًا.

تعيد واجهتنا relay_provider: "Cloudflare WARP" لنطاقات اتصال WARP التي تنشرها Cloudflare. وقد أعاد استعلام عن 162.159.192.1 القيم is_relay: true وrelay_provider: "Cloudflare WARP" وis_hosting: true وis_anycast: true، بدرجة 24 وallow. وهذا هو العنوان الذي تتصل به تطبيقات WARP، لا عنوانًا سيراه خادمك كزائر.

ما تعيده واجهتنا لعناوين Cloudflare غير الموجودة في قائمة Apple

تعود عناوين مخارج شبكة الخصوصية لدى Cloudflare غير الموجودة في قائمة Apple موسومة بـ "Cloudflare"، بينما تعود نطاقات اتصال WARP المنشورة لدى Cloudflare بـ "Cloudflare WARP". وهذا هو 104.28.210.10. يقع في /16 نفسه الذي يقع فيه اثنان من مرحِّلات Apple لدينا لكنه ليس على قائمة Apple. وهذه نسخة مقتطعة من استعلامنا الساعة 09:40 بالتوقيت العالمي في 2026-10-12، بقيم غير معدّلة:

GeoIPHub API

{
  "ip": "104.28.210.10",
  "asn": {
    "asn": 13335,
    "org": "CLOUDFLARENET - Cloudflare, Inc.",
    "user_type": "consumer_privacy_network"
  },
  "geo": {
    "country_code": "CA",
    "city": "Toronto"
  },
  "detection": {
    "is_vpn": false,
    "is_hosting": false,
    "is_relay": true,
    "is_anonymous": false,
    "relay_provider": "Cloudflare"
  },
  "scoring": {
    "fraud_score": 9,
    "recommended_action": "allow",
    "detection_methods": ["relay_ip"]
  }
}

IP	على قائمة Apple؟	relay_provider	حقول أخرى	الدرجة والإجراء والطرق
104.28.210.10	لا	Cloudflare	AS13335, consumer_privacy_network, is_vpn false, is_hosting false	9, allow, relay_ip
104.28.28.41	نعم (AU, Adelaide)	iCloud Private Relay	AS13335, consumer_privacy_network	9, allow, relay_ip
162.159.192.1	لا (عنوان اتصال WARP)	Cloudflare WARP	is_hosting true, is_anycast true	24, allow, datacenter_ip + no_ptr_datacenter + relay_ip
102.129.235.17 (VPN، للمقارنة)	لا	لا يوجد	is_vpn true, is_anonymous true	92, block, known_vpn_server + openvpn_open + ipsec_open

اقرأ "Cloudflare" على أنه "عنوان مخرج خصوصية استهلاكية لدى Cloudflare غير منسوب إلى Apple". وهو لا يعني مستخدم WARP مؤكدًا، ولا ندّعي ذلك. ولا يسرد مرجع الواجهة لدينا سوى قيمتين لـ relay_provider حاليًّا، "iCloud Private Relay" و"Cloudflare WARP"، لذا فهذه القيمة الثالثة غير موثَّقة حاليًّا. وقد طلبنا من فريق الواجهة الخلفية توثيقها.

والنقطة المفيدة في الصفين الأولين. ففي /16 واحد لدى Cloudflare، تفصل مطابقة CSV التامة مرحِّل Apple (104.28.28.41) عن مخرج خصوصية آخر لدى Cloudflare (104.28.210.10). وتتفق تسميتنا مع قائمة Apple في الحالتين. وكلاهما يحصل على 9 وallow، فسياستك واحدة في الحالتين. وصف VPN أيضًا بلا اسم مزود: التقطته فحوصنا، لكنه ليس في أي قائمة مزودين لدينا، وهذا سبب بقاء VPN دون اسم.

Private Relay وWARP جنبًا إلى جنب

السؤال	iCloud Private Relay	Cloudflare WARP
من يشغّله	Apple، مع شبكات شريكة للمرحِّل الثاني	Cloudflare
من يستطيع استخدامه	مشتركو iCloud+ على iPhone أو iPad أو Mac موثَّق	أي شخص يثبّت تطبيق 1.1.1.1 المجاني
ما يغطيه	Safari واستعلامات DNS وحركة تطبيقات http غير الآمنة	حركة الجهاز، باستثناء WebRTC والمواقع الممنوحة إذنًا بالكاميرا أو الميكروفون
قائمة مخارج عامة	نعم، ملف CSV من Apple	لا
الموقع	تُحفظ المنطقة؛ مدينة تقريبية افتراضيًّا، وأوسع إذا اختار المستخدم	عنوان IP من Cloudflare يمثّل الموقع التقريبي للمستخدم
كيف يتعرف عليه الخادم	مطابقة تامة مع CSV من Apple، أو علم مرحِّل من مزود	تسمية من مزود فقط

قد يقع كلاهما على AS13335، فلا تفصل الشبكة وحدها بينهما.

ما تعيده استعلاماتنا لعناوين المرحِّل

في استعلاماتنا، تعود عناوين Private Relay كمرحِّلات لا كمجهولة الهوية أو VPN، وتقع في allow ما لم توجد أدلة أخرى. تتبّعنا 104.28.46.99 من أوله إلى آخره. يقول صف Apple: زامبيا، لوساكا. وهذا هو الطلب كما سترسله بمفتاح:

GeoIPHub API

curl https://api.geoiphub.com/v1/lookup/104.28.46.99 \
  -H "x-api-key: YOUR_API_KEY"

شغّلناه دون مفتاح الساعة 09:40 بالتوقيت العالمي في 2026-10-12، وتسمح الواجهة بذلك للاستخدام الخفيف. وهذه نسخة مقتطعة من الاستجابة، بقيم غير معدّلة:

GeoIPHub API

{
  "ip": "104.28.46.99",
  "asn": {
    "asn": 13335,
    "org": "CLOUDFLARENET - Cloudflare, Inc.",
    "asn_type": "unknown",
    "user_type": "consumer_privacy_network"
  },
  "geo": {
    "country_code": "AO",
    "region": "Luanda",
    "city": "Luanda",
    "geo_confidence": 0.8
  },
  "detection": {
    "is_proxy": false,
    "is_vpn": false,
    "is_tor": false,
    "is_hosting": false,
    "is_relay": true,
    "is_anonymous": false,
    "anonymity_level": "medium",
    "relay_provider": "iCloud Private Relay"
  },
  "scoring": {
    "fraud_score": 9,
    "recommended_action": "allow",
    "detection_methods": ["relay_ip"]
  }
}

سُمّي المرحِّل، وis_vpn وis_anonymous كلاهما false، ويُظهر scoring.detection_methods الإشارة الوحيدة التي أُطلقت: relay_ip. والدرجة 9، فالإجراء allow. ويقول التحديد الجغرافي أنغولا، وهو ما يناقضه صف Apple؛ ونعالج ذلك في القسم التالي. والقرار لهذا العنوان أن تسمح به، وتحدّد معدله كعنوان مشترك، وتأخذ موقعه من صف Apple.

وهذه المرحِّلات الأخرى بجانب VPN حقيقي:

IP	صف Apple	نتيجتنا في 2026-10-12
172.224.226.1	GB, GB-EN, London	AS36183 Akamai, asn_type hosting; is_relay true, iCloud Private Relay, is_hosting true; الدرجة 24, allow; datacenter_ip, no_ptr_datacenter, relay_ip; geo GB, London
104.28.28.41	AU, AU-SA, Adelaide	AS13335; is_relay true, iCloud Private Relay; الدرجة 9, allow; relay_ip; geo AU, Sydney, 0.8
102.129.235.17 (VPN)	ليس على القائمة	AS834 IPXO; is_vpn true, is_anonymous true; الدرجة 92, block; known_vpn_server, openvpn_open, ipsec_open

علم المرحِّل لا يخفض الدرجة. بل يضيف إليها. ففي 104.28.46.99، relay_ip هو الإدخال الوحيد في detection_methods، فهو يفسّر الدرجة 9 كلها. ويحصل 172.224.226.1 على 24 لأن إشارتين لمركز بيانات أُطلقتا أيضًا، فيبقى على بعد نقطة واحدة داخل حد allow البالغ 25. لذا تقع المرحِّلات في allow ما لم توجد أدلة أخرى. وإن وُجد ما يحتسب ضد العنوان، كإدراج في قائمة إساءة، ارتفعت الدرجة وقد ينتقل الإجراء إلى review. وتسرد صفحة كيف تُبنى الدرجة الإشارات.

تسمّي الواجهة المرحِّل. وملف CSV من Apple هو فحصك المستقل، والمطابِق أعلاه ينفّذه دوننا. وتسجيل المرحِّل كأنه VPN هو الحالة الكلاسيكية في الإيجابيات الكاذبة في اكتشاف VPN.

لماذا يُظهر مستخدمو Private Relay مدينة خاطئة، بما في ذلك في بياناتنا

لا يعد عنوان المرحِّل إلا بمنطقة المستخدم، ومدينة تقريبية افتراضيًّا. والموقع الموثوق الوحيد لعنوان المرحِّل هو صف Apple نفسه، وقاعدة بياناتنا لا تتفق معه دائمًا.

تقول صفحة Apple لمشغِّلي الشبكات إن عنوان المرحِّل "يمثّل بدقة الموقع التقريبي للعميل على مستوى المدينة افتراضيًّا". ويمكن للمستخدمين توسيع ذلك. ويسرد دليل مستخدم iPhone الحالي لدى Apple خيارين لموقع عنوان IP، "Maintain General Location" و"Use Country and Time Zone". وتصفهما نظرة 2021 العامة. يختار الأول عناوين "تقابل منطقة تقريبية على مستوى المدينة تتسق مع المكان الذي يتصل منه المستخدم فعلًا". ويختار الثاني عناوين "عبر منطقة إقليمية أوسع"، و"ستظل جميع عناوين IP للمرحِّل تقابل بلد المستخدم الأصلي ومنطقته الزمنية."

قارنّا تحديدنا الجغرافي بصفوف Apple للمرحِّلات الثلاثة:

IP	صف Apple	تحديدنا الجغرافي	هل يتفقان؟
104.28.46.99	ZM, Lusaka	AO, Luanda (geo_confidence 0.8)	لا، بلد مختلف
104.28.28.41	AU, AU-SA, Adelaide	AU, Sydney (geo_confidence 0.8)	البلد نعم، المدينة لا
172.224.226.1	GB, GB-EN, London	GB, London	نعم

يختلف اثنان من الثلاثة. زامبيا مقابل أنغولا خطأ على مستوى البلد، من النوع الذي يُفعّل قاعدة ترخيص أو عقوبات. وأديلايد مقابل سيدني تصيب البلد وتخطئ المدينة. ثلاثة عناوين IP ليست اختبار أداء، لكنها تكفي لوضع قاعدة: لعناوين المرحِّل، خذ الموقع من صف Apple لا من أي قاعدة بيانات جغرافية، بما فيها قاعدتنا. وقرّر بحسب البلد أو المنطقة، وتعامل مع المدينة على أنها تلميح. وقد سجّلنا كلا الاختلافين لدى فريق الواجهة الخلفية.

هل تحجب Private Relay أو WARP؟ مرّرهما وسجّل الجلسة

لا. تتحقق Apple من كل عميل مرحِّل وتقول إن قواعد الاحتيال المعتمدة على IP "قد تحتاج إلى تعديل"، لذا اسمح بحركة Private Relay، وحدّد معدلها كعنوان مشغِّل مشترك، وارفع مستوى التحقق فقط عندما تشير أدلة أخرى إلى مخاطر.

وصفحة Apple لمشغِّلي الشبكات مباشرة بشأن النقطتين:

"قد يحتاج اكتشاف الاحتيال التقليدي المعتمد على عناوين IP إلى تعديل لضمان عدم تضرر المستخدمين المشروعين."

"فكّر في معاملة هذه العناوين كما تعامل عناوين Carrier-Grade NAT الأكبر أو عناوين IP المؤسسية لحساب هذا النوع من الحركة على نحو أفضل، إذ قد يُخصَّص كثير من مستخدمي Private Relay لعنوان IP واحد للمرحِّل."

كما تقدم Apple بديلًا لصفحة التحدي. فهي تلاحظ أن "التخفيفات الشائعة تشمل CAPTCHA أو حجب الحركة كليًّا"، وتقول "يدعم كل جهاز Apple يعمل بـ iOS 16 أو iPadOS 16 أو macOS Monterey وما بعدها رموز الوصول الخاصة (Private Access Tokens)"، وهي تتيح للخادم التحقق من جهاز مشروع دون تحديد هوية المستخدم.

هل يستطيع المحتالون استخدام المرحِّلات؟ يستطيعون، لكن Private Relay يتطلب جهاز Apple وحساب iCloud+ مدفوعًا. وتقول Apple إن التحقق "مصمم لضمان أن الأجهزة والحسابات الصالحة وذات السمعة الجيدة فقط يُسمح لها باستخدام Private Relay." وهذا يجعله طريقة مكلفة لتصنيع الحسابات. أما WARP فتطبيق مجاني، فأعطِ جلسات WARP وزنًا أكبر قليلًا في إشاراتك الأخرى، لا حجبًا. وتقع مشكلات إخفاء IP الأصعب في مكان آخر، مثل بروكسيات الجوال.

وتفصيل لمحدِّد المعدل لديك: نصيحة Apple بشأن Carrier-Grade NAT تتعلق بطريقة تعاملك مع العنوان لا بعلم. وكان threat.is_cgnat قيمته false في استعلامات المرحِّل الثلاثة كلها. فاربط معالجة العنوان المشترك بـ is_relay أو بمطابقة CSV بدلًا من ذلك. ولفحص عنوان من سجلاتك، الصقه في أداة استعلام IP المجانية.

ما تراه	الإجراء	السبب
IP في CSV من Apple أو is_relay true، دون دليل مخاطر آخر	السماح؛ وتحديد المعدل لكل حساب أو جلسة لا لكل IP	تتحقق Apple من الجهاز والحساب، ويتشارك مستخدمون كثيرون عنوان مرحِّل واحدًا
عنوان مرحِّل أو WARP مع إشارة حساب خطرة (حساب جديد، أو بلد دفع خارج منطقة IP، أو سرعة التسجيل)	رفع التحقق: رمز وصول خاص (Private Access Token) حيث يُدعم، وإلا مصادقة ثنائية أو فحص بريد، لا جدار CAPTCHA	لا يضيف IP دليلًا؛ الدليل من إشارة الحساب
عنوان مرحِّل يقع أيضًا في review، مثلًا لأنه على قائمة إساءة	المراجعة	هذا الدليل يخص العنوان لا المرحِّل
عنوان موسوم بـ WARP	السماح وتسجيل الجلسة	مجاني وشائع؛ يخفي المستخدم لكنه لا يثبت النية
قواعد الموقع (الترخيص والضرائب) على حركة المرحِّل	القرار بحسب البلد أو المنطقة من صف Apple، لا المدينة أبدًا	تحافظ Apple على المنطقة؛ والمدينة تقريبية أو أوسع بحسب الإعداد

ثلاثة فحوص تجريها على سجلاتك هذا الأسبوع:

عدّ مستخدمي المرحِّل الذين رددتهم. اربط آخر 30 يومًا من عمليات التسجيل وتسجيل الدخول والرفض بملف CSV من Apple باستخدام المطابِق أعلاه. كم مستخدم مرحِّل رفضته قواعدك أو تحدّته؟
ابحث عن حجب ASN والاستضافة. ابحث في قواعدك عن AS13335 أو AS36183 أو is_hosting. العنوان 172.224.226.1 مرحِّل بقيمة is_hosting: true، فحجب الاستضافة يصيب مستخدمي المرحِّل.
افحص حدود كل IP وأسيجة المدن الجغرافية. تقول Apple أن تعامل عناوين المرحِّل كما تعامل Carrier-Grade NAT، فحدّ لكل IP مصمم لأسرة واحدة سيخنق مستخدمين كثيرين، وسياج على مستوى المدينة سيخطئ مع موقع تقريبي.

الأسئلة الشائعة

كيف أعرف إن كان iCloud Private Relay مفعّلًا؟

على iPhone، افتح الإعدادات، ثم اضغط على اسمك، ثم iCloud، ثم Private Relay. أما بصفتك مشغّل موقع فلا ترى الإعداد بل العنوان فقط: إن طابق قائمة مخارج Apple فقد مرّ ذلك الطلب عبر Private Relay.

هل iCloud Private Relay هو VPN؟

لا. فهو يغطي Safari وDNS وحركة تطبيقات http غير الآمنة فقط، ويبقي المستخدم في بلده ومنطقته، ويقتصر على أجهزة Apple الموثَّقة ذات اشتراك iCloud+.

هل يخفي Cloudflare WARP عنوان IP الخاص بك؟

نعم. تقول Cloudflare إن WARP يستبدل عنوان IP الأصلي بعنوان IP من Cloudflare سواء أكان الموقع على Cloudflare أم لا، باستثناء حركة WebRTC والمواقع التي مُنحت إذنًا بالوصول إلى الكاميرا أو الميكروفون.

أين قائمة عناوين IP الخاصة بـ iCloud Private Relay؟

تنشرها Apple على mask-api.icloud.com/egress-ip-ranges.csv. وفي 2026-10-12 كانت تضم 285,091 بادئة IPv4 وIPv6 موزعة على 235 رمز دولة.

هل يستطيع موقع ويب رؤية عنوان IP الحقيقي خلف Private Relay؟

ليس بحسب التصميم. يرى الموقع عنوان المرحِّل فقط، ولا يرى عنوان المستخدم الفعلي إلا مرحِّل Apple الأول.

هل ينبغي أن أحجب iCloud Private Relay؟

لا. تقول Apple إن قواعد الاحتيال المعتمدة على IP قد تحتاج إلى تعديل لمستخدمي المرحِّل. اسمح به، وحدّد معدله كما تفعل مع Carrier-Grade NAT، وارفع مستوى التحقق فقط عند وجود إشارات مخاطر أخرى.

بقلم

فريق GeoIPHub

الفريق الذي يقف وراء واجهة GeoIPHub API

بقلم فريق GeoIPHub، وهم من يبنون واجهة GeoIPHub API لاستخبارات IP وماسحها. تُعَدّ المسودات بمساعدة الذكاء الاصطناعي ويحررها الفريق، وأمثلة API استعلامات حقيقية على واجهة API الحية ما لم تُوصف بأنها توضيحية.

تابعنا على LinkedIn

شارك هذا المقال

مزيد من المقالات

اكتشاف iCloud Private Relay وCloudflare WARP، ثم تمريرهما

كيف تكتشف iCloud Private Relay: طابِق قائمة Apple نفسها

ما في ملف CSV لمخارج Apple

لماذا لا تكفي قاعدة ASN أو /16

لماذا لا يُعد عنوان المرحِّل عنوان VPN

طابِق عنوان IP مع قائمة Apple بلغة Python

كيف تكتشف Cloudflare WARP، ولماذا لا توجد قائمة

ما تعيده واجهتنا لعناوين Cloudflare غير الموجودة في قائمة Apple

Private Relay وWARP جنبًا إلى جنب

ما تعيده استعلاماتنا لعناوين المرحِّل

لماذا يُظهر مستخدمو Private Relay مدينة خاطئة، بما في ذلك في بياناتنا

هل تحجب Private Relay أو WARP؟ مرّرهما وسجّل الجلسة

الأسئلة الشائعة

كيف أعرف إن كان iCloud Private Relay مفعّلًا؟

هل iCloud Private Relay هو VPN؟

هل يخفي Cloudflare WARP عنوان IP الخاص بك؟

أين قائمة عناوين IP الخاصة بـ iCloud Private Relay؟

هل يستطيع موقع ويب رؤية عنوان IP الحقيقي خلف Private Relay؟

هل ينبغي أن أحجب iCloud Private Relay؟

مقالات ذات صلة

كيف يعمل اكتشاف VPN والبروكسي فعليًّا، إشارة بعد إشارة

لماذا يُوسَم عنوان IP الخاص بي على أنه VPN أو بروكسي؟ وكيف أصلح ذلك

الإيجابيات الكاذبة في اكتشاف VPN: من يُوسَم خطأً وماذا تفعل