# HTTP、HTTPS 和 SOCKS5，以及网关处理各协议的确切方式。

采用标准协议，无需自定义客户端。本页为需要了解网络传输细节的用户准确说明各项行为。


## 速查表

| 目标 | 客户端中的代理 URL | 端口 |
| --- | --- | --- |
| `http://` 和 `https://` URL | http://USER:PASS@res.proxshift.com:9000 | 9000 |
| 任何基于 TCP 的流量，主机名由出口解析 | socks5h://USER:PASS@res.proxshift.com:9001 | 9001 |
| 同上，但主机名由本机解析 | socks5://USER:PASS@res.proxshift.com:9001 | 9001 |
| 专用地址，HTTP(S) | http://USER:PASS@203.0.113.42:8000 | 8000 |
| 专用地址，SOCKS5 | socks5h://USER:PASS@203.0.113.42:8001 | 8001 |


## HTTP

对于普通的 `http://` 目标，客户端会把带有绝对 URI 和 `Proxy-Authorization` 标头的请求发送到 9000 端口。网关会移除该标头，通过出口转发请求，并以流式方式返回响应。支持采用 keep-alive 的 HTTP/1.1；保持活动的连接会继续使用同一出口（参见[轮换](https://proxshift.com/zh/docs/username-parameters#rotation-and-sessions)）。


## HTTPS

对于 `https://` 目标，客户端发送 `CONNECT host:443`，网关则从出口建立原始隧道。TLS 握手通过该隧道在客户端与目标之间完成：网关不会解密、检查或重新签名任何内容，你所验证的证书就是目标本身的证书。在隧道内协商的 HTTP/2 和 HTTP/3-over-TCP 回退机制与直连时行为相同。


## SOCKS5

- 支持 RFC 1928，可使用用户名/密码身份验证（RFC 1929），白名单地址也可以免验证。
- 可通过 `CONNECT` 连接除 25 之外的任何 TCP 端口。不支持 `BIND` 和 `UDP ASSOCIATE`：不支持 UDP，也不支持入站连接。
- 发送主机名（地址类型 0x03），让出口负责解析；在 curl、Python 和 Node 中，`socks5h://` 表示的正是这种方式。如果客户端在本地解析并发送 IP，请求仍能工作，但 DNS 查询发生在你的设备上。
- 非 HTTP 的 TCP 协议以及仅支持 SOCKS 的客户端应选择 SOCKS5；对于 Web 流量，HTTP 端口的效果相同。


## 标头

网关会移除 `Proxy-Authorization` 和 `Proxy-Connection`，且不会添加任何内容：没有 `Via`、`X-Forwarded-For` 或 `X-Real-IP`。目标收到的是出口设备原样发出的请求，这正是该网络的用途。请自行设置 `User-Agent`、`Accept-Language` 及其他标头，使其与出口所在国家一致。


## 不支持的功能

- 任何形式的 UDP（配置代理后，所有浏览器中的 QUIC 都会回退到 TCP）。
- IPv6 目标：出口使用 IPv4。
- 直接与代理端口建立 TLS（即将 `https://` 用作**代理**协议）。到网关这一段不加密；参见[端点](https://proxshift.com/zh/docs/endpoints#https-targets)。
- FTP、使用 25 端口的 SMTP，以及需要代理反向连接到你的协议。


来源：https://proxshift.com/zh/docs/protocols