Trong mô hình WebSOS, giao thông từ một nguồn tới server đích sẽ đi qua các node theo thứ tự: nguồn, SOAP, Beacon, Servlet và Server đích. Cơ chế định tuyến thông thường được sử dụng để người dùng kết nối tới SOAP. Hơn nữa, do Beacon đã biết các Servlet xác định tương ứng với các Server, cũng như Servlet cũng biết vị trí của Server, vì vậy cơ chế định tuyến thông thường cũng được sử dụng giữa Beacon và Servlet, giữa Servlet và Server đích. Còn giữa SOAP với Beacon, một cơ chế định tuyến của lớp bao phủ được sử dụng. Nhằm giảm quãng đường định tuyến giữa chúng, nhờ đó giảm quãng đường tổng từ nguồn tới Server đích, thuật toán Chord được sử dụng trong trường hợp này.
Trong mô hình SOS gốc, quãng đường thiết lập từ người dùng đến Server đích qua mạng bao phủ có thể khác với quãng đường ngược lại từ Server đích tới người dùng. Hơn nữa, response từ Server đích có thể gửi trực tiếp đến người dùng mà không qua lại mạng bao phủ, bởi các kênh truyền thông là song công, và trong các cuộc tấn công DDoS thì chỉ có kết nối tới các Server đích mới là bị tắc nghẽn. Cách thức có những thuận lợi khá lớn trong việc giảm độ trễ của mạng, vì hầu hết các kết nối client/server hiện nay là không đối xứng do các client thường nhận response nhiều hơn là gửi đi các request.
Trong WebSOS, định tuyến được thực hiện với từng kết nối cơ bản. Mỗi request tiếp theo trong cùng một kết nối và các response từ Server đích có thể đi theo quãng đường ngược lại trong mạng bao phủ. Trong khi cơ chế này làm cho việc áp dụng trở nên đơn giản, nó cũng gây nên hậu quả làm cho độ trễ tăng lên đáng kể, vì hầu hết các response đều đi qua mạng bao phủ với nhiều chặng, hơn là việc đi trực tiếp đến máy khách để giảm quãng đường trong mạng phủ.