2. Démarrez `frps` sur le serveur A :

`./frps -c ./frps.toml`

3. Modifiez `frpc.toml` sur le serveur B et définissez le champ `serverAddr` sur l'adresse IP publique de votre serveur frps :  ```toml
# frpc.toml
serverAddr = "x.x.x.x"
serverPort = 7000

[[proxies]]
name = "ssh"
type = "tcp"
localIP = "127.0.0.1"
localPort = 22
remotePort = 6000

2. Déployez frpc sur la machine interne A avec la configuration suivante :  ```toml
serverAddr = "x.x.x.x"
serverPort = 7000

[[proxies]]
name = "ssh1"
type = "tcpmux"
multiplexer = "httpconnect"
customDomains = ["machine-a.example.com"]
localIP = "127.0.0.1"
localPort = 22

4. Pour accéder à la machine interne A via SSH ProxyCommand, en supposant que le nom d'utilisateur est « test » :

`ssh -o 'proxycommand socat - PROXY:x.x.x.x:%h:%p,proxyport=5002' [email protected]`

5. Pour accéder à la machine interne B, la seule différence est le nom de domaine, en supposant que le nom d'utilisateur est « test » :

`ssh -o 'proxycommand socat - PROXY:x.x.x.x:%h:%p,proxyport=5002' [email protected]`

### Accéder aux services web internes avec des domaines personnalisés dans le LAN

Parfois, nous devons exposer un service web local derrière un réseau NAT à d'autres personnes à des fins de test avec notre propre nom de domaine.

Malheureusement, nous ne pouvons pas résoudre un nom de domaine vers une IP locale. Cependant, nous pouvons utiliser frp pour exposer un service HTTP(S).

1. Modifiez `frps.toml` et définissez le port HTTP pour vhost sur 8080 :  ```toml
# frps.toml
bindPort = 7000
vhostHTTPPort = 8080

4. Démarrez `frpc` :

`./frpc -c ./frpc.toml`

5. Mappez l'enregistrement A de `www.example.com` vers l'IP publique du serveur frps distant ou un enregistrement CNAME pointant vers votre domaine d'origine.

6. Visitez votre service web local en utilisant l'URL `http://www.example.com:8080`.

### Transférer les requêtes de requête DNS

1. Modifiez `frps.toml` :  ```toml
# frps.toml
bindPort = 7000

4. Démarrez frpc :

`./frpc -c ./frpc.toml`

5. Testez la résolution DNS à l'aide de la commande `dig` :

`dig @x.x.x.x -p 6000 www.google.com`

### Transfert de socket Unix

Exposez un socket de domaine Unix (par exemple, le socket du démon Docker) en tant que TCP.

Configurez `frps` comme ci-dessus.

1. Démarrez `frpc` avec la configuration suivante :  ```toml
# frpc.toml
serverAddr = "x.x.x.x"
serverPort = 7000

[[proxies]]
name = "unix_domain_socket"
type = "tcp"
remotePort = 6000
[proxies.plugin]
type = "unix_domain_socket"
unixPath = "/var/run/docker.sock"

2. Visitez `http://x.x.x.x:6000/static/` depuis votre navigateur et spécifiez le nom d'utilisateur et le mot de passe corrects pour afficher les fichiers dans `/tmp/files` sur la machine `frpc`.

### Activer HTTPS pour un service HTTP(S) local

Vous pouvez remplacer le plugin par `https2https` et pointer `localAddr` vers un point de terminaison HTTPS.

1. Démarrez `frpc` avec la configuration suivante :  ```toml
# frpc.toml
serverAddr = "x.x.x.x"
serverPort = 7000

[[proxies]]
name = "test_https2http"
type = "https"
customDomains = ["test.example.com"]

[proxies.plugin]
type = "https2http"
localAddr = "127.0.0.1:80"
crtPath = "./server.crt"
keyPath = "./server.key"
hostHeaderRewrite = "127.0.0.1"
requestHeaders.set.x-from-where = "frp"

2. Démarrez un autre `frpc` (généralement sur une autre machine C) avec la configuration suivante pour accéder au service SSH avec une clé de sécurité (champ `secretKey`) :  ```toml
# frpc.toml
serverAddr = "x.x.x.x"
serverPort = 7000

[[visitors]]
name = "secret_ssh_visitor"
type = "stcp"
serverName = "secret_ssh"
secretKey = "abcdefg"
bindAddr = "127.0.0.1"
bindPort = 6000

2. Démarrez un autre `frpc` (généralement sur une autre machine C) avec la configuration pour se connecter à SSH en mode P2P :  ```toml
# frpc.toml
serverAddr = "x.x.x.x"
serverPort = 7000
# set up a new stun server if the default one is not available.
# natHoleStunServer = "xxx"

[[visitors]]
name = "p2p_ssh_visitor"
type = "xtcp"
serverName = "p2p_ssh"
secretKey = "abcdefg"
bindAddr = "127.0.0.1"
bindPort = 6000
# when automatic tunnel persistence is required, set it to true
keepTunnelOpen = false

Avec la configuration ci-dessus, les variables peuvent être transmises au programme `frpc` de cette manière :```
export FRP_SERVER_ADDR=x.x.x.x
export FRP_SSH_REMOTE_PORT=6000
./frpc -c ./frpc.toml

Please provide the Markdown content to translate.```toml
# ./confd/test.toml

[[proxies]]
name = "ssh"
type = "tcp"
localIP = "127.0.0.1"
localPort = 22
remotePort = 6000

Puis visitez `http://[serverAddr]:7500` pour voir le tableau de bord, avec le nom d'utilisateur et le mot de passe étant tous deux `admin`.

De plus, vous pouvez utiliser le port HTTPS en utilisant le certificat SSL wildcard ou normal de vos domaines :```toml
webServer.port = 7500
# dashboard's username and password are both optional
webServer.user = "admin"
webServer.password = "admin"
webServer.tls.certFile = "server.crt"
webServer.tls.keyFile = "server.key"

Ensuite, visitez `http://127.0.0.1:7400` pour voir l'interface d'administration, avec le nom d'utilisateur et le mot de passe étant tous deux `admin`.

#### Gestion dynamique des proxys (Store)

Vous pouvez créer, mettre à jour et supprimer dynamiquement des proxys et des visiteurs à l'exécution via l'interface Web ou l'API, sans redémarrer frpc.

Pour activer cette fonctionnalité, configurez `store.path` pour spécifier un fichier de persistance des configurations :```toml
[store]
path = "./db.json"

Le jeton sera lu depuis le fichier spécifié au démarrage. Cela est utile pour les scénarios où les jetons sont gérés par des systèmes externes ou doivent être conservés séparément des fichiers de configuration pour des raisons de sécurité.

#### Authentification OIDC

Lorsque `auth.method = "oidc"` est spécifié dans `frpc.toml` et `frps.toml` - l'authentification basée sur OIDC sera utilisée.

OIDC signifie OpenID Connect, et le flux utilisé est appelé [Client Credentials Grant](https://tools.ietf.org/html/rfc6749#section-4.4).

Pour utiliser ce type d'authentification - configurez `frpc.toml` et `frps.toml` comme suit :```toml
# frps.toml
auth.method = "oidc"
auth.oidc.issuer = "https://example-oidc-issuer.com/"
auth.oidc.audience = "https://oidc-audience.com/.default"

## Installation

To install `dnsx`, you need to have Go 1.21 or higher installed. Then, run the following command:

```bash
go install -v github.com/projectdiscovery/dnsx/cmd/dnsx@latest

dnsx -h

# frpc.toml
auth.method = "oidc"
auth.oidc.clientID = "98692467-37de-409a-9fac-bb2585826f18" # Replace with OIDC client ID
auth.oidc.clientSecret = "oidc_secret"
auth.oidc.audience = "https://oidc-audience.com/.default"
auth.oidc.tokenEndpointURL = "https://example-oidc-endpoint.com/oauth2/v2.0/token"
```
### Encryption et compression

Ces fonctionnalités sont désactivées par défaut. Vous pouvez activer le chiffrement et/ou la compression :```toml
# frpc.toml

[[proxies]]
name = "ssh"
type = "tcp"
localPort = 22
remotePort = 6000
transport.useEncryption = true
transport.useCompression = true
```
#### TLS

Depuis la v0.50.0, la valeur par défaut de `transport.tls.enable` et `transport.tls.disableCustomTLSFirstByte` a été modifiée à true, et TLS est activé par défaut.

Pour le multiplexage de ports, frp envoie un premier octet `0x17` pour établir une connexion TLS. Cela ne prend effet que lorsque vous définissez `transport.tls.disableCustomTLSFirstByte` sur false.

Pour **forcer** `frps` à n'accepter que des connexions TLS - configurez `transport.tls.force = true` dans `frps.toml`. **Ceci est facultatif.**

**Paramètres TLS de `frpc` :**```toml
transport.tls.enable = true
transport.tls.certFile = "certificate.crt"
transport.tls.keyFile = "certificate.key"
transport.tls.trustedCaFile = "ca.crt"
```
**`frps` Paramètres TLS :**```toml
transport.tls.force = true
transport.tls.certFile = "certificate.crt"
transport.tls.keyFile = "certificate.key"
transport.tls.trustedCaFile = "ca.crt"
```
Vous aurez besoin **d'un certificat CA racine** et **d'au moins un certificat SSL/TLS**. Il **peut** être auto-signé ou standard (comme Let's Encrypt ou un autre fournisseur de certificats SSL/TLS).

Si vous utilisez `frp` via une adresse IP et non un nom d'hôte, assurez-vous de définir l'adresse IP appropriée dans la zone Subject Alternative Name (SAN) lors de la génération des certificats SSL/TLS.

Exemple :

* Préparez le fichier de configuration openssl. Il se trouve à `/etc/pki/tls/openssl.cnf` sur les systèmes Linux et à `/System/Library/OpenSSL/openssl.cnf` sur MacOS, et vous pouvez le copier dans le répertoire courant, comme `cp /etc/pki/tls/openssl.cnf ./my-openssl.cnf`. Sinon, vous pouvez le créer vous-même, comme :```
cat > my-openssl.cnf << EOF
[ ca ]
default_ca = CA_default
[ CA_default ]
x509_extensions = usr_cert
[ req ]
default_bits        = 2048
default_md          = sha256
default_keyfile     = privkey.pem
distinguished_name  = req_distinguished_name
attributes          = req_attributes
x509_extensions     = v3_ca
string_mask         = utf8only
[ req_distinguished_name ]
[ req_attributes ]
[ usr_cert ]
basicConstraints       = CA:FALSE
nsComment              = "OpenSSL Generated Certificate"
subjectKeyIdentifier   = hash
authorityKeyIdentifier = keyid,issuer
[ v3_ca ]
subjectKeyIdentifier   = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints       = CA:true
EOF
```
* générer les certificats d'autorité de certification :```
openssl genrsa -out ca.key 2048
openssl req -x509 -new -nodes -key ca.key -subj "/CN=example.ca.com" -days 5000 -out ca.crt
```
* générer les certificats frps :```
openssl genrsa -out server.key 2048

openssl req -new -sha256 -key server.key \
    -subj "/C=XX/ST=DEFAULT/L=DEFAULT/O=DEFAULT/CN=server.com" \
    -reqexts SAN \
    -config <(cat my-openssl.cnf <(printf "\n[SAN]\nsubjectAltName=DNS:localhost,IP:127.0.0.1,DNS:example.server.com")) \
    -out server.csr

openssl x509 -req -days 365 -sha256 \
	-in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial \
	-extfile <(printf "subjectAltName=DNS:localhost,IP:127.0.0.1,DNS:example.server.com") \
	-out server.crt
```
* générer les certificats frpc :```
openssl genrsa -out client.key 2048
openssl req -new -sha256 -key client.key \
    -subj "/C=XX/ST=DEFAULT/L=DEFAULT/O=DEFAULT/CN=client.com" \
    -reqexts SAN \
    -config <(cat my-openssl.cnf <(printf "\n[SAN]\nsubjectAltName=DNS:client.com,DNS:example.client.com")) \
    -out client.csr

openssl x509 -req -days 365 -sha256 \
    -in client.csr -CA ca.crt -CAkey ca.key -CAcreateserial \
	-extfile <(printf "subjectAltName=DNS:client.com,DNS:example.client.com") \
	-out client.crt
```
### Rechargement à chaud de la configuration frpc

Les champs `webServer` sont requis pour activer l'API HTTP :```toml
# frpc.toml
webServer.addr = "127.0.0.1"
webServer.port = 7400
```
Ensuite, exécutez la commande `frpc reload -c ./frpc.toml` et attendez environ 10 secondes pour laisser `frpc` créer, mettre à jour ou supprimer les proxys.

**Notez que les paramètres globaux du client ne seront pas modifiés, à l'exception de 'start'.**

`start` est une liste blanche globale évaluée après la fusion de toutes les sources (fichier de configuration/include/store).
Si `start` n'est pas vide, tout proxy ou visiteur qui n'y figure pas ne sera pas démarré, y compris
les entrées créées via l'API Store.

`start` est principalement conservé pour des raisons de compatibilité et n'est généralement pas recommandé pour les nouvelles configurations.
Privilégiez `enabled` par proxy/par visiteur, et laissez `start` vide sauf si vous souhaitez explicitement ce
comportement de liste blanche globale.

Vous pouvez exécuter la commande `frpc verify -c ./frpc.toml` avant le rechargement pour vérifier s'il y a des erreurs de configuration.

### Obtenir le statut des proxys depuis le client

Utilisez `frpc status -c ./frpc.toml` pour obtenir le statut de tous les proxys. Les champs `webServer` sont requis pour activer l'API HTTP.

### Autoriser uniquement certains ports sur le serveur

`allowPorts` dans `frps.toml` est utilisé pour éviter l'abus des ports :```toml
# frps.toml
allowPorts = [
  { start = 2000, end = 3000 },
  { single = 3001 },
  { single = 3003 },
  { start = 4000, end = 50000 }
]
```
### Réutilisation de port

`vhostHTTPPort` et `vhostHTTPSPort` dans frps peuvent utiliser le même port que `bindPort`. frps détectera le protocole de la connexion et le gérera en conséquence.

Ce que vous devez noter, c'est que si vous souhaitez configurer `vhostHTTPSPort` et `bindPort` sur le même port, vous devez d'abord définir `transport.tls.disableCustomTLSFirstByte` sur false.

Nous aimerions essayer de permettre à plusieurs proxys de lier un même port distant avec différents protocoles à l'avenir.

### Limite de bande passante

#### Pour chaque proxy```toml
# frpc.toml

[[proxies]]
name = "ssh"
type = "tcp"
localPort = 22
remotePort = 6000
transport.bandwidthLimit = "1MB"
```
Définissez `transport.bandwidthLimit` dans la configuration de chaque proxy pour activer cette fonctionnalité. Les unités prises en charge sont `MB` et `KB`.

Définissez `transport.bandwidthLimitMode` sur `client` ou `server` pour limiter la bande passante côté client ou côté serveur. La valeur par défaut est `client`.

### Multiplexage de flux TCP

frp prend en charge le multiplexage de flux TCP depuis la v0.10.0, comme le multiplexage HTTP2, dans ce cas toutes les connexions logiques vers le même frpc sont multiplexées dans la même connexion TCP.

Vous pouvez désactiver cette fonctionnalité en modifiant `frps.toml` et `frpc.toml` :```toml
# frps.toml and frpc.toml, must be same
transport.tcpMux = false
```
### Prise en charge du protocole KCP

KCP est un protocole rapide et fiable qui permet d'obtenir une réduction de la latence moyenne de 30 % à 40 % et une réduction du délai maximal d'un facteur trois, au prix de 10 % à 20 % de bande passante supplémentaire gaspillée par rapport à TCP.

Le mode KCP utilise UDP comme transport sous-jacent. Utilisation de KCP dans frp :

1. Activer KCP dans frps :  ```toml
  # frps.toml
  bindPort = 7000
  # Specify a UDP port for KCP.
  kcpBindPort = 7000
  ```
The `kcpBindPort` number can be the same number as `bindPort`, since `bindPort` field specifies a TCP port.

2. Configure `frpc.toml` to use KCP to connect to frps:  ```toml
  # frpc.toml
  serverAddr = "x.x.x.x"
  # Same as the 'kcpBindPort' in frps.toml
  serverPort = 7000
  transport.protocol = "kcp"
  ```
### Prise en charge du protocole QUIC

QUIC est un nouveau transport multiplexé construit au-dessus d'UDP.

Utilisation de QUIC dans frp :

1. Activer QUIC dans frps :  ```toml
  # frps.toml
  bindPort = 7000
  # Specify a UDP port for QUIC.
  quicBindPort = 7000
  ```
The `quicBindPort` number can be the same number as `bindPort`, since `bindPort` field specifies a TCP port.

2. Configure `frpc.toml` to use QUIC to connect to frps:  ```toml
  # frpc.toml
  serverAddr = "x.x.x.x"
  # Same as the 'quicBindPort' in frps.toml
  serverPort = 7000
  transport.protocol = "quic"
  ```
### Regroupement de connexions

Par défaut, frps crée une nouvelle connexion frpc vers le service backend à chaque requête utilisateur. Avec le regroupement de connexions, frps conserve un certain nombre de connexions préétablies, réduisant ainsi le temps nécessaire pour établir une connexion.

Cette fonctionnalité convient à un grand nombre de connexions courtes.

1. Configurez la limite du nombre de connexions du pool que chaque proxy peut utiliser dans `frps.toml` :  ```toml
  # frps.toml
  transport.maxPoolCount = 5
  ```
2. Activez et spécifiez le nombre de pools de connexions :  ```toml
  # frpc.toml
  transport.poolCount = 1
  ```
### Équilibrage de charge

L'équilibrage de charge est pris en charge par `group`.

Cette fonctionnalité n'est actuellement disponible que pour les types `tcp`, `http`, `tcpmux`.```toml
# frpc.toml

[[proxies]]
name = "test1"
type = "tcp"
localPort = 8080
remotePort = 80
loadBalancer.group = "web"
loadBalancer.groupKey = "123"

[[proxies]]
name = "test2"
type = "tcp"
localPort = 8081
remotePort = 80
loadBalancer.group = "web"
loadBalancer.groupKey = "123"
```
`loadBalancer.groupKey` est utilisé pour l'authentification.

Les connexions au port 80 seront réparties aléatoirement entre les proxys du même groupe.

Pour le type `tcp`, `remotePort` doit être identique au sein du même groupe.

Pour le type `http`, `customDomains`, `subdomain`, `locations` doivent être identiques.

### Vérification de l'état du service

La fonctionnalité de vérification de l'état peut vous aider à atteindre une haute disponibilité avec l'équilibrage de charge.

Ajoutez `healthCheck.type = "tcp"` ou `healthCheck.type = "http"` pour activer la vérification de l'état.

Avec le type de vérification **tcp**, le port du service sera sondé (TCPing) :```toml
# frpc.toml

[[proxies]]
name = "test1"
type = "tcp"
localPort = 22
remotePort = 6000
# Enable TCP health check
healthCheck.type = "tcp"
# TCPing timeout seconds
healthCheck.timeoutSeconds = 3
# If health check failed 3 times in a row, the proxy will be removed from frps
healthCheck.maxFailed = 3
# A health check every 10 seconds
healthCheck.intervalSeconds = 10
```
Avec le type de vérification de santé **http**, une requête HTTP sera envoyée au service et une réponse HTTP 2xx OK est attendue :```toml
# frpc.toml

[[proxies]]
name = "web"
type = "http"
localIP = "127.0.0.1"
localPort = 80
customDomains = ["test.example.com"]
# Enable HTTP health check
healthCheck.type = "http"
# frpc will send a GET request to '/status'
# and expect an HTTP 2xx OK response
healthCheck.path = "/status"
healthCheck.timeoutSeconds = 3
healthCheck.maxFailed = 3
healthCheck.intervalSeconds = 10
```
### Réécriture de l'en-tête HTTP Host

Par défaut, frp ne modifie pas du tout les requêtes HTTP tunnelisées, car il s'agit d'une copie octet pour octet.

Cependant, en parlant de serveurs web et de requêtes HTTP, votre serveur web pourrait s'appuyer sur l'en-tête HTTP `Host` pour déterminer le site web à atteindre. frp peut réécrire l'en-tête `Host` lors du transfert des requêtes HTTP, grâce au champ `hostHeaderRewrite` :```toml
# frpc.toml

[[proxies]]
name = "web"
type = "http"
localPort = 80
customDomains = ["test.example.com"]
hostHeaderRewrite = "dev.example.com"
```
The HTTP request will have the `Host` header rewritten to `Host: dev.example.com` when it reaches the actual web server, although the request from the browser probably has `Host: test.example.com`.

### Setting other HTTP Headers

Similar to `Host`, You can override other HTTP request and response headers with proxy type `http`.```toml
# frpc.toml

[[proxies]]
name = "web"
type = "http"
localPort = 80
customDomains = ["test.example.com"]
hostHeaderRewrite = "dev.example.com"
requestHeaders.set.x-from-where = "frp"
responseHeaders.set.foo = "bar"
```
Dans cet exemple, il définira l'en-tête `x-from-where: frp` dans la requête HTTP et `foo: bar` dans la réponse HTTP.

### Obtenir l'IP réelle

#### HTTP X-Forwarded-For

Cette fonctionnalité est destinée aux proxys `http` ou aux proxys avec les plugins `https2http` et `https2https` activés.

Vous pouvez obtenir l'IP réelle de l'utilisateur à partir des en-têtes de requête HTTP `X-Forwarded-For`.

#### Proxy Protocol

frp prend en charge le Proxy Protocol pour envoyer l'IP réelle de l'utilisateur aux services locaux.

Voici un exemple pour le service https :```toml
# frpc.toml

[[proxies]]
name = "web"
type = "https"
localPort = 443
customDomains = ["test.example.com"]

# now v1 and v2 are supported
transport.proxyProtocolVersion = "v2"
```
Vous pouvez activer la prise en charge du Proxy Protocol dans nginx pour exposer l'IP réelle de l'utilisateur dans l'en-tête HTTP `X-Real-IP`, puis lire l'en-tête `X-Real-IP` dans votre service web pour obtenir l'IP réelle.

### Exiger une authentification HTTP Basic (mot de passe) pour les services web

Toute personne qui devine l'URL de votre tunnel peut accéder à votre serveur web local, sauf si vous le protégez avec un mot de passe.

Cela impose une authentification HTTP Basic sur toutes les requêtes avec le nom d'utilisateur et le mot de passe spécifiés dans le fichier de configuration de frpc.

Elle ne peut être activée que lorsque le type de proxy est http.```toml
# frpc.toml

[[proxies]]
name = "web"
type = "http"
localPort = 80
customDomains = ["test.example.com"]
httpUser = "abc"
httpPassword = "abc"
```
Visitez `http://test.example.com` dans le navigateur et vous êtes maintenant invité à saisir le nom d'utilisateur et le mot de passe.

### Noms de sous-domaines personnalisés

Il est pratique d'utiliser la configuration `subdomain` pour les types http et https lorsque de nombreuses personnes partagent un seul serveur frps.```toml
# frps.toml
subDomainHost = "frps.com"
```
Résolvez `*.frps.com` vers l'adresse IP du serveur frps. C'est ce qu'on appelle généralement un enregistrement DNS générique (Wildcard DNS).```toml
# frpc.toml

[[proxies]]
name = "web"
type = "http"
localPort = 80
subdomain = "test"
```
Maintenant, vous pouvez visiter votre service web sur `test.frps.com`.

Notez que si `subdomainHost` n'est pas vide, `customDomains` ne doit pas être un sous-domaine de `subdomainHost`.

### Routage d'URL

frp prend en charge le transfert de requêtes HTTP vers différents services web backend via le routage d'URL.

`locations` spécifie le préfixe de l'URL utilisé pour le routage. frps recherche d'abord le préfixe le plus spécifique donné par des chaînes littérales, quel que soit l'ordre de la liste.```toml
# frpc.toml

[[proxies]]
name = "web01"
type = "http"
localPort = 80
customDomains = ["web.example.com"]
locations = ["/"]

[[proxies]]
name = "web02"
type = "http"
localPort = 81
customDomains = ["web.example.com"]
locations = ["/news", "/about"]
```
Les requêtes HTTP avec le préfixe d'URL `/news` ou `/about` seront transmises à **web02** et les autres requêtes à **web01**.

### Multiplexage de ports TCP

frp prend en charge la réception de sockets TCP dirigés vers différents proxys sur un seul port sur frps, similaire à `vhostHTTPPort` et `vhostHTTPSPort`.

La seule méthode de multiplexage de ports TCP prise en charge actuellement est `httpconnect` - tunnel HTTP CONNECT.

Lorsque `tcpmuxHTTPConnectPort` est défini sur une valeur autre que 0 dans frps, frps écoutera sur ce port les requêtes HTTP CONNECT.

L'hôte de la requête HTTP CONNECT sera utilisé pour faire correspondre le proxy dans frps. Les hôtes de proxy peuvent être configurés dans frpc en configurant `customDomains` et/ou `subdomain` sous les proxys `tcpmux`, lorsque `multiplexer = "httpconnect"`.

Par exemple :```toml
# frps.toml
bindPort = 7000
tcpmuxHTTPConnectPort = 1337
```
(empty)```toml
# frpc.toml
serverAddr = "x.x.x.x"
serverPort = 7000

[[proxies]]
name = "proxy1"
type = "tcpmux"
multiplexer = "httpconnect"
customDomains = ["test1"]
localPort = 80

[[proxies]]
name = "proxy2"
type = "tcpmux"
multiplexer = "httpconnect"
customDomains = ["test2"]
localPort = 8080
```
Dans la configuration ci-dessus - frps peut être contacté sur le port 1337 avec un en-tête HTTP CONNECT tel que :```
CONNECT test1 HTTP/1.1\r\n\r\n
```
and the connection will be routed to `proxy1`.

### Connexion à frps via un proxy

frpc peut se connecter à frps via un proxy si vous définissez la variable d'environnement du système d'exploitation `HTTP_PROXY`, ou si `transport.proxyURL` est défini dans le fichier frpc.toml.

Cela ne fonctionne que lorsque le protocole est tcp.```toml
# frpc.toml
serverAddr = "x.x.x.x"
serverPort = 7000
transport.proxyURL = "http://user:[email protected]:8080"
```
### Mappage de plage de ports

*Ajouté dans la v0.56.0*

Nous pouvons utiliser la syntaxe de plage des templates Go combinée à la fonction intégrée `parseNumberRangePair` pour réaliser un mappage de plage de ports.

L'exemple suivant, lorsqu'il est exécuté, créera 8 proxys nommés `test-6000, test-6001 ... test-6007`, chacun mappant le port distant vers le port local.```
{{- range $_, $v := parseNumberRangePair "6000-6006,6007" "6000-6006,6007" }}
[[proxies]]
name = "tcp-{{ $v.First }}"
type = "tcp"
localPort = {{ $v.First }}
remotePort = {{ $v.Second }}
{{- end }}
```
### Plugins côté client

Par défaut, frpc ne transmet les requêtes que vers des ports TCP ou UDP locaux.

Les plugins sont utilisés pour fournir des fonctionnalités riches. Il existe des plugins intégrés tels que `unix_domain_socket`, `http_proxy`, `socks5`, `static_file`, `http2https`, `https2http`, `https2https` et vous pouvez voir [un exemple d'utilisation](#example-usage).

Utilisation du plugin **http_proxy** :```toml
# frpc.toml

[[proxies]]
name = "http_proxy"
type = "tcp"
remotePort = 6000
[proxies.plugin]
type = "http_proxy"
httpUser = "abc"
httpPassword = "abc"
```
`httpUser` et `httpPassword` sont des paramètres de configuration utilisés dans le plugin `http_proxy`.

### Plugins de gestion du serveur

Lisez le [document](https://github.com/fatedier/frp/blob/HEAD/doc/server_plugin.md).

Trouvez plus de plugins dans [gofrp/plugin](https://github.com/gofrp/plugin).

### Passerelle de tunnel SSH

*ajouté dans v0.53.0*

frp prend en charge l'écoute d'un port SSH côté frps et réalise le proxy du protocole TCP via le protocole SSH -R, sans dépendre de frpc.```toml
# frps.toml
sshTunnelGateway.bindPort = 2200
```
Lors de l’exécution de `./frps -c frps.toml`, un fichier de clé privée nommé `.autogen_ssh_key` sera automatiquement créé dans le répertoire de travail actuel. Ce fichier de clé privée généré sera utilisé par le serveur SSH dans frps.

Exécution de la commande```bash
ssh -R :80:127.0.0.1:8080 v0@{frp address} -p 2200 tcp --proxy_name "test-tcp" --remote_port 9090
```
met en place un proxy sur frps qui transmet le service local 8080 vers le port 9090.```bash
frp (via SSH) (Ctrl+C to quit)

User:
ProxyName: test-tcp
Type: tcp
RemoteAddress: :9090
```
Ceci est équivalent à :```bash
frpc tcp --proxy_name "test-tcp" --local_ip 127.0.0.1 --local_port 8080 --remote_port 9090
```
Veuillez vous référer à ce [document](https://github.com/fatedier/frp/blob/HEAD/doc/ssh_tunnel_gateway.md) pour plus d'informations.

### Réseau virtuel (VirtualNet)

*Fonctionnalité alpha ajoutée dans la v0.62.0*

La fonctionnalité VirtualNet permet à frp de créer et de gérer des connexions réseau virtuelles entre les clients et les visiteurs via une interface TUN. Cela permet un routage au niveau IP entre les machines, étendant frp au-delà du simple transfert de ports pour prendre en charge une connectivité réseau complète.

Pour des informations détaillées sur la configuration et l'utilisation, veuillez vous référer à la [documentation VirtualNet](https://github.com/fatedier/frp/blob/HEAD/doc/virtual_net.md).

## Feature Gates

frp prend en charge les feature gates pour activer ou désactiver les fonctionnalités expérimentales. Cela permet aux utilisateurs de tester de nouvelles fonctionnalités avant qu'elles ne soient considérées comme stables.

### Feature Gates disponibles

| Nom | Étape | Défaut | Description |
|------|-------|---------|-------------|
| VirtualNet | ALPHA | false | Capacités de réseau virtuel pour frp |

### Activation des feature gates

Pour activer une fonctionnalité expérimentale, ajoutez le feature gate à votre configuration :```toml
featureGates = { VirtualNet = true }
```
### Cycle de vie des fonctionnalités

Les fonctionnalités passent généralement par trois étapes :
1. **ALPHA** : Désactivées par défaut, peuvent être instables
2. **BÊTA** : Peuvent être activées par défaut, plus stables mais encore en évolution
3. **GA (Disponibilité générale)** : Activées par défaut, prêtes pour une utilisation en production

## Projets connexes

* [gofrp/plugin](https://github.com/gofrp/plugin) - Un dépôt pour les plugins frp qui contient une variété de plugins implémentés sur la base du mécanisme d'extension de frp, répondant aux besoins de personnalisation de différents scénarios.
* [gofrp/tiny-frpc](https://github.com/gofrp/tiny-frpc) - Une version légère du client frp (environ 3,5 Mo au minimum) implémentée à l'aide du protocole ssh, prenant en charge certaines des fonctionnalités les plus couramment utilisées, adaptée aux appareils disposant de ressources limitées.

## Contribution

Vous souhaitez vous impliquer ? Nous serions ravis de vous aider !

* Consultez notre [liste de problèmes](https://github.com/fatedier/frp/issues) et envisagez d'envoyer une Pull Request vers la **branche dev**.
* Si vous souhaitez ajouter une nouvelle fonctionnalité, veuillez d'abord créer un problème pour décrire la nouvelle fonctionnalité, ainsi que l'approche d'implémentation. Une fois la proposition acceptée, créez une implémentation des nouvelles fonctionnalités et soumettez-la sous forme de pull request.
* Désolé pour mon anglais approximatif. Les améliorations de ce document sont les bienvenues, même les simples corrections de fautes de frappe.
* Si vous avez de bonnes idées, envoyez un e-mail à [email protected].

**Remarque : Nous préférons que vous donniez votre avis dans les [problèmes](https://github.com/fatedier/frp/issues), afin que d'autres personnes ayant la même question puissent la rechercher rapidement et que nous n'ayons pas à y répondre à plusieurs reprises.**

## Don

Si frp vous aide beaucoup, vous pouvez nous soutenir en :

### Sponsors GitHub

Soutenez-nous via [Github Sponsors](https://github.com/sponsors/fatedier).

Vous pouvez faire placer le logo de votre entreprise dans le fichier README de ce projet.

### PayPal

Faites un don via [PayPal](https://www.paypal.me/fatedier) sur mon compte **[email protected]**.