آیا یک وب‌سایت می‌تواند NAT را از پروکسی پیش‌رو تشخیص دهد؟
ارزیابی کنید که یک IP عمومی مشترک، سرآیندهای ارسال و نتیجهٔ بررسی پروکسی چه چیزی را دربارهٔ مسیر رسیدن به یک وب‌سایت ثابت می‌کنند.
چند بازدیدکننده از یک نشانی عمومی می‌آیند. این با دروازهٔ NAT یک دفتر جور درمی‌آید. با پروکسی پیش‌روی مشترک هم جور درمی‌آید. خود نشانی میان این دو انتخاب نمی‌کند.
NAT اطلاعات نشانی را در طول مسیر تغییر می‌دهد. پروکسی پیش‌رو یک اتصال را می‌پذیرد و اتصال بعدی را برقرار می‌کند. این‌ها سازوکارهای متفاوتی هستند، اما مقصد اتصال‌هایی را می‌بیند که به آن می‌رسند، نه فهرست کامل تجهیزات شبکهٔ کاربر.
فیلد Via در HTTP می‌تواند شاهدی بر وجود واسطه‌های HTTP باشد. نبودنش را تنگ‌تر تفسیر کنید: این درخواست آن نشانگر را به این ناظر نشان نداد. سرآیندها ممکن است نامعتبر، حذف‌شده یا درون یک تونل معمولی TLS سرتاسری در دسترس نباشند. پایگاه‌های اعتبار IP نوع دیگری از شاهد را فراهم می‌کنند، با پوشش و قدمت خودشان.
به همین دلیل «هیچ پروکسی‌ای یافت نشد» در یک ابزار بررسی نقشهٔ شبکه نیست. همچنین نمی‌تواند گواهی دهد که هر وب‌سایت دیگری به همان نتیجه می‌رسد.
اگر کاربر یا شبکه را اداره می‌کنید، مشاهدات نقطهٔ پایانی را با تنظیمات واقعی برنامه، پیکربندی دروازه و سوابق مرتبط اتصال ترکیب کنید. اگر فقط وب‌سایت را اداره می‌کنید، توضیح دهید سیگنال‌هایتان از چه چیزی پشتیبانی می‌کنند و جای عدم‌قطعیت را باز بگذارید.
برای کنترل دسترسی، تصمیم بگیرید از چه چیزی باید محافظت کنید. نشانی مشترک می‌تواند برای محدودیت نرخ درشت مفید باشد، اما جانشین بدی برای یک شخص است. نامیدنش به NAT یا پروکسی آن مشکل هویت را حل نمی‌کند.