a month ago
Hello Railway Support,
We operate Pipernus, a web application hosted on Railway that integrates with HMRC Making Tax Digital APIs using the WEB_APP_VIA_SERVER connection method.
Project: innovative-optimism
Environment: production
Service: pipernus
Public domain: www.pipernus.app
HMRC requires metadata from the original browser-to-vendor connection:
- the originating device's public IPv4/IPv6 address;
- its public TCP source port, not destination port 443;
- the exact public destination IP on which the first Railway edge accepted TLS; and
- the sequence of public Internet hops that terminate TLS.
Could you please provide authoritative answers to the following questions?
-
Can our workload obtain, for each request, the exact public destination IP on which the Railway edge accepted the browser's TCP/TLS connection? If yes, which header or API provides it? Is it exact for that request, and can an external client spoof it?
-
If the exact IP is not available directly, is there an authoritative mapping from X-Railway-Edge to that IP? How do anycast, IPv4/IPv6 and custom domains affect that mapping?
-
Can Railway expose the original public TCP source port observed at the first TLS terminator? We do not mean port 443, the deployment PORT, an internal proxy port, or the source port of a later connection. If this is unsupported, please confirm that explicitly.
-
For X-Real-IP, X-Forwarded-For, Forwarded, X-Railway-Edge, X-Request-Start and X-Railway-Request-Id, does Railway remove, overwrite, append to, or pass through values supplied by an external client? Which value is the authoritative public client IP? Can public traffic bypass these guarantees?
-
Is X-Request-Start generated by the first Railway edge when the client IP is observed? Please confirm its format/unit and whether any client-supplied value is overwritten.
-
After the public edge terminates TLS, is traffic forwarded exclusively over Railway's internal network? If another public TLS terminator exists, can our workload obtain each public “by” and “for” value for the request?
If either the exact ingress destination IP or the original client public source port is unavailable, please state this explicitly in writing. We need provider evidence for HMRC's exceptional missing-header process.
HMRC specification:
https://developer.service.hmrc.gov.uk/guides/fraud-prevention/connection-method/web-app-via-server/
Railway documentation reviewed:
https://docs.railway.com/networking/public-networking/specs-and-limits
https://docs.railway.com/networking/edge-networking
https://docs.railway.com/networking/static-outbound-ips
We can provide project, service and deployment identifiers privately if required. This request contains no credentials, tokens or customer data.
Thank you.
2 Replies
a month ago
This thread has been opened as a public bounty so the community can help solve it. The thread and any further activity are now visible to everyone.
Status changed to Open Railway • about 1 month ago
a month ago
Thank you for the detailed response.
Because this information will be used as regulatory evidence for HMRC, we need confirmation from an authorised Railway employee rather than a community account.
Could a Railway employee please confirm, specifically for the selected production service:
-
Whether the original browser public TCP source port is unavailable at the workload.
-
Whether the exact per-request public destination IP used at the first Railway TLS terminator is unavailable.
-
Whether X-Forwarded-For is stripped, overwritten or appended at the public edge, and whether the authoritative client IP is the first/leftmost or last/rightmost value. The current reply states rightmost, while Railway employee answers elsewhere state first/leftmost.
-
Whether X-Real-IP currently represents the original client IP for this service across every Railway routing/CDN path, including Fastly or other upstream CDN infrastructure.
-
Whether X-Request-Start is generated and overwritten by the first public edge, including its exact format and timing semantics.
-
Whether X-Railway-Edge and X-Railway-Request-Id are always generated or overwritten by Railway and cannot be supplied by an external client.
-
Whether all traffic after the first TLS terminator is carried through a non-public internal path with no public-origin bypass.
Please explicitly identify any unavailable fields and confirm that the answer is an official Railway platform statement applicable to:
Project: innovative-optimism
Environment: production
Service: pipernus
Domain: www.pipernus.app
We understand that HMRC, rather than Railway, must decide whether an unavailable field may be omitted under HMRC's exceptional missing-header process.
Thank you.
a month ago
Hello Railway Support,
Following up on our request regarding HMRC Fraud Prevention Headers for WEB_APP_VIA_SERVER. To unblock our HMRC exceptional missing-header submission, please explicitly confirm:
Whether the original public TCP source port observed at the first Railway TLS terminator is unavailable to the workload.
Whether the exact per-request public destination IP accepting TLS is unavailable, or which trusted header/API exposes it.
Whether Railway overwrites client-supplied X-Real-IP, X-Forwarded-For, Forwarded, X-Request-Start and X-Railway-Edge, and which value is guaranteed non-spoofable.
Whether X-Request-Start is generated at the first public edge, in Unix milliseconds.
Whether there is only one public TLS terminator before traffic enters Railway’s internal network.
Whether Railway provides static ingress IPs or authoritative per-request ingress-IP information for custom domains.
A direct written confirmation that the source port and/or ingress destination IP are unavailable is sufficient for our HMRC evidence package.