Skip to content

RDTKF-25112 Clarify --proxy scope and document relay-server pattern #204

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
samartha-pm merged 3 commits into from
Sep 9, 2026
+7 −4
Merged

RDTKF-25112 Clarify --proxy scope and document relay-server pattern #204

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
4268558
RDTKF-25112 Clarify --proxy scope and document relay-server pattern
rmlos Sep 2, 2026
9b33cb9
RDTKF-25112 Move concept to Overview, rewrite negatives per style guide
rmlos Sep 2, 2026
9035b0f
Merge branch 'main' into RDTKF-25112
rmlos Sep 8, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 7 additions & 4 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -28,6 +28,8 @@ You run `outsystemscc` on a system in your private network—an on-premise netwo

`outsystemscc` creates a fast TCP/UDP tunnel, with transport over HTTP via WebSockets, secured via SSH using ECDSA with SHA256 keys. The connection is established to either the built-in domain for the stage (for example `<organization>.outsystems.app`) or a custom domain configured for the stage (for example `example.com`). In both cases, the connection is over TLS and always encrypted with a valid X.509 certificate.

Past that tunnel, `outsystemscc` forwards traffic to each `<remote-host>` as a raw TCP/UDP passthrough, carrying HTTP and TLS content through exactly as the connecting client sends it. An HTTP `Host` header or a TLS Server Name Indication (SNI) reaches `<remote-host>` unchanged. Because `outsystemscc` treats `<remote-host>` as an opaque TCP/UDP endpoint, `<remote-host>` can itself be a relay rather than the final service: point it at an intermediary that terminates TLS or presents a different hostname when the real destination requires that.

The following diagram is an example of a ODC customer setup for a Private Gateway active on two stages.

![Private gateways diagram](images/private-gateways-diag.png "Private gateways diagram")
Expand Down Expand Up @@ -89,7 +91,7 @@ The OutSystems Cloud Connector establishes an outbound secure WebSocket (WSS) co

No inbound firewall rules are required. The connector only needs the ability to initiate outbound connections.

If the network requires outbound traffic to route through a proxy, you specify that using the `--proxy` option.
If the network requires outbound traffic to route through a proxy, you specify that using the `--proxy` option. `--proxy` applies only to this connection, from Cloud Connector to the Private Gateway. `outsystemscc` dials the connection to each `<remote-host>` directly through the host's local network stack, bypassing `--proxy`.

#### Layer 7 (Application-Level) Firewalls

Expand Down Expand Up @@ -243,9 +245,10 @@ If your organization uses a centralized log management product, see its document
--max-retry-interval, Maximum wait time before retrying after a
disconnection. Defaults to 5 minutes.

--proxy, An optional HTTP CONNECT or SOCKS5 proxy which will be
used to reach the server. Authentication can be specified
inside the URL.
--proxy, An optional HTTP CONNECT or SOCKS5 proxy used to reach
<server> (the Private Gateway). Applies only to that connection:
outsystemscc dials the connection to each <remote-host> directly,
bypassing --proxy. Authentication can be specified inside the URL.
For example, http://admin:password@my-server.com:8081
or: socks://admin:password@my-server.com:1080

Expand Down