Web 表单代理改变的是浏览器的源，而不只是出口 IP
区分带 URL 输入框的代理网站与浏览器原生代理，并说明为什么复杂的登录和脚本可能表现不同。
带 URL 输入框的页面本身就是一个 Web 应用。在其中填入目标地址，等于请这个应用去抓取并呈现内容。这与让浏览器使用 HTTP 或 SOCKS 代理是两回事。
使用原生代理设置时，浏览器仍把目标 URL 视为网站本身。而在传统的 Web 表单代理中，你看到的页面是通过代理应用自己的 URL 方案和源提供的。为了维持跳转，服务可能会重写链接、脚本、请求头或 Cookie。
| 行为 | 差异为何重要 |
|---|---|
| 同源检查 | 浏览器评估的是它实际加载的源 |
| Cookie 与重定向 | 域、路径与安全上下文的行为必须与呈现的 URL 相符 |
| 构造新 URL 的脚本 | 请求可能逃出简单的链接重写方案 |
| 持久连接或 WebSockets | 代理应用需要显式的兼容处理 |
这解释了一个常见结果：简单的文章能打开，文档编辑器或登录流程却失败。失败并不一定意味着目标站点拒绝了该服务的出口 IP。中间层可能无法维持应用对 URL 和浏览器安全性的假设。
还要区分 TLS 在哪里终止。抓取并重新发布目标内容的服务，其信任地位与承载加密会话的普通 CONNECT 中继并不相同。在代理网站自己的地址上看到 HTTPS，并不能证明浏览器到原站之间是端到端的 TLS 连接。
如果目的只是通过另一个出口正常浏览，请从你的服务或代理列表中挑选 HTTP 或 SOCKS 端点，并使用受支持的原生代理配置，例如 Firefox 的连接设置。这通常能保留更多浏览器正常的目标语义。带 URL 输入框的站点仍可以是有意选择的应用程序，但不应被说成是少些配置的同一种接口。